views:

579

answers:

4

As the title says, does any Unix-like system ascribe a meaning to the SUID bit on a directory, and if so, what does it mean?

The SVTX (saved text, or sticky) bit has a meaning - thou shalt not delete a file from this directory unless you can write to the file. It is used on /tmp, for example.

The SGID (set GID) bit has a meaning - files created in this directory shall belong to the group that owns the directory (though that assignment can later be changed by an explicit call to chown(2)).

What about the SUID bit?

A: 

The SUID bit states that, on execution of a file (when executable), the process will run under the identity of the owner of said file, not the user that executed it.

There are a few cases where a utility program is 'suid root' to allow privilege escalation.

EDIT: Misread original question (which refers to directories rather than files) - leaving answer unaltered for educational purposes ;-)

Jan Jungnickel
And you can't execute directories - so what would it mean applied to directories?
Jonathan Leffler
D'oh, you're right, I overlooked the directory part. See John Ellinwood's answer.
Jan Jungnickel
+1  A: 

When set on a directory, all the files and directories created within this directory will have the same owner as the SUID-directory itself, no matter who created the file. This is a feature which is not used too often, but it can be useful in some cases. (source)

Update: I just tried this on Linux 2.6.25.5-1.1-default #1 SMP x86_64 GNU/Linux openSUSE 11.0 (X86-64).

mkdir tmp
chmod 4777 tmp
su othergroup
touch testfile

It had no effect.

John Ellinwood
Do you know of any systems which actually support it - the URL says it happens, but I'm not clear on which platforms.
Jonathan Leffler
Edited my post. Looks like it works on OpenSuSE 11.0
John Ellinwood
@John: You've demonstrated SGID on directory, not SUID. Solaris and Linux support SGID on directories out of the box.
Martin Carpenter
bah, you're right. i tried 4777 and it didn't do anything, so I guess OpenSuSE doesn't do anything with it. Wikipedia also says only FreeBSD uses it, too.
John Ellinwood
SGID works on FreeBSD too, SUID however requires kernel support and an option to passed to mount!
X-Istence
+3  A: 

Copied from here:

On most systems, if a directory's set-group-ID bit is set, newly created subfiles inherit the same group as the directory, and newly created subdirectories inherit the set-group-ID bit of the parent directory. On a few systems, a directory's set-user-ID bit has a similar effect on the ownership of new subfiles and the set-user-ID bits of new subdirectories. These mechanisms let users share files more easily, by lessening the need to use chmod or chown to share new files.

These convenience mechanisms rely on the set-user-ID and set-group-ID bits of directories. If commands like chmod and mkdir routinely cleared these bits on directories, the mechanisms would be less convenient and it would be harder to share files. Therefore, a command like chmod does not affect the set-user-ID or set-group-ID bits of a directory unless the user specifically mentions them in a symbolic mode, or sets them in a numeric mode.

Node
Thanks - that is a helpful pointer. Do we have any information about which systems support the "on a few systems, a directory's set-user-ID bit has a similar effect"? It seems like an obvious extension of the set-group-ID feature. What security consequences would it have?
Jonathan Leffler
Hm, good question on my linux (coreutils-5.93) it does not show this behavior. ATM I can't see any real security problems if it would act like described.
Node
+5  A: 

As a followup on Node's answer, I will post the following from the FreeBSD man page for mount(8):

             suiddir
                 A directory on the mounted file system will respond to
                 the SUID bit being set, by setting the owner of any new
                 files to be the same as the owner of the directory.  New
                 directories will inherit the bit from their parents.
                 Execute bits are removed from the file, and it will not
                 be given to root.

                 This feature is designed for use on fileservers serving
                 PC users via ftp, SAMBA, or netatalk.  It provides secu-
                 rity holes for shell users and as such should not be used
                 on shell machines, especially on home directories.  This
                 option requires the SUIDDIR option in the kernel to work.
                 Only UFS file systems support this option.  See chmod(2)
                 for more information.

And the chmod(2) man page section that refers to the suid bit:

           4000    (the setuid bit).  Executable files with this bit set will
               run with effective uid set to the uid of the file owner.
               Directories with this bit set will force all files and sub-
               directories created in them to be owned by the directory
               owner and not by the uid of the creating process, if the
               underlying file system supports this feature: see chmod(2)
               and the suiddir option to mount(8).

Please be aware that this is a security risk and know what you are doing when you enable it, in FreeBSD but I believe Linux as well it requires special mount flag to be enabled and will change the way files in that directory behave.

X-Istence
Thank you - that is helpful because it includes specific platform information. Other messages I've seen only include the general assertion that such systems exist.
Jonathan Leffler
Hm, could you describe a scenario where it would be a security risk to use it? Maybe if _secret_ files from a user would be created as _nobody_. But nice to know. :) *upvote*
Node
@Node: Not sure how it could be used as a security hole, other than that it is generally considered bad practice, and therefore it has been disabled by default in FreeBSD/Linux.
X-Istence
Note creat(2)'s second parameter allows the attacker (Mallory) to specify file mode. Imagine Alice has a setuid directory, Mallory has write access. Mallory creates a file in this directory with permissions 4555 (ie executable, SUID). File is automatically chowned to Alice. Mallory pwns Alice.
Martin Carpenter
@Martin Carpenter: The FreeBSD implementation already accounts for that, it won't allow you to create files that are chmod'ed to +x, it always removes the execute bit from the files that are created, but it does not mention what happens when you move a setuid file to the setuid directory!
X-Istence