security problem with fat32 on suse 9.0

Because of data-exchange with windows-systems I have to mount a
fat32-partition into a suse 9.0 system. Only members of a special group may
read/write on it.So I edited /etc/fstab, set the "gid=" - option and the
"umask=0007". But because the dmask/fmask - option don't work on suse (on
debian is everything o.k.) all (!!) new regular files are executable. I
consider this a real security risk - but of course no help from suse
itself.
Does anybody have experience with this and give some advice?

Thanks very much

griscia

Gregor Ries wrote:

> Because of data-exchange with windows-systems I have to mount a
> fat32-partition into a suse 9.0 system. Only members of a special group
> may read/write on it.So I edited /etc/fstab, set the "gid=" - option and
> the "umask=0007". But because the dmask/fmask - option don't work on suse
> (on debian is everything o.k.) all (!!) new regular files are executable.
> I consider this a real security risk - but of course no help from suse
> itself.
> Does anybody have experience with this and give some advice?
>
> Thanks very much
>
> griscia

Experience: fat32 is insecure and has lots of virii that can attack it.
Advice: find a different way to do what you need without using FAT32.

--
.... bleakness ... desolation ... plastic forks ...

NeoSadist wrote:

> Gregor Ries wrote:
>
>> Because of data-exchange with windows-systems I have to mount a
>> fat32-partition into a suse 9.0 system. Only members of a special group
>> may read/write on it.So I edited /etc/fstab, set the "gid=" - option and
>> the "umask=0007". But because the dmask/fmask - option don't work on suse
>> (on debian is everything o.k.) all (!!) new regular files are executable.
>> I consider this a real security risk - but of course no help from suse
>> itself.
>> Does anybody have experience with this and give some advice?
>>
>> Thanks very much
>>
>> griscia
>
> Experience: fat32 is insecure and has lots of virii that can attack it.
> Advice: find a different way to do what you need without using FAT32.
>
You are completely right - but I need to have dataexchange on one
computersystem - and for this fat 32 is the only solution I know....
So if you have nevertheless an idea for such unsecure filesystem...
Thanks

In article <bv8ovi$phbhn$1@ID-47665.news.uni-berlin.de>,
Gregor Ries wrote:
> NeoSadist wrote:
>> Experience: fat32 is insecure and has lots of virii that can attack it.
>> Advice: find a different way to do what you need without using FAT32.
>>
> You are completely right - but I need to have dataexchange on one

Is he? This is news to me. What can a virus do to a FAT32 filesystem?
What vulnerabilities are specific to FAT32 (or to any type of DOS
filesystem, for that matter)?

Yes, it could be erased if some viral code executes under a DOS or
Windows OS. It could similarly be erased using "rm -rf /path-to/vfat"!
This has nothing to do with the filesystem!

> computersystem - and for this fat 32 is the only solution I know....

Let's nip the FUD in the bud.

FAT filesystems are well-supported under just about any OS you might
care to use -- MS's forced-upgrade policies for Win95 retail and WinNT
notwithstanding. There is absolutely nothing wrong from a security
standpoint with FAT32 (the vfat driver in Linux.) Simply be aware that
DOS filesystems are too primitive to support ownership and permission
attributes.

> So if you have nevertheless an idea for such unsecure filesystem...

IIRC from your OP, your answers should all be found in the man pages for
mount(8) and fstab(5).
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply

/dev/rob0 wrote:

> In article <bv8ovi$phbhn$1@ID-47665.news.uni-berlin.de>,
> Gregor Ries wrote:
>> NeoSadist wrote:
>>> Experience: fat32 is insecure and has lots of virii that can attack it.
>>> Advice: find a different way to do what you need without using FAT32.
>>>
>> You are completely right - but I need to have dataexchange on one
>
> Is he? This is news to me. What can a virus do to a FAT32 filesystem?
> What vulnerabilities are specific to FAT32 (or to any type of DOS
> filesystem, for that matter)?
>
> Yes, it could be erased if some viral code executes under a DOS or
> Windows OS. It could similarly be erased using "rm -rf /path-to/vfat"!
> This has nothing to do with the filesystem!
>
>> computersystem - and for this fat 32 is the only solution I know....
>
> Let's nip the FUD in the bud.
>
> FAT filesystems are well-supported under just about any OS you might
> care to use -- MS's forced-upgrade policies for Win95 retail and WinNT
> notwithstanding. There is absolutely nothing wrong from a security
> standpoint with FAT32 (the vfat driver in Linux.) Simply be aware that
> DOS filesystems are too primitive to support ownership and permission
> attributes.
>
>> So if you have nevertheless an idea for such unsecure filesystem...
>
> IIRC from your OP, your answers should all be found in the man pages for
> mount(8) and fstab(5).
No, I am sorry - on the manpages is written to use dmask and fmask; but as I
wrote, on SuSE they are not working. That's a bug in SuSE, but how to deal
with it if you must use SuSE?

