Which commands (in /bin & /usr/bin) must have set user ID (for root)
Scott Bemis
I am wondering which commands in /bin /and /usr/bin (owned by root, group is
sys) must have the set user ID, or set group ID on execution in order
to work correctly.
An example of a command is /usr/bin/at. Below is what ls -l would produce.
$ ls -l /usr/bin/at
-rwsr-xr-x 1 root sys 31448 Jul 3 1984 /usr/bin/at
I hesitate to change the permissions without knowing why the commands
had the set user id on execution in the first place. Or in other
words, I have changed the permissions on a FEW commands and they stopped
working.
Scott Bemis
mcnc!rti-sel!tijc02!root
Jim Webb
> I am wondering which commands in /bin /and /usr/bin (owned by root, group is
> sys) must have the set user ID, or set group ID on execution in order
> to work correctly.
-rwsr-xr-x 1 root sys 9784 Apr 3 1986 df
df needs to be able to read the superblock of the filesystem(s) to see how
many blocks and inodes are free. Unfortunately, the standard version allows
it to open ANY device; it should restrict non-super-users to those devices
found in /etc/mnttab (mounted filesystems)
-rwsr-xr-x 1 root sys 8360 Nov 5 1983 mkdir
only root can mknod directories, as the . and .. entries are put in
somewhat manually by the command. If anyone could make directories,
I guess somewhere along the line someone in their application would
not do it correctly and minor mayhem would ensue.
-rwsr-xr-x 1 root bin 18936 Nov 5 1983 newgrp
needs suid so that one can change his/her group id.
-rwsr-sr-x 1 root sys 19068 Nov 5 1983 passwd
obvious.
-rwsr-xr-x 1 root sys 8796 Nov 5 1983 rmdir
like mkdir, only root can unlink directories.
-rwsr-xr-x 1 root sys 19484 Nov 5 1983 su
obvious.
-rwsr-xr-x 1 root sys 47197 Oct 20 1985 at
at needs to talk to cron in a very specific manner.
It should be noted that this is why the files in
/usr/spool/cron/atjobs are setuid and setgid to the submitter,
for cron (yes, cron) stats the file and does a setuid and setgid
on the owner and group of the file. However, some pond scum (:-) could
chgrp and chown the files to root and have them then run as root.
SO, at makes sure the setuid and setgid bits are set, as they are
cleared on chowns.
-rwsr-xr-x 1 root sys 25093 Nov 5 1983 crontab
crontab tells the cron daemon to create individual crontabs. It does
this by writing on /usr/lib/cron/FIFO which had better be 700 owned
by root. Otherwise, a user could manipulate cron quite freely.
You should at this point make /usr/spool owned by uucp and modes
755. As distributed, /usr/spool is 777, so a user could
mv /usr/spool/cron to /usr/spool/cron/.cron and replicate the
directory structure, obviously adding a nicety to root's crontab.
Although this would not be noticed until the system is rebooted
or cron re-run, it is usually worth the wait...
---s--x--x 1 root sys 41980 Oct 16 1985 ct
ct needs to be suid root so that when it calls /etc/getty, getty can
write in /etc/utmp and /etc/wtmp to log the login. It also needs to
run as root so that login will work, as by default, login is NOT suid.
You could setuid root login and then people could successfully login
again via "exec login"
-rwsr-xr-x 2 root bin 37232 Nov 6 1983 sh
just kidding...
-rwsr-xr-x 1 root sys 22380 Nov 5 1983 shl
shl needs it so that it can set/reset the owners of the sxt devices
as well as twiddle some other things.
> I hesitate to change the permissions without knowing why the commands
> had the set user id on execution in the first place. Or in other
> words, I have changed the permissions on a FEW commands and they stopped
> working.
snicker snicker
Some more comments on suid root programs. Do yourself a favor and make the
following change, it will make a lot of hackers (like myself) not like your
machine too much, but....
chmod 777 /usr/preserve
chmod u-s /usr/lib/ex*preserve
By no means does ex*preserve need to be setuid root. It did when it was
on berkeley, as chown was/is restricted to root there, but not under SV.
I guess you could make a group "vi" and setgid it to vi, and make
/usr/preserve 775, group vi if you wanted to be a bit more secure.
Also, /etc does not need to be 775 group sys. Make it 755.
--
Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw
Scott Bemis
I am wondering which commands in /bin /and /usr/bin (owned by root, group is
sys) must have the set user ID, or set group ID on execution in order
to work correctly.
An example of a command is /usr/bin/at. Below is what ls -l would produce.
$ ls -l /usr/bin/at
-rwsr-xr-x 1 root sys 31448 Jul 3 1984 /usr/bin/at
I hesitate to change the permissions without knowing why the commands
had the set user id on execution in the first place. Or in other
words, I have changed the permissions on a FEW commands and they stopped
working.
Scott Bemis
mcnc!rti-sel!tijc02!root
#Bill.Stewart
>>[Somebody else wrote..]
>> I currently have VAX 11/785s running AT&T UNIX V Release 2 Version 2.0.
>> I am wondering which commands in /bin /and /usr/bin (owned by root, group is
>> sys) must have the set user ID, or set group ID on execution in order
>> to work correctly.
What surprised me about the list Jim replied with was that most of the commands
were -rws......! Why should a setuid command *ever* be writeable? - it's just
*inviting* attempts to find a bug and convince the command to write over itself.
Are there any commands that actually depend on this?
>-rwsr-xr-x 1 root sys 47197 Oct 20 1985 at
>-rwsr-xr-x 1 root sys 25093 Nov 5 1983 crontab
>at needs to talk to cron in a very specific manner.
I would expect you could write a good cron without setuid, since /etc/cron runs
as root? Likewise "at", since it's the other side of cron?
What irks me more, though, is that the "lp" commands all run setuid-lp
setgid-bin; this means that in a directory which lp can't access ( e.g. 700),
lp foo
fails, though
lp <foo
is ok.
--
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
Ian Donaldson
files and devices you can remove the need for lots of programs to
have "setuid root" permission.
For example, "df", "quot" need only access filesystems, so it makes
sense to group all your "disk" devices by an owner "disks". Thus, you
make "df" and "quot" setuid "disks".
Since "ps", "w", "pstat", "gcore" all access /dev/kmem, they can
conveniently it also makes sense for /dev/kmem to be grouped by "mem",
and the set-gid mem permission placed on the programs.
A few examples follow:
-rws--x--x 1 disks bin 13512 Jun 11 1985 df
-rwx--s--x 1 bin mem 21688 Jun 15 19:38 ps
-rwx--s--x 1 bin mem 12028 Jun 15 19:59 gcore
-rwx--s--x 1 bin mem 20588 Jun 10 01:08 pstat
-rws--x--x 1 disks bin 16328 Jul 16 1985 quot
-rwx--s--x 2 bin mem 17124 Jun 15 19:38 uptime
-rwx--s--x 2 bin mem 17124 Jun 15 19:38 w
Some of my /dev/ follows:
brw-rw-r-- 1 disks floppy 0, 0 Aug 24 22:08 flp0d
brw-r----- 1 disks winnie 1, 0 Jun 26 01:34 imi0a
crw-r----- 1 bin mem 2, 1 Oct 12 21:43 kmem
crw-r----- 1 bin mem 2, 0 Jun 26 01:33 mem
crw-rw-r-- 1 root magtape 10, 16 Jun 26 01:34 nrmt0l
crw-rw-r-- 1 root magtape 10, 24 Jun 26 01:34 nrmt0p
crw-r----- 1 disks winnie 4, 18 Aug 16 15:30 rimi1c
crw-rw-r-- 1 root magtape 10, 8 Jun 26 01:34 rmt0p
crw-r----- 1 disks winnie 11, 0 Jun 26 01:35 rst0a
brw-r----- 1 disks winnie 5, 0 Jun 26 01:35 st0a
brw-r----- 1 bin mem 5, 2 Jul 14 21:36 swap
For the benefet of those who can't handle cryptic crosswords,
"st" and "imi" are winchester disks,
"flp" is a floppy disk,
"mt" is a mag-tape,
the rest should be universal.
This way other benefits are provided: you can list in /etc/group
those users that are allowed access to the floppy and magtape etc,
without having to tell them what the root password is, or make
the device publicly read/writeable. By changing mode 640 to 660
on other devices you can grant winchester access as well (not advised).
This convention has been in use on our systems for months now and
I am confident it is reasonably free of side-effects.
Ian Donaldson
Paul A. Sherman
>Also, /etc does not need to be 775 group sys. Make it 755.
Although /etc does not *need* to be 775 group sys, it makes ps(1) run
much faster in most cases (see explanation below). I don't know if
other standard programs make use of this situation, but I don't think
that it creates a security problem. Unless other programs that are
setgid sys have shell escapes (I don't know of any) or access to group
sys is granted indiscriminately, I think that /etc should remain mode
775, group sys, as distributed.
At least in System V, ps(1) creates a data file called /etc/ps_data
containing information from /dev, /unix, and /etc/passwd. If /etc/ps_data
is newer than those three files than it is used. Otherwise it is
recreated. On all System V systems that I've worked on, ps runs MUCH
faster when it can use an existing ps_data. This is because otherwise
it has to call nlist(3) on /unix and look through all of the entries in /dev.
Normally /etc is 775, group sys and ps is setgid to sys, so any user
of ps can create the new ps_data. If /etc is mode 755, owned by root,
ps can only successfully create a new ps_data file when it is run by
root. If things don't change much, than other users of ps will be able
to use the file that root created. However, any user changing a
password (with passwd) or login shell (with chsh) changes /etc/passwd
and makes the older /etc/ps_data unusable. Adding or removing nodes
from /dev (which admittedly happens much less frequently and requires
superuser permissions) also makes ps_data unusable since the
modification time of /dev changes.
As an aside, I have run across a couple of times that ps seemed to run
slow ALL the time, not only the first time after a change to /etc/passwd
or /dev. I found that the system had been powered off recently and
the date had to be reset. Before that happened, however, the
modification time of /dev or /unix was set to some time in the future.
Thus, ps's check for ps_data being newer than those files always failed, and
ps had to read all of its own data and recreate ps_data. The next
time, of course, the same thing happened.
--
Paul Sherman
AT&T Information Systems, Lincroft, NJ
{pegasus|ihnp4}!popeye!sherm
(201) 576-6316
Jim Webb
> What surprised me about the list Jim replied with was that most of the
> commands
> were -rws......! Why should a setuid command *ever* be writeable? - it's just
> *inviting* attempts to find a bug and convince the command to write
> over itself.
First off, root can overwrite any file regardless of perms, yes/no? Second,
ever see "error: text busy" ? You cannot remove or write over a file that
is running somewhere on the system (or, to be picky, has the sticky bit set
and has been run)
> Are there any commands that actually depend on this?
Self modifying code, perhaps :-)
> >-rwsr-xr-x 1 root sys 47197 Oct 20 1985 at
> >-rwsr-xr-x 1 root sys 25093 Nov 5 1983 crontab
> >at needs to talk to cron in a very specific manner.
> I would expect you could write a good cron without setuid,
> since /etc/cron runs
> as root? Likewise "at", since it's the other side of cron?
at and crontab need to yell down /usr/lib/cron/FIFO to talk with cron.
I suppose you could make these commands setgid to some unique group and
make this pipe writable only by that group.
> What irks me more, though, is that the "lp" commands all run setuid-lp
> setgid-bin; this means that in a directory which lp can't access ( e.g. 700),
> lp foo
> fails, though
> lp <foo
then make lp suid root :-)
--
Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw
"Use the Force, Read the Source"
Jim Webb
>
> Although /etc does not *need* to be 775 group sys, it makes ps(1) run
> much faster in most cases (see explanation below). I don't know if
> other standard programs make use of this situation, but I don't think
> that it creates a security problem. Unless other programs that are
> setgid sys have shell escapes (I don't know of any) or access to group
> sys is granted indiscriminately, I think that /etc should remain mode
> 775, group sys, as distributed.
I can think of one program off the top of my head that is setgid sys
and has two very exploitable security holes. I would mention it here,
but I am sure that every college student listening in would try it :-).
I guess it is a tradeoff, I can become root on any standard SV machine
in under 60 seconds if /etc is 775 group sys, or ps can run slower if
/etc isn't writable by group sys.
Because of this, I guess ps should be hacked to overwrite
/etc/ps_data instead of unlinking and exclusively re-creat-ing it.
Or, make "yet another" nothing login with NONE as its passwd so that
it is IMPOSSIBLE for a non-superuser to login or su to the account,
make it the owner of /etc, 755, and make ps setuid to it. You have to keep
ps setgid sys, otherwise you cannot get at /dev/*mem and /dev/swap.
ISN'T SECURITY FUN?
It should be noted to fellow AT&T Bell Labbers that the hole mentioned above
has been closed on most, if not all, 452 CompCenter machines, so don't waste
your time looking at all of the setgid sys programs :-)
--
Jim Webb "Out of phase--get help" ...!ihnp4!hropus!jrw
Jack Jansen
Probably a *lot* of commands in /bin or /usr/bin don't need set-uid.
If you adopt a well-chosen group scheme, set-gid to a certain group
can be enough.
This is what is more-or-less done in BSD unix. For instance,
/dev/kmem is owned by the group 'kmem', and '/bin/ps' is setgid kmem.
This can easily be extended to programs like 'at', 'df', 'expreserve',
etc. The nice thing is that this is even possible if you don't
have a source license.......
--
Jack Jansen, ja...@mcvax.UUCP
The shell is my oyster.
Henry Spencer
>
> obvious.
No, actually, not obvious. Passwd only has to be able to read and write
in /etc, which generally does not require root privileges.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
Doug Gwyn
>I think that /etc should remain mode 775, group sys, as distributed.
Please note that, from a security standpoint, this has given any "sys" group
member (or set-gid "sys" process) super-user access if it chooses to exploit it.
Also note that "ps" need not have write permission on /etc in order to rewrite
/etc/ps_data. (If so desired, the file could be locked during rewrite so that
concurrent "ps"es wouldn't trip over each other.)
Doug Gwyn
>What surprised me about the list Jim replied with was that most of the commands
>were -rws......! Why should a setuid command *ever* be writeable? - it's just
>*inviting* attempts to find a bug and convince the command to write over itself.
The "write" access bit on a file owned by "root" is essentially a no-op,
since the super-user (or a privileged process) could write the file anyway.
It doesn't create any additional security problem that I can see.
Daniel R. Levy
>What surprised me about the list Jim replied with was that most of the commands
>were -rws......! Why should a setuid command *ever* be writeable? - it's just
>*inviting* attempts to find a bug and convince the command to write over itself.
Waitaminnit... at least on SysV, it is not possible to overwrite, or remove the
last link to, any executable file which is currently being run (this doesn't
count shell scripts). I do not know whether BSD has the same restriction.
Could someone suggest a reason for this (other than security)... is this to
accommodate versions of the UNIX OS which can page or swap text out of the
filesystem? What about UNIX systems which don't swap or page out of the
filesystem? But I digress. A setuid command being writeable makes it easier
for the system admin to install a new version, I suppose, though it seems
almost as easy for makefiles to put in an explicit rm -f or chmod when needed.
># Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
--
------------------------------- Disclaimer: The views contained herein are
| dan levy | yvel nad | my own and are not at all those of my em-
| an engihacker @ | ployer or the administrator of any computer
| at&t computer systems division | upon which I may hack.
| skokie, illinois |
-------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
go for it! allegra,ulysses,vax135}!ttrdc!levy
Brandon Allbery
Quoted from <10...@ho95e.UUCP> ["Re: Which commands (in /bin & /usr/bin) must have set user ID (for root)"], by w...@ho95e.UUCP (#Bill.Stewart)...
+---------------
| In article <7...@hropus.UUCP> j...@hropus.UUCP (Jim Webb) writes:
| >-rwsr-xr-x 1 root sys 47197 Oct 20 1985 at
| >-rwsr-xr-x 1 root sys 25093 Nov 5 1983 crontab
| >at needs to talk to cron in a very specific manner.
| I would expect you could write a good cron without setuid, since /etc/cron runs
| as root? Likewise "at", since it's the other side of cron?
+---------------
Both "crontab" and "at" work in the same way:
(1) write a file in a protected directory (to keep non-superusers from doing
fun things like changing other users' at files or setting up crontabs/at jobs
when they're listed in {cron,at}.deny), and
(2) write something to /usr/spool/cron/FIFO, which is protected for the same
reasons as above. (I wish I'd thought of that way of doing things; it makes
sense. 20/20 hindsight, eh?)
+---------------
| What irks me more, though, is that the "lp" commands all run setuid-lp
| setgid-bin; this means that in a directory which lp can't access ( e.g. 700),
| lp foo
| fails, though
| lp <foo
| is ok.
+---------------
It *might* be possible to run "lp" setgid only -- but that might not help
you. (Although it would take strange circumstances to do that.) But "lp"
revolves around a few special files in /usr/spool/lp and ordinary users
shouldn't be allowed to muck with them; even if they know what they're doing,
mucking with /usr/spool/lp/outputq while lpsched is running is a good way
to trash the print queue.
++Brandon
--
---------------- /--/ Brandon S. Allbery UUCP: decvax!cwruecmp!
/ / /|\/ Tridelta Industries, Inc. ncoast!tdi2!brandon
---- -------- /-++ 7350 Corporate Blvd. PHONE: +1 216 974 9210
/ / /---, ---- Mentor, Ohio 44060 SYSOP: UNaXcess/ncoast
/ / / / / / -- HOME -- (216) 781-6201 24 hrs.
/ / / / / / 6615 Center St. Apt. A1-105 ARPA: ncoast!allbery%
---- -----~ ---- Mentor, Ohio 44060-4101 case....@relay.cs.net
Al Gaspar
Al Gaspar <gas...@almsa-1.arpa>
USAMC ALMSA, ATTN: AMXAL-OW, Box 1578, St. Louis, MO 63188-1578
COMMERCIAL: (314) 263-5118 AUTOVON: 693-5118
seismo!gas...@almsa-1.arpa
Robert Elz
> ... at least on SysV, it is not possible to overwrite, or remove the
> last link to, any executable file which is currently being run (this doesn't
> count shell scripts). I do not know whether BSD has the same restriction.
> Could someone suggest a reason for this (other than security)...
BSD has a similar restriction, you can't overwrite a shared text executable
(I suspect that the SysV implementation is really that too - a non-shared
executable can probably be overwritten) while its being executed, though
on BSD you are allowed to unlink it. The unlink is just like unlinking
an open file though - while the directory entry is removed, the file
(and its inode) hang around until the last execution of the process
completes. Since there is no longer a name for the file, new executions
other than by an existing process forking are obviously impossible.
The reason is simple, and its not related to paging out of the text
space, though its similar.
For shared text executables, unix keeps a table of texts currently
in use (the "text" table). That is indexed by device/inode pairs.
When you exec a shared process, the kernel looks in this table to
see if the process is already being executed, and if it is, just
gives you a copy of the text that's already in code, rather than
reading a new copy from the filesystem. That's what "shared text"
is all about. The initial data space is still read from the file.
Now, if you were to change the file while a copy was running, when
you did the next exec, strange things would happen. Most likely,
the new process would end up with the old text (that was being run
when the file was changed) and the new data sapce. Unless you're
lucky, this isn't going to work well.
There are ways that this could be fixed - when the file is written,
the kernel could mark the text table so that the next exec would
read a new text from the filesystem. However, this doesn't seem
important enough to bother with really, just prohibiting writes
seems good enough. Probiting unlink is too extreme though I think,
allowing the unlink, but simply not releasing the inode is a
sufficient precaution.
Robert Elz seismo!munnari!kre k...@munnari.oz.au
Guy Harris
> remove the last link to, any executable file which is currently being
> run (this doesn't count shell scripts). I do not know whether BSD has
> the same restriction.
BSD has the former restriction, but not the latter.
> Could someone suggest a reason for this (other than security)...
There is no good reason whatsoever for the latter restriction, which is why
Berkeley lifted it. Since the shared text structure (or, presumably, the
region structure in later S5 implementations) holds on to the inode, the
file doesn't really disappear when unlinked (although there are no directory
entries referring to it) until the last process releases that shared text.
The only reason I've heard was something on the order of "well, if you have
the system holding on to one of these 'no directory entries point to it'
files, and the system crashes, it shows up as an unreferenced file", which
is boguus because 1) the exact same thing happens if you remove the last
link to a file which somebody has open, and UNIX doesn't forbid that, and 2)
"fsck" will clean up those unreferenced files anyway.
There are better reasons for the former restriction. In an unpaged system,
if you wrote to the file the change would not necessarily be reflected in
the copy in main memory or on the swap device; as such, until those copies
last their last reference and disappeared, processes trying to execute that
file would get a copy of the old text and a copy of the new data, which
would be very confusing. In a paged system, it's even worse - processes
currently using that file could get a mixture of old and new pages!
In a system using NFS, it is impossible to prevent a file from being opened
for writing by a process on one machine if another machine is using that
file as a shared text (because it's impossible for the machine on which the
file resides to find out who's holding on to it), so the writes are allowed
to go through; however, if the process using that file tries to fetch a
page from a file that has been modified since the process in question first
attached to it, it gets zapped by a SIGKILL (a message is printed on the
user's terminal, if there's a terminal associated with this process).
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
g...@sun.com (or g...@sun.arpa)
System Mangler
> In a system using NFS, it is impossible to prevent a file from being opened
> for writing by a process on one machine if another machine is using that
> file as a shared text (because it's impossible for the machine on which the
> file resides to find out who's holding on to it), so the writes are allowed
> to go through; however, if the process using that file tries to fetch a
> page from a file that has been modified since the process in question first
> attached to it, it gets zapped by a SIGKILL (a message is printed on the
> user's terminal, if there's a terminal associated with this process).
This problem is even worse with dual-ported disks. The read-only side
is completely clueless about the writes, and the process (usually some
daemon like sendmail) gets a mixture of old and new pages. If you're
lucky, the process dies. We only update the read/write side late on
Saturday nights, but we still get bit.
/etc/update's liking for holding certain directories open all the time
causes similar problems when those directories are updated. I've never
understood the purpose of that.
Don Speck sp...@vlsi.caltech.edu {seismo,rutgers}!cit-vax!speck
Dave Martindale
>> Waitaminnit... at least on SysV, it is not possible to overwrite, or
>> remove the last link to, any executable file which is currently being
>
>There are better reasons for the former restriction. In an unpaged system,
>if you wrote to the file the change would not necessarily be reflected in
>the copy in main memory or on the swap device; as such, until those copies
>file would get a copy of the old text and a copy of the new data, which
>would be very confusing.
This is a good reason for not letting people write on shared texts with
the current implementation of the text code, but not necessarily a reason
to avoid fixing the implementation.
In a non-paged system, all that is necessary to allow writes to a shared-text
inode is to "detach" the already-running texts from it. To do this, just
zero the inode pointer in the text table, decrement the reference count
in the inode, and go on your way. The write to the inode can proceed;
anyone trying to exec the file while it is being written gets the usual
error, but once the file is no longer open for write it can again be
exec'ed. The old text table entry will never be used by a new exec,
since it is no longer associated with the file's inode.
The still-executing copies of the old binary are not bothered by any of
this, as a complete copy of the executable is already either in memory
or on the swap device, and the text structure contains all info needed
to keep track of it. The only difference is that when the last instance
of the old program exits, the code cleaning up the text table entry must
be careful to avoid doing an iput on the text inode if the pointer has
already been zeroed.
(I may have forgotten a detail or two, but the approach is sound - it
was implemented years ago under V7 at Waterloo).
In the case of a system that doesn't load the entire binary at once
(e.g. demand paging), it is much messier. There is still no problem
in providing a clean copy of the new code for new execs, contrary to
what Guy suggests - just "detach" the text structure as before.
The problem comes in providing pages to the still-executing "old" copies
of the program from a file that no longer exists in the state it was
in when execution began. To solve this, the "detach" operation would
have to arrange to copy every page of the original file that had not
already been page-faulted into memory from the file system into the
swap device. This could be very expensive for a large binary, and
a pain to implement since you have to change page tables while you
do it. Thus the whole thing is probably not worth doing on a system
that does demand paging from the a.out.
Ray Moody
>> commands
>> were -rws......! Why should a setuid command *ever* be writeable? - it's just
>> *inviting* attempts to find a bug and convince the command to write
>> over itself.
>
>First off, root can overwrite any file regardless of perms, yes/no? Second,
>ever see "error: text busy" ? You cannot remove or write over a file that
>is running somewhere on the system (or, to be picky, has the sticky bit set
>and has been run)
Anyway, if a setuid program overwrites itself, it is no longer setuid!
It says in the manual page for write (2):
If the real user is not the super-user, then _ w_ r_ i_ t_ e clears
the set-user-id bit on a file. This prevents penetration of
system security by a user who "captures" a writable set-
user-id file owned by the super-user.
>> What irks me more, though, is that the "lp" commands all run setuid-lp
>> setgid-bin; this means that in a directory which lp can't access ( e.g. 700),
>> lp foo
>> fails, though
>> lp <foo
>
>then make lp suid root :-)
There shouldn't be any smiley face here. This is a perfectly reasonable
suggestion. Just MAKE SURE IT CALLES ACCESS (2)! Out lpr program runs setuid.
array
array Ray Moody
array ihnp4!pur-ee!pucc-s!aij
array
g...@sun.uucp
> causes similar problems when those directories are updated. I've never
> understood the purpose of that.
Back in the days of V7, UNIX didn't treat the list of free inode table
entries as an LRU cache for inodes. Holding selected directories open
kept their inodes in core, and meant the system didn't have to go to the
disk every time it wanted to get that inode. Of course, when you have two
processors (or processes) sharing access to some data structure, and keeping
local cached copies of that data structure, you have to be careful to avoid
cache consistency problems like the ones you see when dual-porting.
g...@sun.uucp
After having made *damn* sure you've caught all the code that assumes that
"x_iptr" is never null for a valid text table entry, and changed "xalloc"
not to use a null "x_iptr" as an indication of a free text table entry.
(You definitely have to do this with a non-paging S5R2; as I remember, that
code hadn't changed much since V7.)
> In the case of a system that doesn't load the entire binary at once
> (e.g. demand paging), it is much messier. There is still no problem
> in providing a clean copy of the new code for new execs, contrary to
> what Guy suggests - just "detach" the text structure as before.
Gee, I wasn't aware that I suggested that you can't do it even with the
changes you mention. My point was that *with the V7/4BSD/unpaged S5R2
implementation* there is a reason for forbidding writes to active shared
text files. Another possibility is to do what's done with NFS and kill the
process if it tries to fetch a page from the file and the file has been
written since the last time you looked at it.
g...@sun.uucp
> It says in the manual page for write (2):
It says this *in the 4BSD manual page for write(2)*; this is a Berkeleyism.
I consider it to be an airbag; I'm not sure it's worth putting in a hack
like this to protect people who don't remember to make set-UID programs
writable only by the owner. (Also note that it doesn't apply if the process
doing the write has a *real* UID of "root".)
Steve Summit
> > Anyway, if a setuid program overwrites itself, it is no longer setuid!
>
> I consider it to be an airbag; I'm not sure it's worth putting in a hack
> like this to protect people who don't remember to make set-UID programs
> writable only by the owner.
I think this airbag solves a significant class of potential
security problems, such as the following: once I was snooping
around looking for setuid programs (never mind why :-), and I
discovered that, to my astonishment, /usr/bin/uniq was setuid
root! (My guess is that somebody wanted to make uusend, uulog,
etc. setuid uucp, and accidentally typed chmod +s u* instead of
uu*.) This wasn't a general security hole, yet, since being root
doesn't do you much good if all you can do is report repeated
lines in a file. But since uniq happens to take an output
filename argument, I could have parlayed that hole into a general
one, by using the incongrously setuid uniq to scribble a
genuinely useful program (like /bin/sh) onto a previously setuid
program (like /bin/passwd).
It's true that limited write ability could still be used to
scribble on /etc/passwd (which is less desirable for a hacker's
purpose due to console log messages for su's), and to do a few
more subtle tricks (which I think I won't mention).
Steve Summit
tektronix!copper!stevesu
Guy Harris
> >fetch a page from a file that has been modified since the process
> >in question first attached to it, it gets zapped by a SIGKILL (a
> >message is printed on the user's terminal, if there's a terminal
> >associated with this process).
>
> and stored locally until the process is done with them. This could
> be done as a `background task', to keep it from affecting performance
> much.
When would the pages be brought over? When the program was first executed?
This may narrow the window of vulnerability, but it wouldn't close it
entirely. I also wouldn't go so far as to say doing it as a background task
wouldn't affect performance much, without seeing some hard data - if the
program is very big, you will be tying your network and your server's disk
up fetching a bunch of pages which, presumably, you'll not be using.
When the file is written? No can do. The file may be written by another
machine, so you have no way of knowing it's being written.
Guy Harris
> security problems, such as the following: once I was snooping
> around looking for setuid programs (never mind why :-), and I
> discovered that, to my astonishment, /usr/bin/uniq was setuid
> root!
This class of "passive restraint", like the automotive kind, seems to be
intended to protect people who would not otherwise protect themselves. As
you point out, even with that particular sodium-azide-bag, a would-be system
cracker can do a fair bit of damage with an inappropriately-set-UID program.
The added protection provided by turning off the set-UID bit when writing to
a file is pretty minimal in this case.
Daniel R. Levy
>In article <86...@sun.uucp>, g...@sun.uucp (Guy Harris) writes:
>> > Anyway, if a setuid program overwrites itself, it is no longer setuid!
>> It says this *in the 4BSD manual page for write(2)*; this is a Berkeleyism.
>I think this airbag solves a significant class of potential
>/usr/bin/uniq was setuid
>root!
>But since uniq happens to take an output
>filename argument, I could have parlayed that hole into a general
>one, by using the incongrously setuid uniq to scribble a
>genuinely useful program (like /bin/sh) onto a previously setuid
>program (like /bin/passwd).
Right in principle; in practice I'd think you'd have a hard time getting
uniq to pass a binary file :-). Still, a point well taken.
>It's true that limited write ability could still be used to
>scribble on /etc/passwd (which is less desirable for a hacker's
>purpose due to console log messages for su's), and to do a few
>more subtle tricks (which I think I won't mention).
> Steve Summit
While su's may show up on the console, does it show up on the console in
BSD if a user simply logs in to an account (other than root) which shows
a UID of 0 in /etc/passwd? SysV doesn't allow direct login to a UID 0
account except at the console, but I don't have a BSD system to try this
with.
Chris Torek
>>... It would be better if the pages were brought over and stored
>>locally until the process is done with them. This could be done
>>as a `background task', to keep it from affecting performance much.
In article <88...@sun.uucp> g...@sun.uucp (Guy Harris) writes:
>When would the pages be brought over? When the program was first executed?
Yes.
>This may narrow the window of vulnerability, but it wouldn't close it
>entirely.
True---but note that most of the statistics gathered by 4BSD process
migration studies show that programs are grouped into `short lived'
and `long lived', and that there are very few `medium life' programs.
If the window is trimmed down to (say) five seconds, that would
help programs like editors considerably. (Imagine having your
editor die after working on a file for several hours! Fortunately,
most editors can recover from crashes, including being killed by
the kernel because the server's copy of the editor chaned).
>I also wouldn't go so far as to say doing it as a background task
>wouldn't affect performance much, without seeing some hard data ....
A point. But on the Sun-9, this will all be done by the network
processor and the disk-I/O-processor over private memory channels
on your ten terabit LAN anyway, right :-)?
>When the file is written?
No. Aside from the server's having to track all client paging
behaviour, by then it is probably too late anyway. Delaying the
write while clients squirreled away their own copies might work,
but might be slow; writing a new copy would cost disk space and
kernel complexity.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: ch...@mimsy.umd.edu