Package: base-files
Version: 3.0.2
Severity: critical
Tags: patch security
Justification: root security hole
I recently noticed that /usr/local and /usr/local/{bin,sbin} are
group-writable and owned by root:staff. This is wrong: those directories
are in the default PATH for root. They (and files within) should be
root-owned: group staff users or become-any-user-but-root bugs should not
be able to trojan and thus get root.
The Debian Policy Manual [1] says:
... /usr/local take precedence over the equivalents in /usr.
... should have permissions 2775 and be owned by root.staff.
but it [2] also says:
... make sure that [it] is secure ...
Files should be owned by root.root ... mode 644 or 755.
Directories should be mode 755 or 2775 ... owned by the group that needs
write access to it.
The Debian Reference [3] and Securing Debian Manual [4], [5] say
[group] staff is ... for helpdesk types or junior sysadmins ... to do
things in /usr/local and to create directories in /home.
[group] staff: Allows users to add local modifications to the system
(/usr/local, /home) without needing root privileges.
The 'staff' group are usually help-desk/junior sysadmins, allowing them
to work in /usr/local and create directories in /home.
(This is surely wrong, seems a SysV left-over: you need root privileges to
chown user directories in /home or in fact to create users in /etc/passwd.)
"Junior sysadmins" should not be able or encouraged to trojan root, even if
you trust them with the root password or give them sudo privileges.
Become-any-user-but-root and become-any-group-but-root bugs are quite
common. When a group of machines share user home directories via NFS
exported from somewhere with default root-squash, getting root on one
machine gives precisely that on all others of the group. There have been
"genuine" such bugs also e.g. in sendmail [6].
This security lapse has been discussed before [7], [8].
The solution is to remove /usr/local things from the default PATH in
/root/.profile (i.e. in /usr/share/base-files/dot.profile), leaving a
warning comment instead.
It would also be good to re-word the confused policy, and to make
/usr/local root-owned. (Maybe /usr/local/sbin could then be used again.)
Discuss on debian-policy@lists.debian.org, or "reportbug debian-policy"?
References:
[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2
[2] http://www.debian.org/doc/debian-policy/ch-files.html#s10.9
[3] http://www.debian.org/doc/manuals/reference/ch-tune.en.html#s9.2.3
[4]
http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.1.12.1
[5]
http://www.debian.org/doc/manuals/securing-debian-howto/ch11.en.html#s11.1.12.2
[6] http://hackersplayground.org/papers/sendmailholes.txt
[7] http://lists.debian.org/debian-doc/2001/08/msg00041.html
[8] http://lists.debian.org/debian-user/2003/12/msg02057.html
Cheers,
Paul Szabo [EMAIL PROTECTED] http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux pisa.maths.usyd.edu.au 2.4.22-smssvr1.5.3 #1 SMP Wed Jun 23
13:01:39 EST 2004 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages base-files depends on:
ii base-passwd 3.4.1 Debian Base System Password/Group
ii gawk [awk] 1:3.1.0-3 GNU awk, a pattern scanning and pr
ii mawk [awk] 1.3.3-8 a pattern scanning and text proces
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
