%dir %attr(775,root,uucp) /var/lock
Basically, if GID uucp is compromised (probably via one of the SGID
binaries), it becomes possible to change /var/lock/subsys into a
1. Create empty root-owned files anywhere and under arbitrary names.
2. 'touch' any existing file.
3. Remove critical system binaries that are named the same as their
corresponding lock files (atd, crond, gpm, lpd, routed, rwhod, sshd,
and perhaps some others).
4. Remove most of the scripts in /etc/rc.d/init.d.
5. Remove /dev/random and /etc/logrotate.d/syslog.
(Please, see the security-audit posting for other related issues.)
This could get _messy_
After a bit of research, here's a quote from a Michal Zalewski posting to
- gkermit - can read/write/append files with egid==uucp; these file
include many /dev/ entries, /etc/uucp/passwd etc; can
be dangerous on systems running uucp.
In fact see Bugzilla bug #11870 which details gkermit brokenness.
I don't believe the gkermit author condones gkermit being sgid-uucp
This indicates sloppiness in gkermit... may be an easy gid==uucp. And hence
grief as outlined by Solar above.
I don't seem to have permission to change this bug. Could severity be changed to
security? I have a nice saved query to get all security bugs ;-)
Ah... I wasn't logged in... I see severity is already security :-)
Does adding the sticky bit to /var/lock seem like
an agreeable solution?
Hmm.. stops the immediately obvious danger (and this is what Slackware do
according to the security-audit post pointed to by URL)
However, any transient files in /var/lock will still be vulnerable (if there are
Is a separate /var/lock/uucp directory feasible? Can the uucp package be
recompiled to use an arbitrary lock dir?
Can uucp be deprecated? Muhahahah evil laughter etc. >-)
The sticky bit is a workaround I could apply to an installed system. This can
result in problems with stale lock files, see the reply from Olaf Kirch:
My vote is for the addition of /var/lock/uucp and 755 on /var/lock.
/var/lock/subsys should also be changed to 755.
Fixed in filesystem-2.0.8-1; currently there is *no* new /var/lock/uucp; I
may look at creating one as part of the uucp package (it's the only setgid
uucp thing left.)
Actually, we're rearranging how this is done.
FHS calls for /var/lock for device files.
So, it will be 775, root.lock.
A new setgid helper (think: utempter) will be used to make lock files
there. pam_console & samba are being moved out of the /var/lock heirarchy.
initscripts will follow at the next major release (with a compat symlink.)