What breaks if /etc is not owned by bin?
Rogier Wolff
It strikes me that /etc is owned by bin. This makes it very easy for
attacks over NFS to break "root". Also directories like /usr/etc
and /usr/bin and /var should not be owned by bin, but by root.
Some other vendors also do this, but others don't.
Now for the questions:
- Why is it that these "sensitive" directories are owned by the
relatively insecure user "bin".
- Is it Sunspecific that these directories HAVE to be owned by bin (if so)?
- What would break (if anything) if we
chown root /dev /etc /usr/etc /var/yp /tmp /var /var/adm
(try a "find / -user bin -type d -exec ls -ld {} \;" on your system
to find a more or less complete list of directories that are owned by bin)
Roger Wolff.
--
EMail: wo...@duteca.et.tudelft.nl
* There used to be text here but because people complained that my *
* signature file was too long I deleted it. Now only this short *
* message, explaing what happened to my signature remains. *
Neil Rickert
>
>It strikes me that /etc is owned by bin. This makes it very easy for
>attacks over NFS to break "root". Also directories like /usr/etc
>and /usr/bin and /var should not be owned by bin, but by root.
>Some other vendors also do this, but others don't.
>
>Now for the questions:
>- Why is it that these "sensitive" directories are owned by the
> relatively insecure user "bin".
Vendor stupidity.
>- Is it Sunspecific that these directories HAVE to be owned by bin (if so)?
My system (not a Sun) has these directories owned by root.
>- What would break (if anything) if we
> chown root /dev /etc /usr/etc /var/yp /tmp /var /var/adm
You would destroy my ability to easily become root on your system when
you leave other security loopholes which allow me access.
-------------------------------
Do a find on your system to find all programs that are suid bin. Also, using
ps, find which standard daemons run as bin. These are the only programs that
are likely to be affected.
--
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
Neil W. Rickert, Computer Science <ric...@cs.niu.edu>
Northern Illinois Univ.
DeKalb, IL 60115 +1-815-753-6940
Wendy Wilhelm
>>- Is it Sunspecific that these directories HAVE to be owned by bin (if so)?
> My system (not a Sun) has these directories owned by root.
Well I believe that I've heard that yp stuff needed to be owned
by bin... You might want to check that out tho.... Other than
that... nothing..
>>- What would break (if anything) if we
>> chown root /dev /etc /usr/etc /var/yp /tmp /var /var/adm
See above...
But then again, I don't represent sun :)
Wendy
Wietse Venema
>It strikes me that /etc is owned by bin. This makes it very easy for
>attacks over NFS to break "root".
>[...]
>- What would break (if anything) if we
> chown root /dev /etc /usr/etc /var/yp /tmp /var /var/adm
As far as I know, nothing breaks if you chown root /* /usr/{lib,etc}.
That is what we do here routinely (SunOS 4.1.[01]). "chmod go-w" does
not hurt either, except for things that should be world-writable.
A few more ideas:
"umask 022" at the start of our /etc/rc* files also gives no problems.
Examine your /etc/inetd.conf file. Do all those daemons really have to
be run with root privilege? Does your kernel accept NFS requests from
non-privileged ports (*)? There is a lot more that can be done without
breaking things.
(*) This and other stuff is conditionalized on the presence or absence
of /etc/security/passwd.adjunct. We modified rc.local to always choose
the less insecure mode. Until today, nothing got broken.
Scott Merrilees
>It strikes me that /etc is owned by bin. This makes it very easy for
>attacks over NFS to break "root". Also directories like /usr/etc
>and /usr/bin and /var should not be owned by bin, but by root.
>Some other vendors also do this, but others don't.
If you have stuff mounted writable over nfs, what is stopping me, on
the remote machine, doing a su to whatever uid owns the directory, and
then doing as I want. If the directory is owned by root, su to
nobody, and then accessing it.
How does chowning the directories effect things if I have all access on
the remote machine ?
And if I don't have all access on the remote machine, I won't be able to
become bin, so why bother chowning the directories on the local machine ?
Sm
--
Scott Merrilees, BHP Information Technology, Newcastle, Australia
Internet: S...@bhpese.oz.au Phone: +61 49 40 2132 Fax: ... 2165
Casper H.S. Dik
>wo...@dutecaj.et.tudelft.nl (Rogier Wolff) writes:
>>It strikes me that /etc is owned by bin. This makes it very easy for
>>attacks over NFS to break "root". Also directories like /usr/etc
>>and /usr/bin and /var should not be owned by bin, but by root.
>>Some other vendors also do this, but others don't.
>If you have stuff mounted writable over nfs, what is stopping me, on
>the remote machine, doing a su to whatever uid owns the directory, and
>then doing as I want. If the directory is owned by root, su to
>nobody, and then accessing it.
No. That's the whole point. If you have read/write access over NFS,
but not root access, you can't change files owned by root.
>How does chowning the directories effect things if I have all access on
>the remote machine ?
Only if you have root access, which is not the default.
>And if I don't have all access on the remote machine, I won't be able to
>become bin, so why bother chowning the directories on the local machine ?
As someone pointed out on the net, there is a accumulation of
errors by Sun that makes things worse.
in SunOS, as it is shipped, /etc is owned by bin and there's a + in
/etc/hosts.equiv. This means that, as soon as booted and routed, anyone
on the net can do a:
# su bin
hishost% rsh yourhost
yourhost% cd /etc
yourhost% mv passwd passwd.old
yourhost% cp passwd.old passwd
yourhost% vi passwd (add user with uid 0)
yourhost% vi passwd (add user with uid 0)
yourhost% su zero
# chown root passwd
(there might be restriction as to whom can su, but you can edit /etc/group)
Obviously, you can't do this when /etc is owned by root (remember that
if the local user is root, /etc/hosts.equiv is ignored)
Casper
--
| Casper H.S. Dik
| cas...@fwi.uva.nl
Jyrki Kuoppala
>wo...@dutecaj.et.tudelft.nl (Rogier Wolff) writes:
>the remote machine, doing a su to whatever uid owns the directory, and
>then doing as I want. If the directory is owned by root, su to
>nobody, and then accessing it.
The root-access kludge in NFS is to change `root' in client to
`nobody' in the server. `nobody' on the client is still `nobody' on
the server. Hmm - but I haven't really checked this, and considering
the other network software from the same source perhaps you really are
correct.
//Jyrki
Stefan Esser
|> If you have stuff mounted writable over nfs, what is stopping me, on
|> the remote machine, doing a su to whatever uid owns the directory, and
|> then doing as I want. If the directory is owned by root, su to
|> nobody, and then accessing it.
... this way you can do whatever you want with all files owned by 'nobody'.
But how does it help accessing files owned by root ???
(BTW: 'su'ing to nobody is disabled under HP-UX and Ultrix ...
Only Sun seems to treat 'nobody' as a regular account.)
Stefan
--
Stefan Esser, Institute of Nuclear Physics, University of Cologne, Germany
s...@IKP.Uni-Koeln.DE [134.95.192.50]
Joe Smith
>attacks over NFS to break "root". Also directories like /usr/etc
>and /usr/bin and /var should not be owned by bin, but by root.
>Some other vendors also do this, but others don't.
>
>Now for the questions:
>- Why is it that these "sensitive" directories are owned by the
> relatively insecure user "bin".
>- Is it Sunspecific that these directories HAVE to be owned by bin (if so)?
>- What would break (if anything) if we
> chown root /dev /etc /usr/etc /var/yp /tmp /var /var/adm
> (try a "find / -user bin -type d -exec ls -ld {} \;" on your system
> to find a more or less complete list of directories that are owned by bin)
Sun admits that they goofed. Here is the 100103-07_README file:
Patch-ID# 100103-07
Keywords: security
Synopsis: SunOS 4.1.1, 4.1:script to change file permissions to a more secure mode
Date: 14-June-91
SunOS release: 4.1
Unbundled Product:
Unbundled Release:
Topic:
BugId's fixed with this patch: 1046817 1047044 1048142 1054480 1037153 1039292 1042662
Architectures for which this patch is available: sun3, sun3, sun4, sun4c
Obsoleted by: 5.0
Problem Description:
File permissions on numerous files were set incorrectly in the build
tape of 4.1 FCS. This script changes them back to what they should
be.
INSTALL::
MUST be run as root.
# chmod 750 4.1secure.sh (restrict execution to root)
# sh 4.1secure.sh (run the script)
--
Joe Smith (408)922-6220 | SMTP: j...@tardis.tymnet.com DIALCOM: J.SMITH
BTNA Tech Services TYMNET| CA license plate: "POPJ P," PDP-10, 36 bits forever
PO Box 49019, MS-C51 | Married to the LB, Quantum Leap's #1 net.fan
San Jose, CA 95161-9019 | humorous disclaimer: "My Amiga 3000 speaks for me."
Scott Merrilees
>wo...@dutecaj.et.tudelft.nl (Rogier Wolff) writes:
>>It strikes me that /etc is owned by bin. This makes it very easy for
>>attacks over NFS to break "root". Also directories like /usr/etc
>>and /usr/bin and /var should not be owned by bin, but by root.
>>Some other vendors also do this, but others don't.
>If you have stuff mounted writable over nfs, what is stopping me, on
>the remote machine, doing a su to whatever uid owns the directory, and
>then doing as I want. If the directory is owned by root, su to
>nobody, and then accessing it.
>How does chowning the directories effect things if I have all access on
>the remote machine ?
>And if I don't have all access on the remote machine, I won't be able to
>become bin, so why bother chowning the directories on the local machine ?
I was wrong, and confused. The point is what the translation and access
check is done on the remote machine, not the local machine.
The remote machine gets credentials (root), translates it to (nobody),
compares it agains the file credentials (root), and denies access.
Mario Wolczko
>
> It strikes me that /etc is owned by bin. This makes it very easy for
> attacks over NFS to break "root". Also directories like /usr/etc
> and /usr/bin and /var should not be owned by bin, but by root.
> Some other vendors also do this, but others don't.
>
> Now for the questions:
> - Why is it that these "sensitive" directories are owned by the
> relatively insecure user "bin".
Because they like to keep the job market for sys.admins. buoyant :-)
> - What would break (if anything) if we
> chown root /dev /etc /usr/etc /var/yp /tmp /var /var/adm
> (try a "find / -user bin -type d -exec ls -ld {} \;" on your system
> to find a more or less complete list of directories that are owned by bin)
Nothing, provided you catch any setuid binaries too. I did this on
our system a couple of years back, and redo it at every install. No
problems so far.
Having directories like /etc owned by bin (or any non-root-uid) can
leave a security hole if you export that filesystem writable, but also
if another machine in the same domain can do a rsh as bin. It's worth
changing the passwd entries to read something like
bin:*:3:3::/nonexistent:/nonexistent
to prevent the latter.
The directory list I last used was:
/dev
/mnt
/sbin
/usr/bin
/usr/ucb
/usr/etc
/usr/etc/yp
/usr/lib
/usr/lib/ffpa
/usr/lib/f68881
/usr/lib/fsoft
/usr/lib/fswitc
/usr/lib/lex
/usr/share
/usr/share/lib
/usr/share/lib/zoneinfo
/usr/hosts
/usr/old
/usr/kvm
/usr/kvm/stand
/usr/kvm/mdec
/usr/kvm/boot
/usr/5lib
/usr/5bin
/var
/var/adm
/var/log
/var/spool
/var/yp
/var/yp/binding
/etc
/tmp
/var/tmp
/home
Files not owned by root that I also changed (beware if any of these
are setuid on your system, in which case you shouldn't change the
ownership):
/usr/bin/screendump
/usr/bin/uuencode
/usr/bin/uudecode
/usr/lib/compile
/usr/lib/libpixrect*
/usr/lib/libcore.a
/usr/5lib/compile
The best thing is probably to do a find for all such dirs and files in
system partitions and directories, just in case things vary slightly.
Mario Wolczko
______ Dept. of Computer Science Internet: ma...@cs.man.ac.uk
/~ ~\ The University uucp: mcsun!ukc!man.cs!mario
( __ ) Manchester M13 9PL JANET: ma...@uk.ac.man.cs
`-': :`-' U.K. Tel: +44-61-275 6146 (FAX: 6236)
____; ;_____________the mushroom project___________________________________