Bug 14539 - The permissions on /var/lock are insecure
The permissions on /var/lock are insecure
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: filesystem (Show other bugs)
6.2
noarch Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
http://marc.theaimsgroup.com/?l=linux...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-07-24 13:28 EDT by Alexander Peslyak
Modified: 2014-03-16 22:15 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-07-24 17:24:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexander Peslyak 2000-07-24 13:28:31 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.)
Comment 1 Chris Evans 2000-07-24 16:24:54 EDT
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 ;-)
Comment 2 Chris Evans 2000-07-24 16:25:55 EDT
Ah... I wasn't logged in... I see severity is already security :-)
Comment 3 Bill Nottingham 2000-07-24 16:32:33 EDT
Does adding the sticky bit to /var/lock seem like
an agreeable solution?
Comment 4 Chris Evans 2000-07-24 16:55:26 EDT
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. >-)
Comment 5 Alexander Peslyak 2000-07-24 17:24:30 EDT
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.
Comment 6 Bill Nottingham 2001-04-16 12:32:34 EDT
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 01:26:58 EDT
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.