In article <bvb9bh$qjjmj$1@ID-47665.news.uni-berlin.de>,
Gregor Ries wrote:
>> IIRC from your OP, your answers should all be found in the man pages for
>> mount(8) and fstab(5).
> No, I am sorry - on the manpages is written to use dmask and fmask; but as I
> wrote, on SuSE they are not working. That's a bug in SuSE, but how to deal
> with it if you must use SuSE?

Well, we're off topic here ... there's no security issue. Most likely
the only "bug" is incorrect syntax. For one thing, fmask and dmask,
according to my man page, are not supported in 2.4.x kernels. Did you
try umask? Did you understand that these are the ABSENT permission bits?

For another thing, if the uid and/or gid option is not set the umask
might not matter. The init process runs as root:root, so without uid or
gid that's who owns all the files. I no longer have need for primitive
filesystems, but when I did I used a GID value with the users who might
need access, and I used a umask=002 or 007. You mentioned having set the
GID, but not what GID you used.

If you're still having trouble look for examples on Google. TRY "umask"
TOO. If still no luck, post your EXACT fstab line here, the EXACT mount
command you use (be sure to add in the "-v" option) and the complete
command output. I'm sure it's a simple thing to solve.
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply

/dev/rob0 wrote:

> In article <bvb9bh$qjjmj$1@ID-47665.news.uni-berlin.de>,
> Gregor Ries wrote:
>>> IIRC from your OP, your answers should all be found in the man pages for
>>> mount(8) and fstab(5).
>> No, I am sorry - on the manpages is written to use dmask and fmask; but
>> as I wrote, on SuSE they are not working. That's a bug in SuSE, but how
>> to deal with it if you must use SuSE?
>
> Well, we're off topic here ... there's no security issue. Most likely
> the only "bug" is incorrect syntax. For one thing, fmask and dmask,
> according to my man page, are not supported in 2.4.x kernels. Did you
> try umask? Did you understand that these are the ABSENT permission bits?
>
> For another thing, if the uid and/or gid option is not set the umask
> might not matter. The init process runs as root:root, so without uid or
> gid that's who owns all the files. I no longer have need for primitive
> filesystems, but when I did I used a GID value with the users who might
> need access, and I used a umask=002 or 007. You mentioned having set the
> GID, but not what GID you used.
>
> If you're still having trouble look for examples on Google. TRY "umask"
> TOO. If still no luck, post your EXACT fstab line here, the EXACT mount
> command you use (be sure to add in the "-v" option) and the complete
> command output. I'm sure it's a simple thing to solve.
For the first: if all files on a partition are automatically executable, I
think this IS security-relevant - if not, you know a better group...?
Then I DO KNOW what umask means...
For the third I tried as well umask as dmask/fmask together with uid=500 and
gid=101, and nothing worked. Also colleagues didn't know a solution, so I
don't try to waste your time (and of course I used google a lot, but no
solutions, only some other people with the saqme question without answer).
For the fourth I tried also with debian and everything was fine (so
principally I did everything right) - but as Linux-Trainer I have to use
SuSE.
For the fifth I tried also the "support" of SuSE - which let me without
answer more than 10 days...
The fstab:
/dev/hda12 /austausch vfat auto,rw,user,exec,uid=500,gid=101,umask=117 0 0
(I tried also umask=007, umask=0117 and umask=0007)
I mount with "mount -a"
So thanks for your time...

Gregor Ries wrote:
.. . .
> The fstab:
> /dev/hda12 /austausch vfat auto,rw,user,exec,uid=500,gid=101,umask=117 0 0
> (I tried also umask=007, umask=0117 and umask=0007)
> I mount with "mount -a"

Check the man mount pages for vfat. On my RH9 system vfat
doesn't appear to support *mask options. You might try using
fat as the type and setting that to the 32 bit version.

jmh