suid bit on directories

suid bit on directories

[Michael Hoennig]

Hello!

I am new on this list and thoroughly searched the FAQ, the archives and
the web for this question, but couldn't find anything.

We wondererd why setting the guid bit on a directory makes all new files
owned by the group of the directory, but this does not work for the suid
bit, making new files owned by the owner of the directory.

It would be a good solution to make files created by Apaches mod_php in
safe-mode, not owned by web:web (or httpd:httpd or somethign) anymore, but
the Owner of the directory. 

I do not even see a security hole if nobody other than the user itself and
httpd/web can reach this area in the file system, anyway. And it is still
the users decision that files in this (his) directory should belong to
him.

It seems, this has to be patched for each file system separately, right?
For example in linux/fs/ext2/ialloc.c.

Actually, the suid bit on directories works at least under FreeBSD. Is
there any reason, why it does not work under Linux?

Thanks
	Michael

-- 
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg
phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426
http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht

Re: suid bit on directories

[Cedric Ware]

> I do not even see a security hole if nobody other than the user itself and
> httpd/web can reach this area in the file system, anyway. And it is still
> the users decision that files in this (his) directory should belong to
> him.

I guess it is considered a security hole if a user can create files not
belonging to him.

> Actually, the suid bit on directories works at least under FreeBSD. Is

Not under 4.x (nor OpenBSD 2.9); or did I do anything wrong?

krakatoa ~ % uname -a
FreeBSD krakatoa.tectonics 4.5-STABLE FreeBSD 4.5-STABLE #13: Thu Mar 28 01:12:06 CET 2002     ware@krakatoa.tectonics:/local/usr/obj/usr/src/sys/KRAKATOA  i386
krakatoa ~ % whoami
ware
krakatoa ~ % cd /tmp
krakatoa /tmp % mkdir xx
krakatoa /tmp % sudo chown root.bin xx
krakatoa /tmp % sudo chmod 6777 xx
krakatoa /tmp % touch xx/yy
krakatoa /tmp % ls -la xx
total 4
drwsrwsrwx   2 root     bin           512 May 18 10:47 .
drwxrwxrwt  20 root     wheel        3072 May 18 10:47 ..
-rw-r--r--   1 ware     bin             0 May 18 10:47 yy
krakatoa /tmp % 

						Cheers,
						Cedric Ware.

Re: suid bit on directories

[Michael Hoennig]

Hi Cedric,

> > I do not even see a security hole if nobody other than the user itself
> > and httpd/web can reach this area in the file system, anyway. And it
> > is still the users decision that files in this (his) directory should
> > belong to him.
> 
> I guess it is considered a security hole if a user can create files not
> belonging to him.

where is it so much different from the guid flat on directories?  That way
too, you could get rights of a group of which you are not a member.  As
far as I can see, all what has to be prevented, is to create files with
suid flag set within such a folder - not even for a microsecond
(race-condition).  Or do I miss something?  Other issues are quota, but
this problem already exists with guid bit for directories.  And in my case
(mod_php), it is even worse the way it is.

> > Actually, the suid bit on directories works at least under FreeBSD. Is
> 
> Not under 4.x (nor OpenBSD 2.9); or did I do anything wrong?

OpenBSD is extremely carefully about security issues.  Thus, it might not
work at all in OpenBSD.  But it works under FreeBSD (as an option which
has to be compiled into the kernel).  This is exactly what I would like to
have for Linux.

	Michael

-- 
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg
phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426
http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht

Re: suid bit on directories

[jw schultz]

On Sat, May 18, 2002 at 12:34:35PM +0200, Michael Hoennig wrote:
> Hi Cedric,
> 
> > > I do not even see a security hole if nobody other than the user itself
> > > and httpd/web can reach this area in the file system, anyway. And it
> > > is still the users decision that files in this (his) directory should
> > > belong to him.
> > 
> > I guess it is considered a security hole if a user can create files not
> > belonging to him.
> 
> where is it so much different from the guid flat on directories?  That way
> too, you could get rights of a group of which you are not a member.  As

You don't get the rights of the group.  This only allows the
file/directory you could have created anyway to be created with the
gid of the parent.  And you still are the owner so it can be
seen who is responsible for it existing.

The only possible way non-members could do this would be if
the directory has dangerous^Wrisky permissions allowing non-group
members to write in it.

I use sgid directories frequently.  Usually with
user-private-groups and umask of 002. It keeps lusers from
misusing chmod.

> far as I can see, all what has to be prevented, is to create files with
> suid flag set within such a folder - not even for a microsecond

_Please_ don't describe it this way.  We don't want any
files any time to be created with suid flag set
automatically.  Describe it as "the suid flag set _on_ the
directory" or "suid directory", etc.

> (race-condition).  Or do I miss something?  Other issues are quota, but
> this problem already exists with guid bit for directories.  And in my case
> (mod_php), it is even worse the way it is.

