[Yes, this is a long message, but unless you've been following the thread
on the SELinux list, the questions at the end wouldn't make much sense
without the rest. ]
Since a debate on the SELinux list came down to a question of perceived
usability, I'm writing to this list hoping to get feedback from people
who actually use SELinux-enabled commands like mkdir -Z ... dir and
install -Z ... SRC DST.
[ a little background:
RedHat's cp, mkdir, install, mkfifo, mknod all support the SELinux
--context=CTX (-Z CTX) option. That option ensures that any file system
object being created by the command has the specified SELinux context: CTX.
I'm interested in including SELinux support in "upstream" coreutils,
but am reluctant to add such an option to all of those tools, when
there may be a better way (details below). Bear in mind that I am new
to SELinux and am perhaps a little to much of a purist when it comes
to the coreutils. ]
History:
At first, when I saw that the SELinux-enabled cp provides a new
--context=CTX option, I figured mv should have the same one, since
mv sometimes needs to perform a copy. But a better way to look at
that is to wonder if cp really needs the option. It's for _copying_
after all: preserving, not changing permissions or SELinux "labels".
When I raised the issue on the SELinux mailing list, most agreed that
neither mv nor cp need that option. Of course, regardless of whether
there are new options, mv should always attempt to preserve any existing
SELinux context, and cp should be able to do so, too.
Buoyed by that, I began to think about not adding *any* of the
remaining --context=CTX (-Z CTX) options, upstream. After all, the
only thing that option does is to arrange for the application to call
setfscreatecon with the specified string before creating its first file
(or directory, pipe, etc.). I thought "why not do it *outside* the
process, rather than inside." That would be more in the Unix spirit
of things.
So I proposed a new tool, fscon (sort of like runcon):
fscon FS_CREATE_CONTEXT COMMAND [ARG...]
This hypothetical fscon command would merely exec the provided COMMAND
so that it's default file system create context would be the user-
specified FS_CREATE_CONTEXT. For example, instead of this:
mkdir --context=CTX DIR
you would use this:
fscon CTX mkdir DIR
And if policy prohibits running "fscon CTX ..." from your current
execution context, you could even do this:
runcon EXE_CTX fscon FS_CTX mkdir DIR
Using fscon rather than adding -Z options to many tools[*]
has the advantage of keeping the SELinux-specific code in one spot.
Also, it can be applied to arbitrary applications, not just ones for
which we have source and can add support for new -Z options.
Unfortunately, fscon is currently not implementable, since upon exec,
the fscreate context is always set to the policy-default. But initial
feedback suggests that with some minor restrictions, such a change may
be feasible.
On the down side, some have argued that forcing users to run a
separate program like fscon (or worse, the runcon/fscon double exec)
makes things unduly complicated. My response as upstream maintainer,
is that I'm trying to find the *right* long-term solution, even if
it means a little inconvenience in the interim. Of course, even if
upstream requires the use of something like fscon, I'm sure RHEL-
and Fedora-based tools would continue to accept the existing -Z and
--context=CTX options for a generous (or even indefinite) transition
period, maybe warning that they are obsolete and suggesting the new,
preferred usage. Besides, I contend that if the situation already
requires a "-Z CTX" option, adding the requirement to use a new
sudo-like wrapper command is not going to give anyone a headache.
Of course, this presupposes some documentation changes, and a transition
period during which the -Z-enabled tools themselves would educate users.
Another reason I'm reluctant to add SELinux-specific command-line
options upstream is because they are just that: SELinux-specific.
Do we also need options to set XATTRs? ACLs? And what if some other
MAC-based OS-add-on becomes popular? Adding a new set of options for
each of them (especially using a short-named option) is not reasonable.
Don't get me wrong. I'm all for adding support to make e.g., cp and
mv *preserve* XATTRs and SELinux context, but I'm not yet convinced
that programs like mkdir and install should have new options to _set_
those attributes. FWIW, in preparation for adding it upstream, I've
rewritten chcon (the chown analog for SELinux labels) to use fts,
just as the other ch??? programs in coreutils-6.0 do.
So, the questions to any who've read this far:
What do you think about adding the --context=CTX (-Z CTX)
(or perhaps --selinux-context=CTX) options to "upstream" coreutils?
What do you think of phasing them out of RHEL/FCn coreutils?
Does the proposed alternative use of fscon (or maybe
"runcon ... fscon ... CMD") seem too complicated?
Jim
---------
[*] Without a tool like fscon, many other tools would need an option
like --context=CTX or -Z CTX, not just the handful in coreutils; think
of tar, cpio, patch (which already has its own -Z option, btw), gzip,
and many other common programs that can create a named file.
P.S. For most of the debate on the selinux list, see this thread:
http://marc.theaimsgroup.com/?t=115530483500003
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
