Bug 14539

Summary:	The permissions on /var/lock are insecure
Product:	[Retired] Red Hat Linux	Reporter:	Alexander Peslyak <solar>
Component:	filesystem	Assignee:	Bill Nottingham <notting>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2	CC:	chris, pbrown, rvokal, yiango
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	noarch
OS:	Linux
URL:	http://marc.theaimsgroup.com/?l=linux-security-audit&m=96441035801430&w=2
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-07-24 21:24:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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
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 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
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 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:
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 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.)