Group quotas are used even less than user quotas so i don't
consider them much of an issue (someone else probably does).
What i do consider an issue is user accountability.  There
are reasons besides quota only root can chown.

You haven't articulated how doing this would be of benefit to
anyone.  Leaving that aside you could work up a patch to
allow this behaviour.

Features would be:

	1 a non-default mount option. 

	2 either incompatible with quota or throwing up
 	  warnings if quota is enabled.

	3 ineffective if the directory is also sticky.

Personally i don't care for the idea but, hey, you can try.
As long as it doesn't become a default it won't affect me.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: suid bit on directories

[Jesse Pollard]

Michael Hoennig <michael@hostsharing.net>:
> 
> Hello!
> 
> I am new on this list and thoroughly searched the FAQ, the archives and
> the web for this question, but couldn't find anything.
> 
> We wondererd why setting the guid bit on a directory makes all new files
> owned by the group of the directory, but this does not work for the suid
> bit, making new files owned by the owner of the directory.

The setgid bit on a directory is to support BSD activities. It used to be
used for mail delivery.

> It would be a good solution to make files created by Apaches mod_php in
> safe-mode, not owned by web:web (or httpd:httpd or somethign) anymore, but
> the Owner of the directory. 

No. You loose the fact that the file was NOT created by the user.

> I do not even see a security hole if nobody other than the user itself and
> httpd/web can reach this area in the file system, anyway. And it is still
> the users decision that files in this (his) directory should belong to
> him.

1. users will steal/bypass quota controls

2. Consider what happens if a user creates a file in such a directory and
   it is executable. - since the file is fully owned by a different user, it
   appears to have been created by that user. What protection mask is on
   the file? Can the creator (not owner) make it setuid? (nasty worm
   propagation method)

> It seems, this has to be patched for each file system separately, right?
> For example in linux/fs/ext2/ialloc.c.
> 
> Actually, the suid bit on directories works at least under FreeBSD. Is
> there any reason, why it does not work under Linux?

I don't believe it is in the POSIX definition.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: suid bit on directories

[Michael Hoennig]

Hi Jesse,

> The setgid bit on a directory is to support BSD activities. It used to
> be used for mail delivery.

this is actually similar usage to my example:

> > It would be a good solution to make files created by Apaches mod_php
> > in safe-mode, not owned by web:web (or httpd:httpd or somethign)
> > anymore, but the Owner of the directory. 
> 
> No. You loose the fact that the file was NOT created by the user.

the user in my example above would be wwwrun or httpd - and that does not
make any sense at all! It would make much more sense if the new files
belonged to the owner of the directory, who is the one who owns the
virtual host.

> > I do not even see a security hole if nobody other than the user itself
> > and httpd/web can reach this area in the file system, anyway. And it
> > is still the users decision that files in this (his) directory should
> > belong to him.
> 
> 1. users will steal/bypass quota controls

Not in my example - acutally even the other way around.

> 2. Consider what happens if a user creates a file in such a directory
> and   it is executable. - since the file is fully owned by a different
> user, it   appears to have been created by that user. What protection
> mask is on   the file? Can the creator (not owner) make it setuid?
> (nasty worm   propagation method)

Again: it depends on the usage. In my case it is the other way around. A
use should know what he is doing if he is setting this flag on a
directory.  And making such files suid again, has to be prevented by the
code - that I even mentioned in my first mail on this issue.

> > Actually, the suid bit on directories works at least under FreeBSD. Is
> > there any reason, why it does not work under Linux?
> 
> I don't believe it is in the POSIX definition.

I only said, it works under FreeBSD, it is an option there.

	Michael

-- 
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg
phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426
http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht

Re: suid bit on directories

[Jesse Pollard]

Michael Hoennig <michael@hostsharing.net>:
> 
> Hi Jesse,
> 
> > The setgid bit on a directory is to support BSD activities. It used to
> > be used for mail delivery.
> 
> this is actually similar usage to my example:
> 
> > > It would be a good solution to make files created by Apaches mod_php
> > > in safe-mode, not owned by web:web (or httpd:httpd or somethign)
> > > anymore, but the Owner of the directory. 
> > 
> > No. You loose the fact that the file was NOT created by the user.
> 
> the user in my example above would be wwwrun or httpd - and that does not
> make any sense at all! It would make much more sense if the new files
> belonged to the owner of the directory, who is the one who owns the
> virtual host.

You can't tell who the user is. ANY user would be able to do that.

> > > I do not even see a security hole if nobody other than the user itself
> > > and httpd/web can reach this area in the file system, anyway. And it
> > > is still the users decision that files in this (his) directory should
> > > belong to him.
> > 
> > 1. users will steal/bypass quota controls
> 
> Not in my example - acutally even the other way around.

And just how is it prevented? quotas are applied based on either group
or user. Normally it is based on user. Once the uid is set, then the
quotas start being deducted. If the the user procedes to store 10 G of
music files, who is charged? And how do you know who put them there.

