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

[Christopher J. PeBenito]

On Fri, 2007-03-30 at 13:16 -0400, Karl MacMillan wrote:
> On Fri, 2007-03-30 at 17:39 +0200, Jim Meyering wrote:
> > Russell Coker <address@hidden> wrote:
> > > On Friday 30 March 2007 23:13, Jim Meyering <address@hidden> wrote:
> > >> What did you think of the proposal (in the link above) for
> > >>
> > >>     fscon CTX mkdir /new/directory
> > >>
> > >> IMHO, it's not so much less "user friendly" than this equivalent:
> > >>
> > >>     mkdir -C CTX /new/directory
> > >
> > > How about:
> > > umask whatever ; mkdir /new/directory
> > >
> > > Instead of mkdir -m whatever /new/directory?
> > 
> > I agree that having to use umask like that would be a pain,
> > but largely because you generally want to use it in a sub-shell
> > so it doesn't affect other commands.  But fscon wouldn't have
> > that problem.
> > 
> 
> Well - as Russell points out it does have a similar problem with
> privileged commands.
> 
> > 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.
> 
> <snip>
> 
> > 
> > > 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.
> 
> > 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.
> 
> Another important point to me: will distros just carry patches to add
> '-Z' for forever? Russell seemed to indicate that Debian will and I
> assume that Fedora and RHEL will. What about others - Josh/Chris, will
> you continue to carry patches if necessary in Gentoo?

Yes.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150