Re: justifying --context=CTX (-Z) for upstream coreutils, like mkdir

[Jim Meyering <jim@meyering.net>]

Joshua Brindle <jbrindle@tresys.com> wrote:

> On Tue, 2006-08-22 at 18:03 +0200, Jim Meyering wrote:
>> Joshua Brindle <jbrindle@tresys.com> wrote:
>> > Jim Meyering wrote:
>> >> "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
>> > <snip>
>> But I did.
>> Perhaps it doesn't address points that are obvious to you?
>> I interpret "Fscon doesn't work for any program..." as meaning that it
>> is not an appropriate tool for them.  Not that it would cause any harm.
>> Perhaps you interpret it as meaning "fscon could cause arbitrary programs
>> to misbehave"?
>
> It could cause harm if users have to manage contexts in different ways
> depending on the app they are using.

Is the "harm" you suggest that a user would have to choose between
whether to use just fscon or the combination of runcon and fscon?

I envisioned that a lone fscon would fail in the case that it is
insufficient, i.e., when runcon would be required.  Then fscon could
even give a diagnostic suggesting the syntax of the runcon command that
might do the job.

>> I think there's a deeper difference in our understanding of how
>> this hypothetical fscon program would work.  I expect that fscon
>> would call some new function to request that a specified fscreate
>> context be applied (as the default) to the next exec call.
>> When I first read the descriptions of setexeccon and setfscreatecon,
>> I thought the latter would do just what I wanted.  Unfortunately,
>> its semantics aren't analogous to those of setexeccon.
>
> setexeccon sets the context for the next execution, not the context for
> the next execution of the next execution, these are not in any way
> comparable.

Sorry, I can't parse that.
I'll rephrase the part I understand:
  setexeccon sets the execution context for the next execve call

I would like fscon to set the default fscreate context to take effect
for the next execve call -- then it performs that execve call.

...
>> > Being able to set your childrens fscreatecon is _dangerous_ and
>> > potentially affects robustness if a parent forgets to unset it before
>> > spawning children. Granted doing this across domain transitions can (and
>> > must) be protected by policy but within the same domain there is little
>> > that can be done. You'll risk making the filesystem inconsistent with this.
>> >
>> > I honestly don't understand the problem here, these applications are
>> > simple and adding -Z (to be standard with every other selinux aware
>> > util) doesn't hurt anything. fscon is _not_ a better way to do this, its
>> > a hack that can only be used by coreutils because of the point above
>> > that any app of sufficient complexity will be writing files with
>> > different contexts.
>>
>> I'm concerned that if there's a better way (fscon), adding "-Z CTX" in
>> many tools would be a hack.
>
> how is fscon a better way? What other tool in Linux sets attributes for
> the next exec this way? (don't say su or sudo, those are used _before_
> the upcoming exec, not _in_ the next exec). Very unintuitive IMO.

It's more of the one task, one tool Unix approach to problem solving.
Another program that works this way: setarch.
Both were mentioned in my earlier posts.

In principle, what I'm suggesting is no more unusual than what the
setarch program does nor what the setexeccon function does.

>> Did you see both of my messages to this list yesterday?
>> And the long one I posted to fedora-list?
>>   https://www.redhat.com/archives/fedora-list/2006-August/msg02264.html
>> I've tried hard to explain why I am so reluctant to add "-Z CTX" to
>> the coreutils.  If something isn't clear, or if you disagree with
>> specific reasons, please give details.
>
> I read them, I don't see anything about fscon compelling, like I said,
> very unintuitive. You mention using something like this for tar but,
> once again, anything that writes more than 1 file is going to want find
> grained labeling support. Tar is going to need to write labels that it
> has stored, not random labels that its parent is giving it.

The patch program (which I also mentioned) is a better example.

If tar doesn't need an option like "-Z CTX" (-Z is already taken),
then it certainly wouldn't be necessary to invoke it via fscon.
However, since there are options to ignore owner and permission
information from the archive, I can imagine fscon being useful in
any case, e.g., to do this:

  fscon FSCON tar -x --no-same-owner --no-same-permissions ...

> On that note, how do you plan on reconciling when the parent says one
> thing and the child says another? How unintuitive would it be if the
> child simply ignored the parent (which it probably would) even when the
> user is trying to use fscon.

I see it more as an advisory tool.  In the absence of specific
settings made by the child, apply this default fscreate context.
The child can still call setfscreatecon.  fscon is not intended
to be able to override that.  Think of it as a immediately-post-exec
(in-child) call to setfscreatecon.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.