> > 2. Consider what happens if a user creates a file in such a directory
> > and   it is executable. - since the file is fully owned by a different
> > user, it   appears to have been created by that user. What protection
> > mask is on   the file? Can the creator (not owner) make it setuid?
> > (nasty worm   propagation method)
> 
> Again: it depends on the usage. In my case it is the other way around. A
> use should know what he is doing if he is setting this flag on a
> directory.  And making such files suid again, has to be prevented by the
> code - that I even mentioned in my first mail on this issue.

How are you going to control it?

> > > Actually, the suid bit on directories works at least under FreeBSD. Is
> > > there any reason, why it does not work under Linux?
> > 
> > I don't believe it is in the POSIX definition.
> 
> I only said, it works under FreeBSD, it is an option there.

Then use FreeBSD.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: suid bit on directories

[Michael Hoennig]

Hi Jesse,

> > > No. You loose the fact that the file was NOT created by the user.
> > 
> > the user in my example above would be wwwrun or httpd - and that does
> > not make any sense at all! It would make much more sense if the new
> > files belonged to the owner of the directory, who is the one who owns
> > the virtual host.
> 
> You can't tell who the user is. ANY user would be able to do that.

of course not, but many features have to be used carefully, like the suid
bit on files too! 

I don't want to make the bahaviour or a suid bit on directories the
default! I just would like it as a mount option, or even something which
you have to compile into the kernel.

> > > > I do not even see a security hole if nobody other than the user
> > > > itself and httpd/web can reach this area in the file system,
> > > > anyway. And it is still the users decision that files in this
> > > > (his) directory should belong to him.
> > > 
> > > 1. users will steal/bypass quota controls
> > 
> > Not in my example - acutally even the other way around.
> 
> And just how is it prevented? quotas are applied based on either group
> or user. Normally it is based on user. Once the uid is set, then the
> quotas start being deducted. If the the user procedes to store 10 G of
> music files, who is charged? And how do you know who put them there.

Why do you ignore my example? In my example the use who runs the webserver
owns all the files, that is wrong. With the suid bit on directories, this
could be fixed. 

> > > 2. Consider what happens if a user creates a file in such a
> > > directory and   it is executable. - since the file is fully owned by
> > > a different user, it   appears to have been created by that user.
> > > What protection mask is on   the file? Can the creator (not owner)
> > > make it setuid?(nasty worm   propagation method)
> > 
> > Again: it depends on the usage. In my case it is the other way around.
> > A use should know what he is doing if he is setting this flag on a
> > directory.  And making such files suid again, has to be prevented by
> > the code - that I even mentioned in my first mail on this issue.
> 
> How are you going to control it?

Only the owner of the directories can set this flag. There is nothing to
control. 

UNIX users are able to give rights to everybody to their files, right? How
do you control that?

You don't! You just let it to the users to give access to there files to
whomever you want. My case is similar.

> > > > Actually, the suid bit on directories works at least under
> > > > FreeBSD. Is there any reason, why it does not work under Linux?
> > > 
> > > I don't believe it is in the POSIX definition.
> > 
> > I only said, it works under FreeBSD, it is an option there.
> 
> Then use FreeBSD.

No comment.

	Michael

-- 
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg
phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426
http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht

Re: suid bit on directories

[Bill Davidsen]

On Mon, 20 May 2002, Jesse Pollard wrote:

> Michael Hoennig <michael@hostsharing.net>:

> > We wondererd why setting the guid bit on a directory makes all new files
> > owned by the group of the directory, but this does not work for the suid
> > bit, making new files owned by the owner of the directory.
> 
> The setgid bit on a directory is to support BSD activities. It used to be
> used for mail delivery.
> 
> > It would be a good solution to make files created by Apaches mod_php in
> > safe-mode, not owned by web:web (or httpd:httpd or somethign) anymore, but
> > the Owner of the directory. 
> 
> No. You loose the fact that the file was NOT created by the user.

  What's your point here? Obviously the owner of the directory wants it
that way. Linux is about choices, Windows is about "we know best." Like
creating a set-uid file it can be misused, but I ran mail on SCO for years
set-uid mail (not root) as an access control.
 
> > I do not even see a security hole if nobody other than the user itself and
> > httpd/web can reach this area in the file system, anyway. And it is still
> > the users decision that files in this (his) directory should belong to
> > him.
> 
> 1. users will steal/bypass quota controls

  How? The quota should work just as well, the code doesn't seem to care
how the owner was set, just who owns the file. I can think of several
groupware applications for using a group to get write, and having the
files owned by the uid of the application. "chmod 4775 shared_dir" comes
to mind. Yes, it has a sharp edge, you could do something dumb. See above
on o/s philosophy. And this may result in quota being correctly applied to
the filespace of a project rather than on individuals who may be creating
files in many places, some not releated to a given project.

