Bug 14539 - The permissions on /var/lock are insecure
Summary: The permissions on /var/lock are insecure
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: filesystem
Version: 6.2
Hardware: noarch
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
URL: http://marc.theaimsgroup.com/?l=linux...
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2000-07-24 17:28 UTC by Alexander Peslyak
Modified: 2014-03-17 02:15 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2000-07-24 21:24:30 UTC

Attachments (Terms of Use)

Description Alexander Peslyak 2000-07-24 17:28:31 UTC
%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.)

Comment 1 Chris Evans 2000-07-24 20:24:54 UTC
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 ;-)

Comment 2 Chris Evans 2000-07-24 20:25:55 UTC
Ah... I wasn't logged in... I see severity is already security :-)

Comment 3 Bill Nottingham 2000-07-24 20:32:33 UTC
Does adding the sticky bit to /var/lock seem like
an agreeable solution?

Comment 4 Chris Evans 2000-07-24 20:55:26 UTC
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. >-)

Comment 5 Alexander Peslyak 2000-07-24 21:24:30 UTC
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.

Comment 6 Bill Nottingham 2001-04-16 16:32:34 UTC
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.)

Comment 7 Bill Nottingham 2001-08-09 05:26:58 UTC
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.)

Note You need to log in before you can comment on or make changes to this bug.