[systemd-devel] [HEADSUP] /var/lock and /var/lock/lockdev
Lennart Poettering
lennart at poettering.net
Thu Mar 31 15:33:01 PDT 2011
Heya,
A few minutes ago there was a discussion on #systemd involving lots of
folks (from various distros even), regarding the chaotic setup of
/var/lock on most distros. As it turns out every distro set this up
differently, and almost all of them insecurely in one way or another.
I'd like to see this cleaned up and standardized in a secure way among
the distros, so here's what I propose for adoption:
/var/lock should be root:root 0755 and the place for various system
service lock directories such as /var/lock/subsys or /var/lock/lvm.
/var/lock/lockdev should be root:lock 0775 and the place for
LCK..xxx style device lock files.
Why?
- We need to separate system service locks (i.e. root-only locks as
stored in /var/lock/lvm/* or /var/lock/subsys/*) from LCK..xxx device
locks (locks which user programs may acquire). Otherwise it is
possible for users which somehow manage to get into the lock group to
replace files like /var/lock/lvm or
/var/lock/subsys by their own files, for example symlinks, which can
be used to to exploit the system if later on an unexpecting root
process accesses the dir again. This is explained in more detail here:
https://bugzilla.redhat.com/show_bug.cgi?id=581884
- We cannot use the sticky bit on the LCK..xxx dir, because user apps
must be able to remove stale lock files of other users:
https://bugzilla.redhat.com/show_bug.cgi?id=145264#c1
- We should not create another world-writable dir, hence limit access to
a group "lock", so that only apps which are in that group can create
an LCK..xxx lock. it is recommended to do that with a library such as
liblockdev, which comes with a little setgid helper which creates the
actual file.
I have also filed a bug against the (dead, but hey, let's think positive)
FHS in the hope this gets standardized one day:
http://bugs.freestandards.org/show_bug.cgi?id=719
I have also changed the default tmpfiles file in systemd
accordingly. Distros may deviate from this by patching this downstream,
but by shipping this as secure default I do hope to gently push
everybody in the same direction.
What does that mean for you, distro packager?
1. File a bug against your distro copying
https://bugzilla.redhat.com/show_bug.cgi?id=581884 if it is
vulnerable, since this is a security hole that should be fixed.
2. Two options:
A: Patch our new defaults out, and ignore our suggestions and do your
own stuff.
B: Adapt the suggested scheme in your distro: introduce a "lock"
group, and change all apps writing LCK..xxx lock files to
do so in /var/lock/lockdev/ and that after becoming a member of
"lock" somehow, in case the process is not privileged.
Ideas? Comments? Suggestions?
Thanks everybody who explained the intricacies of all of this to me,
Michal, Karel, Michael in particular.
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel
mailing list