> 2. Consider what happens if a user creates a file in such a directory and
>    it is executable. - since the file is fully owned by a different user, it
>    appears to have been created by that user. What protection mask is on
>    the file? Can the creator (not owner) make it setuid? (nasty worm
>    propagation method)

  Clearly the owner is the owner, and the creator is just another user
after the file is created.

> > Actually, the suid bit on directories works at least under FreeBSD. Is
> > there any reason, why it does not work under Linux?
> 
> I don't believe it is in the POSIX definition.

  Neither is clone() and a lot of other stuff. I would say that if POSIX
mandates behaviour or features Linux should follow, if POSIX forbids it
should be forbidden, and everything else is up for discussion. (for
discussion read SuS for POSIX if you care).

  I think the feature is a config option at kernel build time in BSD, but
I didn't go refresh my dusty memory.

  Useful tools are often dangerous, this would seem to be one of those
cases. Linux already has more cutting edges than a Swiss Army Knife, and I
think you have enumerated the dangers in this features. I don't see any
which are subtle.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: suid bit on directories

[Bill Davidsen]

On Mon, 20 May 2002, Jesse Pollard wrote:

> Michael Hoennig <michael@hostsharing.net>:

> > > 1. users will steal/bypass quota controls
> > 
> > Not in my example - acutally even the other way around.
> 
> And just how is it prevented? quotas are applied based on either group
> or user. Normally it is based on user. Once the uid is set, then the
> quotas start being deducted. If the the user procedes to store 10 G of
> music files, who is charged? And how do you know who put them there.

  I won't repeat my previous, but obviously the owner of the file is
charged, and (b) if you care who put it there don't have a directory like
that. If you are a control freak you don't create the directory in the
first place. The behaviour is a feature not a problem.
 
> > > 2. Consider what happens if a user creates a file in such a directory
> > > and   it is executable. - since the file is fully owned by a different
> > > user, it   appears to have been created by that user. What protection
> > > mask is on   the file? Can the creator (not owner) make it setuid?
> > > (nasty worm   propagation method)
> > 
> > Again: it depends on the usage. In my case it is the other way around. A
> > use should know what he is doing if he is setting this flag on a
> > directory.  And making such files suid again, has to be prevented by the
> > code - that I even mentioned in my first mail on this issue.
> 
> How are you going to control it?

  The code is already in place to remove the setuid bit when changing
the owner of a file. I don't see more than an AND on the permissions in
creat() to provide this protection as the owner is changed.
 
> > > > Actually, the suid bit on directories works at least under FreeBSD. Is
> > > > there any reason, why it does not work under Linux?
> > > 
> > > I don't believe it is in the POSIX definition.
> > 
> > I only said, it works under FreeBSD, it is an option there.
> 
> Then use FreeBSD.

  If developers had taken that approach to suggestions for enhancements in
network code people would, and Linux would be saddled with the 1.x network
code (shudder). Ditto journaling, bitmapped filesystems, etc. All started
from features in other operating systems. To reverse your idea, if you
don't want progress stay with 2.2.xx and don't read a DEVELOPMENT list.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
"He stood across the path of progress, loudly crying HALT!"

Re: suid bit on directories

[dean gaudet]

On Mon, 20 May 2002, Michael Hoennig wrote:

> Why do you ignore my example? In my example the use who runs the webserver
> owns all the files, that is wrong. With the suid bit on directories, this
> could be fixed.

CAP_FCHOWN would appear to accomplish what you need (with the bonus of
already existing in modern linux kernels)... the webserver should be able
to chown away a file if it's given this capability.

-dean

Re: suid bit on directories

[Albert D. Cahalan]

Jesse Pollard writes:
> Michael Hoennig <michael@hostsharing.net>:
>> [Jesse Pollard???]

>>> No. You loose the fact that the file was NOT created by the user.
>>
>> the user in my example above would be wwwrun or httpd - and that does not
>> make any sense at all! It would make much more sense if the new files
>> belonged to the owner of the directory, who is the one who owns the
>> virtual host.
>
> You can't tell who the user is. ANY user would be able to do that.

If you have a setuid directory, then you accept responsibility
for anything that other people place in that directory.

If you are the admin, you hold the owner of a setuid directory
responsible for everything that gets put in it.

>>>> I do not even see a security hole if nobody other than the user itself
>>>> and httpd/web can reach this area in the file system, anyway. And it
>>>> is still the users decision that files in this (his) directory should
>>>> belong to him.
>>>
>>> 1. users will steal/bypass quota controls
>>
>> Not in my example - acutally even the other way around.
>
> And just how is it prevented? quotas are applied based on either group
> or user. Normally it is based on user. Once the uid is set, then the
> quotas start being deducted. If the the user procedes to store 10 G of
> music files, who is charged? And how do you know who put them there.

Duh, this is a web server.

If you really don't understand, then read up on dynamic
web stuff and web authentication:

cgi-bin, PHP, WebDAV, Java servlets, SSL...

