FS possible security exposure ?

FS possible security exposure ?

[regatta]

Hi everyone,

I have a question regarding how Linux handle the files permission ,
here is what I found

When logged on to a Linux workstation a user can edit a file (even if
the file on an NFS-mounted NAS directory) if he has write access at
the directory level, even if the file is owned by root (or any other
user) and is read-only.

I tried this in local file system (ext3) and in remote home directory
(autofs) in (NetApp nfs NAS storage)

this is not the case with Solaris , the user will get permission
denied if he try to write any thing to the file.


My question is, what is happening ? and is it correct ? is it possible
to change it to behave to be like Solaris ?

(when you have hundred of users and hundred of NFS and thousand of 
net groups you don't want a user to edit other file just because he
has write permission in the patent dir).

Thanks

Best Regards,
--------------------
-*- If Linux doesn't have the solution, you have the wrong problem -*-

Re: FS possible security exposure ?

[Arjan van de Ven]

> (when you have hundred of users and hundred of NFS and thousand of 
> net groups you don't want a user to edit other file just because he
> has write permission in the patent dir).

if you have write permission in the directory you're allowed to
1) create new files
2) rename existing files
3) delete files
4) rename files over existing files (combo of 2 and 3 sort of)

so an "edit" as you describe is
* create a new file with the new (eg modified) content
* rename the new file over the existing file

that's how reliable editors operate (the rename-over-file is an atomic
operation) to avoid any possibility of dataloss due to crashes etc.

Since the 1-4 rules are pretty much there for all unixes...
Maybe your solaris editor doesn't do editing in this way?

Re: FS possible security exposure ?

[regatta]

I'm using Vi in Solaris and Vim in Linux, do you think this is the
problem ? (because when I use "echo BLABAL >> FILE_I_DONT_OWN_IT"  it
will give me permission denied in Linux)

but if you think about it, how could the system allow the user to
modify a file that he don't own it and he don't have write privilege
on the file just because he has write in the parent directory ?

Maybe I'm wrong, but is this normal ? please let me know

BTW: is there any document, article or any page about this so I can
show it to my boss :)

Thanks




On 12/25/05, Arjan van de Ven <arjan@infradead.org> wrote:
>
> > (when you have hundred of users and hundred of NFS and thousand of
> > net groups you don't want a user to edit other file just because he
> > has write permission in the patent dir).
>
> if you have write permission in the directory you're allowed to
> 1) create new files
> 2) rename existing files
> 3) delete files
> 4) rename files over existing files (combo of 2 and 3 sort of)
>
> so an "edit" as you describe is
> * create a new file with the new (eg modified) content
> * rename the new file over the existing file
>
> that's how reliable editors operate (the rename-over-file is an atomic
> operation) to avoid any possibility of dataloss due to crashes etc.
>
> Since the 1-4 rules are pretty much there for all unixes...
> Maybe your solaris editor doesn't do editing in this way?
>
>
>
>


--
Best Regards,
--------------------
-*- If Linux doesn't have the solution, you have the wrong problem -*-

Re: FS possible security exposure ?

[Wichert Akkerman]

Previously regatta wrote:
> but if you think about it, how could the system allow the user to
> modify a file that he don't own it and he don't have write privilege
> on the file just because he has write in the parent directory ?

As Arjan explained you are not modifying the file. vim just removes it
and replaces it with a new one.

> Maybe I'm wrong, but is this normal ? please let me know

It is, ans solaris does the same thing.

> BTW: is there any document, article or any page about this so I can
> show it to my boss :)

Any decent posix/unix manual should do.

Wichert.

-- 
Wichert Akkerman <wichert@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

Re: FS possible security exposure ?

[Arjan van de Ven]

On Sun, 2005-12-25 at 13:10 +0300, regatta wrote:
> I'm using Vi in Solaris and Vim in Linux, do you think this is the
> problem ?

that very well can be the difference

> but if you think about it, how could the system allow the user to
> modify a file that he don't own it and he don't have write privilege
> on the file just because he has write in the parent directory ?
> 
> Maybe I'm wrong, but is this normal ? please let me know

this is normal and a result of the linux permission model.
(and fwiw you don't get to edit the file, only to create a new file. You
may think that's exactly the same.. but it's not in the light of
hardlinks)

Btw there is a "sticky bit" you can set on the directory which changes this behavior,
for example /tmp has this set for obvious reasons

> BTW: is there any document, article or any page about this so I can
> show it to my boss :)

I suspect the SUS standard fully specifies the 4 rules I mentioned and
the sticky-exception (and the rest is an obvious result)

Re: FS possible security exposure ?

[regatta]

Thank you all, it was great information that you shared with me



On 12/25/05, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sun, 2005-12-25 at 13:10 +0300, regatta wrote:
> > I'm using Vi in Solaris and Vim in Linux, do you think this is the
> > problem ?
>
> that very well can be the difference
>
> > but if you think about it, how could the system allow the user to
> > modify a file that he don't own it and he don't have write privilege
> > on the file just because he has write in the parent directory ?
> >
> > Maybe I'm wrong, but is this normal ? please let me know
>
> this is normal and a result of the linux permission model.
> (and fwiw you don't get to edit the file, only to create a new file. You
> may think that's exactly the same.. but it's not in the light of
> hardlinks)
>
> Btw there is a "sticky bit" you can set on the directory which changes this behavior,
> for example /tmp has this set for obvious reasons
>
> > BTW: is there any document, article or any page about this so I can
> > show it to my boss :)
>
> I suspect the SUS standard fully specifies the 4 rules I mentioned and
> the sticky-exception (and the rest is an obvious result)
>
>
>


--
Best Regards,
--------------------
-*- If Linux doesn't have the solution, you have the wrong problem -*-

Re: FS possible security exposure ?

[Trond Myklebust]

On Sun, 2005-12-25 at 12:29 +0300, regatta wrote:
> Hi everyone,
> 
> I have a question regarding how Linux handle the files permission ,
> here is what I found
> 
> When logged on to a Linux workstation a user can edit a file (even if
> the file on an NFS-mounted NAS directory) if he has write access at
> the directory level, even if the file is owned by root (or any other
> user) and is read-only.

Since you do not explain how you performed the test, it is hard to
comment, but I don't see this behaviour you describe:

trondmy@lade test$ ls -al
total 12
drwxrwxrwx   2 root root 4096 2005-12-25 10:42 .
drwxrwxrwt  10 root root 4096 2005-12-25 10:41 ..
-rw-r--r--   1 root root    5 2005-12-25 10:42 test
trondmy@lade test$ cat >test
bash: test: Permission denied


If I use 'vi' to edit the file, then it can be modified, but the way vi
does that is to delete the old file, and create a new one with the same
name (and it will only do this if you use 'w!'). That should ordinarily
work on Solaris too.

Cheers,
  Trond