On Sun, 2009-05-17 at 18:44 +0200, Göran Uddeborg wrote:
Is there some reason user_t is denied to link a file with type
var_lib_t (among others)? Or did it just happen that way? I don't
see any security advantage.
In a least privilege scheme, the question is not why should it be denied
but rather what legitimate purpose does user_t have in creating hard
links to random files under /var/lib. Generally none; in your case, you
ought to have a distinct type for those files (and if they are in fact
served via NFS, then I don't see why they would be in var_lib_t unless
you mounted the NFS filesystem with
context=system_u:object_r:var_lib_t).
user_t is supposed to be an unprivileged user account, and creating hard
links to files to which you have no create/write permissions is usually
a sign of something wrong (hence a wide variety of Linux security
patches prohibit link'ing to files you don't own).
(It doesn't matter for the question, but I suspect somebody will
ask
why I want this. The particular use case where we were hit by this is
non-standard. We have a digital TV receiver box that saves recordings
via NFS under /var/lib/TV on a server. A user wanted to edit out the
commercials from one recording using the m2vmp2cut tool. The tool is
most easy to use when the original recording is in the working
directory. She could copy the file from /var/lib/TV/... to her home
directory, but to save a lot of time and space she tried to make a
(hard) link instead. SELinux denied her that. Obviously
non-standard, and the regular policy doesn't know anything about these
files. And I know various ways to work around it, including adding a
module. But I was a bit surprised over the denial. I would have
expected user_t to be allowed to do this. Thus my question, is this
by design or by mistake?)
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list --
Stephen Smalley
National Security Agency