>>> 2. Consider what happens if a user creates a file in such a directory
>>> and it is executable. - since the file is fully owned by a different
>>> user, it appears to have been created by that user. What protection
>>> mask is on the file? Can the creator (not owner) make it setuid?
>>> (nasty worm propagation method)

Oh please. Do you know that Linux supports a setgid bit
on directories? Well, it does, just the same as SysV.
Go ahead, try to get setgid for a group you aren't in.
Linux will even take away your setuid bit for trying.

Re: suid bit on directories

[Jesse Pollard]

Michael Hoennig <michael@hostsharing.net>:
> Hi Jesse,
> 
> > > > No. You loose the fact that the file was NOT created by the user.
> > > 
> > > the user in my example above would be wwwrun or httpd - and that does
> > > not make any sense at all! It would make much more sense if the new
> > > files belonged to the owner of the directory, who is the one who owns
> > > the virtual host.
> > 
> > You can't tell who the user is. ANY user would be able to do that.
> 
> of course not, but many features have to be used carefully, like the suid
> bit on files too!

That CAN be audited. Putting a suid on a directory CAN'T.

> I don't want to make the bahaviour or a suid bit on directories the
> default! I just would like it as a mount option, or even something which
> you have to compile into the kernel.

Once mounted/compiled in you have lost control.

> > > > > I do not even see a security hole if nobody other than the user
> > > > > itself and httpd/web can reach this area in the file system,
> > > > > anyway. And it is still the users decision that files in this
> > > > > (his) directory should belong to him.
> > > > 
> > > > 1. users will steal/bypass quota controls
> > > 
> > > Not in my example - acutally even the other way around.
> > 
> > And just how is it prevented? quotas are applied based on either group
> > or user. Normally it is based on user. Once the uid is set, then the
> > quotas start being deducted. If the the user procedes to store 10 G of
> > music files, who is charged? And how do you know who put them there.
> 
> Why do you ignore my example? In my example the use who runs the webserver
> owns all the files, that is wrong. With the suid bit on directories, this
> could be fixed. 

That is NOT wrong. The files belong to the server. Not a user. I've been
running a server that way for years.

And ANY user can put files into YOUR directory. Even files you don't want
there. AND you can't tell who did it.

Remember - with this facility any penetration of of a server suddenly becomes a
penetration of every user with such a directory.

> > > > 2. Consider what happens if a user creates a file in such a
> > > > directory and   it is executable. - since the file is fully owned by
> > > > a different user, it   appears to have been created by that user.
> > > > What protection mask is on   the file? Can the creator (not owner)
> > > > make it setuid?(nasty worm   propagation method)
> > > 
> > > Again: it depends on the usage. In my case it is the other way around.
> > > A use should know what he is doing if he is setting this flag on a
> > > directory.  And making such files suid again, has to be prevented by
> > > the code - that I even mentioned in my first mail on this issue.
> > 
> > How are you going to control it?
> 
> Only the owner of the directories can set this flag. There is nothing to
> control. 

Ah - so I can put files into your directory, and suddenly they are owned
by you. Remember that the next time you are convicted of piracy with criminal
data in your directory.... (DMCA remember - and saying "Those files are not
mine" just doesn't cut it, when obviously they have your uid on them; the
best you would work them down to is "contributing to piracy").

Also remember what happens when a hard link is created in the directory...
The file changes ownership. That will then change the owner of ANY file
on the filesystem. I believe this can happen with sgid directories too
(which would be another reason that mail spool directories were supposed
to be on their own file system).

> UNIX users are able to give rights to everybody to their files, right? How
> do you control that?

MLS/compartmentalization. See SELinux. See mandatory access controls.

Also put users in filesystems where the parent directory only permits
group access: mode 0550. No user outside the group will be able to access
the files, even if the user does grant access. Details:

	sample		- mode 0550
          |
         users          - mode 0555

Only members of the group, or owners will be able to see files in the
directory "users", even though the owner of that directory has granted
world rx access.
 
> You don't! You just let it to the users to give access to there files to
> whomever you want. My case is similar.

NOT the same situation. The OWNER of the file gives ACCESS to files. Not
a user making their files owned by someone else (unless that user
is root). Even giving someone else the ability to create files in your
directory is dangerous, though possible. At least it is still possible to
determine WHO put them there.

This was explicitly removed to prevent quota corruption - the history
of chown originally allowed changing the ownership of a file to anyone in
the system (when done, it did remove setuid from the file). This was
removed under the "prevention of a denial of service" attack.

> > > > > Actually, the suid bit on directories works at least under
> > > > > FreeBSD. Is there any reason, why it does not work under Linux?
> > > > 
> > > > I don't believe it is in the POSIX definition.
> > > 
> > > I only said, it works under FreeBSD, it is an option there.
> > 
> > Then use FreeBSD.
> 
> No comment.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: suid bit on directories

[Jesse Pollard]

