Red Hat Bugzilla – Bug 14539
The permissions on /var/lock are insecure
Last modified: 2014-03-16 22:15:04 EDT
%dir %attr(775,root,uucp) /var/lock %attr(775,root,root) /var/lock/subsys Basically, if GID uucp is compromised (probably via one of the SGID binaries), it becomes possible to change /var/lock/subsys into a symlink and: 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 Bugtraq. -- - 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 any) 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: http://marc.theaimsgroup.com/?l=linux-security-audit&m=96441626707601&w=2 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.)