bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SELinux for upstream coreutils, finally (RFC: does mkdir need -Z?)


From: Jim Meyering
Subject: Re: SELinux for upstream coreutils, finally (RFC: does mkdir need -Z?)
Date: Fri, 30 Mar 2007 19:53:57 +0200

Karl MacMillan <address@hidden> wrote:
...
>> However, your example raises a good point: with mode-setting, we *do*
>> have the option of selecting a default mode via the "umask" command.
>> Currently, there is no analog to set the default SELinux file system
>> context, and that is part of why I'm arguing for the ability to write
>> "fscon".
>
> The policy can set a default that is roughly analogous to umask - but
> appropriate to SELinux - via type transition rules with a fallback to
> inheritance from the creating process / containing directory.
> Matchpathcon also has some overlap here.

Do you mean we *can* implement fscon already?
I don't think I could have misunderstood things that badly.

What I meant is that because of the fscreate-context-clearing
that happens (I think it was) at exec time, currently we can't
write a program to implement fscon semantics.

>> > Adding an option to utilities is by far the easiest option.
>>
>> In some sense (especially in the short term), it does look easier simply
>> to add the option to each program that needs it.  And I wouldn't have to
>> write so much, explaining my position :-)  However, as upstream maintainer,
>> I have to try to find the right (long term) solution.  I'm reluctant
>> to lock coreutils in to the short-term-easy solution if with a little
>> perseverance and patience we can get to a better one.
>
> I think it is far from clear that fscon is a better solution, either
> from a usage or security perspective. It also shifts complexity from
> userspace to the kernel, which is seldom desirable.

Actually, last summer, I was actually hoping for a quick negative,
along the lines "no, with SELinux it is not reasonable to make the
changes required to support fscon".  But I never got that.  On the
contrary, I got the message that it was doable, but not trivial.
Stephen Smalley's replies gave me this impression.  Please be specific,
if you think I misinterpreted something.

>> As I understood the outcome of our discussions on the selinux list back in
>> July, it would be feasible to make fscon work, but not trivial.  The main
>> objection appeared to be that fscon would not be easy for regular users
>> to find/understand/use, and that's why I ended up posting to fedora-list:
>> trying to get feedback from people not already up to their elbows in
>> the guts of SELinux.
>
> That wasn't what I got out of that discussion. The usability concerns
> are important, but the proposed kernel mechanism has some serious
> semantic issues that I don't think have been resolved. Again, I don't
> think that we are actually searching for a better solution, but rather
> shifting where the complexity resides. The '-Z' option, while requiring
> changing a lot of software, is conceptually clear and doesn't require
> much code. That makes it the better option in my opinion.

Perhaps if I knew more about SELinux, I would understand why it seems
better to add a new option to so many tools (there are far more than just
these four in coreutils) than to provide a single tool that could also
be applied to programs that we don't have the luxury of adding options to.

If the people responsible for SELinux development can tell me they are
confident that my pursuing this is not worthwhile, (i.e., fscon won't
be implementable any time soon), I'll have no choice but to let this
thread die.  That's what I wanted months ago -- it sure would have saved
some debating.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]