"Albert D. Cahalan" <acahalan@cs.uml.edu>:
> Jesse Pollard writes:
> > Michael Hoennig <michael@hostsharing.net>:
> >> [Jesse Pollard???]
> 
> >>> No. You loose the fact that the file was NOT created by the user.
> >>
> >> the user in my example above would be wwwrun or httpd - and that does not
> >> make any sense at all! It would make much more sense if the new files
> >> belonged to the owner of the directory, who is the one who owns the
> >> virtual host.
> >
> > You can't tell who the user is. ANY user would be able to do that.
> 
> If you have a setuid directory, then you accept responsibility
> for anything that other people place in that directory.
> 
> If you are the admin, you hold the owner of a setuid directory
> responsible for everything that gets put in it.
> 
> >>>> I do not even see a security hole if nobody other than the user itself
> >>>> and httpd/web can reach this area in the file system, anyway. And it
> >>>> is still the users decision that files in this (his) directory should
> >>>> belong to him.
> >>>
> >>> 1. users will steal/bypass quota controls
> >>
> >> Not in my example - acutally even the other way around.
> >
> > And just how is it prevented? quotas are applied based on either group
> > or user. Normally it is based on user. Once the uid is set, then the
> > quotas start being deducted. If the the user procedes to store 10 G of
> > music files, who is charged? And how do you know who put them there.
> 
> Duh, this is a web server.

A web server is just a user.

> If you really don't understand, then read up on dynamic
> web stuff and web authentication:
> 
> cgi-bin, PHP, WebDAV, Java servlets, SSL...

so? And each has been penetrated before.

This is no improvement. It is a step backward to when chown would give
a file to any user. It was used several times to attack quotas, several
times to hack systems.

> >>> 2. Consider what happens if a user creates a file in such a directory
> >>> and it is executable. - since the file is fully owned by a different
> >>> user, it appears to have been created by that user. What protection
> >>> mask is on the file? Can the creator (not owner) make it setuid?
> >>> (nasty worm propagation method)
> 
> Oh please. Do you know that Linux supports a setgid bit
> on directories? Well, it does, just the same as SysV.
> Go ahead, try to get setgid for a group you aren't in.
> Linux will even take away your setuid bit for trying.

Yup. and it depends on where the setuid is as to whether it is taken
away.

It would be much better to get ACLs to support this, which I think all
of the implementations of ACLs do.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: suid bit on directories

[Miquel van Smoorenburg]

In article <200205201928.OAA13328@tomcat.admin.navo.hpc.mil>,
Jesse Pollard  <pollard@tomcat.admin.navo.hpc.mil> wrote:
>And ANY user can put files into YOUR directory. Even files you don't want
>there. AND you can't tell who did it.

A setuid bit on a directory doesn't mean it syddenly has
rwxrwxrwx permissions. You still need permission to create the
file as usual. Try playing with a setgid directory one day.
It behaves the same.

>> Only the owner of the directories can set this flag. There is nothing to
>> control. 
>
>Ah - so I can put files into your directory, and suddenly they are owned
>by you. Remember that the next time you are convicted of piracy with criminal
>data in your directory.... (DMCA remember - and saying "Those files are not
>mine" just doesn't cut it, when obviously they have your uid on them; the
>best you would work them down to is "contributing to piracy").

It would be stupid to have a setuid directory world writable. You'd
probably make it group writab;e. Then only people in that group have
access to create files, so the files aren't anonymous - they were
created by someone in that group.

>Also remember what happens when a hard link is created in the directory...
>The file changes ownership.

Adding an extra directory entry for a file doesn't change
the inode (well, the link count is bumped up by one) in any way.

Mike.
-- 
"Insanity -- a perfectly rational adjustment to an insane world."
  - R.D. Lang

Re: suid bit on directories

[Michael Hoennig]

Hi Jesse,

> > of course not, but many features have to be used carefully, like the
> > suid bit on files too!
> 
> That CAN be audited. Putting a suid on a directory CAN'T.

Of course it can. You can easily list all files with this flag set.

> > I don't want to make the bahaviour or a suid bit on directories the
> > default! I just would like it as a mount option, or even something
> > which you have to compile into the kernel.
> 
> Once mounted/compiled in you have lost control.

How do you come to that conclusion? Even if it were the case: I don't
force you to use this mount option.

> > Why do you ignore my example? In my example the use who runs the
> > webserver owns all the files, that is wrong. With the suid bit on
> > directories, this could be fixed. 
> 
> That is NOT wrong. The files belong to the server. Not a user. I've been
> running a server that way for years.

Files can only belong to users, not to server processes.

> And ANY user can put files into YOUR directory. Even files you don't
> want there. AND you can't tell who did it.

Nope. Only httpd and the user who should onw the files (the User of the
VirtualHost) can reach the directory in my case. Nobody else can even
reach it.

> Remember - with this facility any penetration of of a server suddenly
> becomes a penetration of every user with such a directory.

With the rights of wwwrun/httpd you can do more damange in this case than
with the rights of one user. In this case that are  special accounts for
running CGIs etc. 

