Vladimir Kazantsev wrote:
> Hello all,
>
> another dummy question. What is 'suid bit' and where I can learn more?
>
Vladimir,
I assume that you are familiar with normal file permissions. The suid
bit can only be set in the place of the user or group execute bit. If the
user execute bit is set, it means that the file, when executed, will be
executed with all the permissions available to the file owner. A similar
statement holds true for the group suid bit. Thus, if the file is owned
by the user 'tom' and has permissions rwsr-xr-x, then when users 'dick'
or 'harry' executes it, the file gets executed as if 'tom' was executing
the file. Here is something that I was planning to put in the
linux-newbie FAQ about suid :
Suid is necessary for allowing certain programs access to certain
resources without directly granting all users access to the resource in
question. However, when used the wrong way, suid can lead to security
holes.
For example, the 'write' program which is used to send messages from one
user to another, needs to have access to the tty devices. Generally
speaking, it is a bad idea to give everyone on the system read and write
access to tty's, since then ordinary users can read confidential data off
of the screens of priviledged users, or can write to other users screens
in an uncontrolled manner. In order for 'write' to work, the tty devices
are given write authority for the 'tty' group, and the 'write' program is
made sgid 'tty'. Now, a user can send a message to another user (write
to his tty) because, the sgid bit of 'write' gives him permission to do
so while using 'write'.
'write' had a security hole, once upon a time. Before the days of job
control in Unix, the 'write' program had what is called a 'shell escape'.
This was a sequence of keystrokes, which when invoked would present the
user with a shell prompt. The user would then have a shell with effective
group id of 'tty', which could be used to create havoc. Newer versions of
'write' relinquish the effective group id when the shell escape is
invoked.
The security problems that occur due to incorrect use of suid and sgid
are rarely as obvious as this. The following example is taken from the
book 'Practical Unix Security' by Simson Garfinkel & Gene Spafford
(O'Reilly,1991). It is an example of a problem which noone was aware of
for years, and was patched in 1986.
The programs 'vi' and 'ex' are editors, and they used to use a program
called /usr/lib/preserve. 'preserve' is a program that makes a backup of
the file being edited if the user is unexpectedly disconnected from the
system (network failure, power failure, etc) before the file is saved. It
writes the changes to a special directory, and then uses
bin/mail to mail a notification to the user that the file was saved.
The directory in which the changes were saved had restricted access
because people could have been editing confidential documents, and these
needed to have restricted access. Because of this, 'preserve' was made
suid root. 'preserve' used the 'system' call to invoke 'mail' and this
call actually invokes the shell 'sh' to parse the string that
it executes. The command that was executed was '/bin/mail <filename>'.
There is a shell variable called 'IFS' or the internal field separator.
Normally it is set to spaces. When set to '/', the command would get
interpreted as 'bin mail <filename>' - or in other words, a program
called 'bin' with the arguments of 'mail' and '<filename>'. All the
cracker would have to do was to create a malicious program called 'bin'
in his directory, set the IFS to '/' and kill 'vi'. His program named
'bin' would get executed with root authority!
Another factor to consider is that, when using NFS, or any kind of remote
filesystem mounting, it is not advisable to honour the suid bit if the
program is on the remote filesystem. If honoured, this becomes an instant
security loophole. This is why the use 0f the -nosuid flag is strongly
advocated when using 'mount'.
Regards,
Kenneth
--
There is no such thing as luck. 'Luck' is nothing but an absence of bad luck.