> > > How are you going to control it?
> > 
> > Only the owner of the directories can set this flag. There is nothing
> > to control. 
> 
> Ah - so I can put files into your directory, and suddenly they are owned
> by you. 

You would not even reach this directory. That is assured because it is
child of a dir owned by me:httpd which is child of a directory owned by
httpd:mygroup - in neither case rights for others.

> Also remember what happens when a hard link is created in the
> directory... The file changes ownership. That will then change the owner
> of ANY file on the filesystem. I believe this can happen with sgid
> directories too

good point to pay attention to, but you are wrong


> > You don't! You just let it to the users to give access to there files
> > to whomever you want. My case is similar.
> 
> NOT the same situation. The OWNER of the file gives ACCESS to files. 

I coudl set up a cronjob which copies the files in the directories and
deletes the originals. It's the same, just delayed.

Anyway, when I find time in the next weeks, I will try this patch and post
it.  I will do it as a mount option.  Nobody is forced to use it ;-)

	Michael

-- 
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg
phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426
http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht

Re: suid bit on directories

[Dax Kelson]

On Mon, 20 May 2002, Jesse Pollard wrote:

> > > No. You loose the fact that the file was NOT created by the user.
> > 
> > the user in my example above would be wwwrun or httpd - and that does not
> > make any sense at all! It would make much more sense if the new files
> > belonged to the owner of the directory, who is the one who owns the
> > virtual host.
> 
> You can't tell who the user is. ANY user would be able to do that.

Bzzzt.  Only if the permissions permitted it.


Example 1:

/home/bob/public_html

public_html  is user/group  bob/httpd

the perms are 2770

============================

Example 2:

All users on the system have a primary or secondary group "users"

/home/bob   user/group  bob/users

perms are 701

This explictly denies "users", yet allows Apache in (since it is running 
as httpd).

Re: suid bit on directories

[Dax Kelson]

On Mon, 20 May 2002, Jesse Pollard wrote:

> That is NOT wrong. The files belong to the server. Not a user. I've been
> running a server that way for years.

This is insecure.

A user has a defined security context.  If the user can create code that 
is then executed in a different security context (user httpd/nobody), then 
you've got a potential problem.  If you have multiple users who can 
create code that executes in the *same* security context, you have a 
recipe for disaster.

user1 can write a web app the delete/modifies the web app, or web app 
created files of user2.

Dax Kelson
Guru Labs

Re: suid bit on directories

[Dax Kelson]

On Mon, 20 May 2002, Dax Kelson wrote:

> Example 1:
> 
> /home/bob/public_html
> 
> public_html  is user/group  bob/httpd
> 
> the perms are 2770

I meant 4770 since we are discussing a hypothetical SUID directory.

Re: suid bit on directories

[Jesse Pollard]

Dax Kelson <dax@gurulabs.com>
> On Mon, 20 May 2002, Jesse Pollard wrote:
> 
> > > > No. You loose the fact that the file was NOT created by the user.
> > > 
> > > the user in my example above would be wwwrun or httpd - and that does not
> > > make any sense at all! It would make much more sense if the new files
> > > belonged to the owner of the directory, who is the one who owns the
> > > virtual host.
> > 
> > You can't tell who the user is. ANY user would be able to do that.
> 
> Bzzzt.  Only if the permissions permitted it.
> 
> 
> Example 1:
> 
> /home/bob/public_html
> 
> public_html  is user/group  bob/httpd
> 
> the perms are 2770
> 
> ============================
> 
> Example 2:
> 
> All users on the system have a primary or secondary group "users"
> 
> /home/bob   user/group  bob/users
> 
> perms are 701
> 
> This explictly denies "users", yet allows Apache in (since it is running 
> as httpd).


And if "bob" makes the file world readable it can't be read by someone else?
And if the file is supposed to be updated by the web server it can't be
created (truncated, unless also world writeable)? If not, then his implies that
besides changing the owner of created files, the changed owner is also
used to verify authorization to create.

Granted, this limits the identity of the attacker to anyone in the group
httpd or the user.

And the world x doesn't grant access? (have you seen the attempts to get
a "open file by inode" added? very usefull for file migration - and almost
mandatatory for performance reasons. And also usefull for attacks.
Fortunately, it isn't there yet, and hopefully it will be restricted).

The attacker may not be able to read the directory, but he can certanly
attack it by just creating/opening files in the home directory. That could gain 
access to OTHER files in the home directory.

You also have problems with backup/restore done by users. Tar/cpio will/can
change the group ownership of the directory, and will change group ownership
of any files/subdirectories restored. Even cp would cause problems
by preventing the web server from access (again, it must be created world
readable). Also exposes potential damage in crash situations (though not
as bad as external attack - lost files become world accessable).

ACLs would be much easer to support. Try them out..

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: suid bit on directories

[Jesse Pollard]

Dax Kelson <dax@gurulabs.com>:
> 
> On Mon, 20 May 2002, Jesse Pollard wrote:
> 
> > That is NOT wrong. The files belong to the server. Not a user. I've been
> > running a server that way for years.
> 
> This is insecure.
> 
> A user has a defined security context.  If the user can create code that 
> is then executed in a different security context (user httpd/nobody), then 
> you've got a potential problem.  If you have multiple users who can 
> create code that executes in the *same* security context, you have a 
> recipe for disaster.

correct.

> user1 can write a web app the delete/modifies the web app, or web app 
> created files of user2.

Exactly what you get when the owner is hidden. Whose app got executed
that created/destroyed someone elses files? What files were created?

It all runs under the web server account... but the results are owned by
the attacked user so it looks like the user did it. Anything a CGI can
create, a CGI can execute or cause to be executed.

If you want a secured web server, DON'T let users create CGI. and don't
give the CGI the capability to execute other programs either. And this
is where compartmentalization comes into play.

All you know is that maybe the attack was via a web server. But you can't tell.

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

Re: suid bit on directories

[Bill Davidsen]

On Mon, 20 May 2002, dean gaudet wrote:

> On Mon, 20 May 2002, Michael Hoennig wrote:
> 
> > Why do you ignore my example? In my example the use who runs the webserver
> > owns all the files, that is wrong. With the suid bit on directories, this
> > could be fixed.
> 
> CAP_FCHOWN would appear to accomplish what you need (with the bonus of
> already existing in modern linux kernels)... the webserver should be able
> to chown away a file if it's given this capability.

This is a useful point, but doesn't address the intent of the original
proposal. The solution you propose gives VERY powerful capabilities to a
process, and if I undestand how it works gives them in every directory.

By putting them on a single directory like setgid, you allow any tool to
operate on files in the directory, given that the process has directory
access to do so. Think "groupware" and people working on a project.

Both are useful, of course, but they are NOT alternative solutions to the
same problem, but solutions to two problems.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: suid bit on directories

[Bill Davidsen]

On Mon, 20 May 2002, Michael Hoennig wrote:

> Anyway, when I find time in the next weeks, I will try this patch and post
> it.  I will do it as a mount option.  Nobody is forced to use it ;-)

If I might offer a suggestion, that requires a patched mount command, etc.
I would offer as an alternative implementation which might be both easier
to do and more useful in testing. Make the capability an option in the
kernel, and then require that it be enabled in /proc/sys with default off.
Think TCP_SYN_COOKIES or similar. That way you can have a single patch set
for the kernel only, and no one can possibly "stumble on it" and complain.
Also, you can disable without reboot or remount after testing.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: suid bit on directories

[Bill Davidsen]

On Mon, 20 May 2002, Dax Kelson wrote:

> On Mon, 20 May 2002, Dax Kelson wrote:
> 
> > Example 1:
> > 
> > /home/bob/public_html
> > 
> > public_html  is user/group  bob/httpd
> > 
> > the perms are 2770
> 
> I meant 4770 since we are discussing a hypothetical SUID directory.

I would expect public_html to be 4775 or 4771 if it's to be any use at
all. Otherwise why have it?

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: suid bit on directories

[J Sloan]

Bill Davidsen wrote:

>On Mon, 20 May 2002, Dax Kelson wrote:
>
>  
>
>>On Mon, 20 May 2002, Dax Kelson wrote:
>>
>>    
>>
>>>Example 1:
>>>
>>>/home/bob/public_html
>>>
>>>public_html  is user/group  bob/httpd
>>>
>>>the perms are 2770
>>>      
>>>
>>I meant 4770 since we are discussing a hypothetical SUID directory.
>>    
>>
>
>I would expect public_html to be 4775 or 4771 if it's to be any use at all. Otherwise why have it?
>  
>

Yes, it would have to have httpd group ownership
or it would be totally inaccessible - and it would
be difficult for a non-root user to assign such grp
ownership....

Joe

Re: suid bit on directories

[Michael Hoennig]

Hi Bill,

> > Anyway, when I find time in the next weeks, I will try this patch and
> > post it.  I will do it as a mount option.  Nobody is forced to use it
> > ;-)
> 
> If I might offer a suggestion, that requires a patched mount command,
> etc. I would offer as an alternative implementation which might be both
> easier to do and more useful in testing. Make the capability an option
> in the kernel, and then require that it be enabled in /proc/sys with
> default off. Think TCP_SYN_COOKIES or similar. That way you can have a
> single patch set for the kernel only, and no one can possibly "stumble
> on it" and complain. Also, you can disable without reboot or remount
> after testing.

Good idea; I will consider it.  

	Michael

-- 
Hostsharing eG / c/o Michael Hönnig / Boytinstr. 10 / D-22143 Hamburg
phone:+49/40/67581419 / mobile:+49/177/3787491 / fax:++49/40/67581426
http://www.hostsharing.net ---> Webhosting Spielregeln selbst gemacht