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

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

[Jim Meyering]

Hello again,

With clear agreement that neither cp nor mv needs the --context=CTX (-Z)
option, I am nearly convinced that the this option does not belong in any
other program in upstream coreutils.  [of course, I expect it to remain
in RHEL and probably in Fedora for some time]  Upstream coreutils will
display contexts (stat, ls, uname), and preserve them (cp, mv, install?),
and add chcon+runcon, but that's all.

For a little context on why, ...
I'm also considering the xattr patch that's been floating around for
years.  Currently it's part of SuSE's coreutils patch set.  It ensures
that mv and cp -p preserve any (selected) XATTR attributes.  There is
no option to let install(1) apply XATTR attributes.  Nor mkdir, mkfifo,
mknod.  Similarly for the ACL support that's widely available, there is
no option to let those programs apply a specified ACL.  Why should
SELinux security contexts be treated differently?

I do understand the race condition argument, but any sysadmin who is
silly enough to create new files in such a way that those races matter,
deserves whatever s/he gets.  If a destination file really must be in a
vulnerable place, it's not so hard to create it first in a safe place,
apply any necessary context via chcon, and then `install' them via rename.

Am I missing some justification for why e.g., mkdir should have the
option?  Yes, it does accept --mode=M (-m), but is that enough to
justify the SELinux---ACL/XATTR dichotomy?  Not to me.  But I'm
willing to be educated :)

BTW, what makes install so special that it needs to call matchpathcon?
Can it accomplish the same goal via "chcon ...;
install --preserve-context ..."?

Thanks for your feedback,

Jim

--
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.

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

[Karl MacMillan]

On Fri, 2006-08-11 at 15:58 +0200, Jim Meyering wrote:
> Hello again,
> 
> With clear agreement that neither cp nor mv needs the --context=CTX (-Z)
> option, I am nearly convinced that the this option does not belong in any
> other program in upstream coreutils.  [of course, I expect it to remain
> in RHEL and probably in Fedora for some time]  Upstream coreutils will
> display contexts (stat, ls, uname), and preserve them (cp, mv, install?),
> and add chcon+runcon, but that's all.
> 
> For a little context on why, ...
> I'm also considering the xattr patch that's been floating around for
> years.  Currently it's part of SuSE's coreutils patch set.  It ensures
> that mv and cp -p preserve any (selected) XATTR attributes.

Only selected attributes or you can optionally preserve only a subset?
I.e., is the default to preserve all?

>   There is
> no option to let install(1) apply XATTR attributes.

Is there a need for this? I have no idea.

>   Nor mkdir, mkfifo,
> mknod.  Similarly for the ACL support that's widely available, there is
> no option to let those programs apply a specified ACL.  Why should
> SELinux security contexts be treated differently?

Acls are a discretionary mechanism and it is, therefore, appropriate for
them to be applied by users after file creation.

SELinux is fundamentally different as a mandatory mechanism and a core
property is that objects should be labeled correctly at creation time.

> 
> I do understand the race condition argument, but any sysadmin who is
> silly enough to create new files in such a way that those races matter,
> deserves whatever s/he gets.

But what real options do they have? Forcing the app to install into a
DESTDIR, labeling and copying? What about a developer trying to
distribute a tarball with selinux support at install - what option would
this leave them?

>   If a destination file really must be in a
> vulnerable place, it's not so hard to create it first in a safe place,
> apply any necessary context via chcon, and then `install' them via rename.
> 

You are assuming a policy where relabeling is allowed fairly broadly -
not all policies are written in this way. Heavily locked-down systems
will want to prevent relabeling wherever possible and not providing
tools to create files labeled correctly prevents this.

> Am I missing some justification for why e.g., mkdir should have the
> option?  Yes, it does accept --mode=M (-m), but is that enough to
> justify the SELinux---ACL/XATTR dichotomy?  Not to me.  But I'm
> willing to be educated :)
> 

Again, SELinux is fundamentally different from ACL/XATTRs.

> BTW, what makes install so special that it needs to call matchpathcon?
> Can it accomplish the same goal via "chcon ...;
> install --preserve-context ..."?
> 

It allows install to correctly label for different policies, including
policies distributed separately from the application. Otherwise the
makefile must hardcode all possible labels in the chcon statements or
provide a mechanism that is essentially matchpathcon.

This could be done with the separate matchpatcon utility though, so I
wouldn't be against dropping this.

Karl

> Thanks for your feedback,
> 
> Jim
> 
> --
> 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.

--
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.

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

[Stephen Smalley]

On Fri, 2006-08-11 at 10:58 -0400, Karl MacMillan wrote:
> On Fri, 2006-08-11 at 15:58 +0200, Jim Meyering wrote:
> > Hello again,
> > 
> > With clear agreement that neither cp nor mv needs the --context=CTX (-Z)
> > option, I am nearly convinced that the this option does not belong in any
> > other program in upstream coreutils.  [of course, I expect it to remain
> > in RHEL and probably in Fedora for some time]  Upstream coreutils will
> > display contexts (stat, ls, uname), and preserve them (cp, mv, install?),
> > and add chcon+runcon, but that's all.
> > 
> > For a little context on why, ...
> > I'm also considering the xattr patch that's been floating around for
> > years.  Currently it's part of SuSE's coreutils patch set.  It ensures
> > that mv and cp -p preserve any (selected) XATTR attributes.
> 
> Only selected attributes or you can optionally preserve only a subset?
> I.e., is the default to preserve all?
> 
> >   There is
> > no option to let install(1) apply XATTR attributes.
> 
> Is there a need for this? I have no idea.
> 
> >   Nor mkdir, mkfifo,
> > mknod.  Similarly for the ACL support that's widely available, there is
> > no option to let those programs apply a specified ACL.  Why should
> > SELinux security contexts be treated differently?
> 
> Acls are a discretionary mechanism and it is, therefore, appropriate for
> them to be applied by users after file creation.
> 
> SELinux is fundamentally different as a mandatory mechanism and a core
> property is that objects should be labeled correctly at creation time.
> 
> > 
> > I do understand the race condition argument, but any sysadmin who is
> > silly enough to create new files in such a way that those races matter,
> > deserves whatever s/he gets.
> 
> But what real options do they have? Forcing the app to install into a
> DESTDIR, labeling and copying? What about a developer trying to
> distribute a tarball with selinux support at install - what option would
> this leave them?
> 
> >   If a destination file really must be in a
> > vulnerable place, it's not so hard to create it first in a safe place,
> > apply any necessary context via chcon, and then `install' them via rename.
> > 
> 
> You are assuming a policy where relabeling is allowed fairly broadly -
> not all policies are written in this way. Heavily locked-down systems
> will want to prevent relabeling wherever possible and not providing
> tools to create files labeled correctly prevents this.
> 
> > Am I missing some justification for why e.g., mkdir should have the
> > option?  Yes, it does accept --mode=M (-m), but is that enough to
> > justify the SELinux---ACL/XATTR dichotomy?  Not to me.  But I'm
> > willing to be educated :)
> > 
> 
> Again, SELinux is fundamentally different from ACL/XATTRs.
> 
> > BTW, what makes install so special that it needs to call matchpathcon?
> > Can it accomplish the same goal via "chcon ...;
> > install --preserve-context ..."?
> > 
> 
> It allows install to correctly label for different policies, including
> policies distributed separately from the application. Otherwise the
> makefile must hardcode all possible labels in the chcon statements or
> provide a mechanism that is essentially matchpathcon.
> 
> This could be done with the separate matchpatcon utility though, so I
> wouldn't be against dropping this.

The only thing I would add here is that the install(1) change to use
matchpathcon(3) was to parallel the corresponding logic in rpm, so that
non-rpm packages (e.g. ordinary upstream tarballs that people build and
install via make install) would have their files labeled correctly at
install time too.  Otherwise, admins have to take extra steps to get
such files labeled correctly.  At installation time, you generally need
some external knowledge of the right security attributes for the file,
which is what matchpathcon is providing.  Whereas cp or mv can operate
based on the original security attributes of the file, plus the process'
attributes.
  
-- 
Stephen Smalley
National Security Agency


--
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.

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

[Casey Schaufler]

--- Karl MacMillan <kmacmillan@mentalrootkit.com>
wrote:

> >   There is
> > no option to let install(1) apply XATTR
> attributes.
> 
> Is there a need for this? I have no idea.

The Irix xattr experiance, wherein inst(1) did
not do extended attributes, leads me to suggest
strongly that install(1) be enhanced to do so.

> 
> >   Nor mkdir, mkfifo,
> > mknod.  Similarly for the ACL support that's
> widely available, there is
> > no option to let those programs apply a specified
> ACL.  Why should
> > SELinux security contexts be treated differently?

When an attribute is optional (e.g. an ACL)
and the object is useful without it, there's
no issues. Whan an attribute is required
(e.g. a sensitivity label) it's a fish of
another color. Since every file needs a
sensitivity, and the install program is
responsible for the initial state of the
file, install needs to set it. Sure, you
can put together a multipass scheme if
you can't put it in install, but that's
another divergence.

> Acls are a discretionary mechanism and it is,
> therefore, appropriate for
> them to be applied by users after file creation.
> 
> SELinux is fundamentally different as a mandatory
> mechanism and a core
> property is that objects should be labeled correctly
> at creation time.

Yes. My experiance with xattrs backs Karl's
arguments from here.



Casey Schaufler
casey@schaufler-ca.com

--
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.

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

[Jim Meyering]

Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:

> On Fri, 2006-08-11 at 15:58 +0200, Jim Meyering wrote:
>> Hello again,
>>
>> With clear agreement that neither cp nor mv needs the --context=CTX (-Z)
>> option, I am nearly convinced that the this option does not belong in any
>> other program in upstream coreutils.  [of course, I expect it to remain
>> in RHEL and probably in Fedora for some time]  Upstream coreutils will
>> display contexts (stat, ls, uname), and preserve them (cp, mv, install?),
>> and add chcon+runcon, but that's all.
>>
>> For a little context on why, ...
>> I'm also considering the xattr patch that's been floating around for
>> years.  Currently it's part of SuSE's coreutils patch set.  It ensures
>> that mv and cp -p preserve any (selected) XATTR attributes.
>
> Only selected attributes or you can optionally preserve only a subset?
> I.e., is the default to preserve all?

mv tries to preserve all of them.
That patch set adds this option to cp:

      --attributes=regex       preserve extended attributes whose name
                               matches the specified regular expression
                               (defaults to preserving all extended
                               attributes except file permissions;
                               regex=`-' preserves no extended attributes).

>>   There is
>> no option to let install(1) apply XATTR attributes.
>
> Is there a need for this? I have no idea.
>
>>   Nor mkdir, mkfifo,
>> mknod.  Similarly for the ACL support that's widely available, there is
>> no option to let those programs apply a specified ACL.  Why should
>> SELinux security contexts be treated differently?
>
> Acls are a discretionary mechanism and it is, therefore, appropriate for
> them to be applied by users after file creation.
>
> SELinux is fundamentally different as a mandatory mechanism and a core
> property is that objects should be labeled correctly at creation time.

If using chcon is sometimes not an option for a user who must be able
to create files in a non-default context, then we have to choose between:

  1) adding the --context=CTX (-Z) option to many of the programs
      that create a named output file.

  2) providing a tool to change the fscreate context for an exec'd program

The latter seems much cleaner.
Is there any hope on that front?
The problem is that if I add an options upstream, it's
a big deal/hassle to remove it later, if a more appropriate
mechanism becomes available.  As long as there's a hint
of hope for a cleaner approach, I'm extremely reluctant
to impose on the coreutils something that looks like a kludge.

...
>> BTW, what makes install so special that it needs to call matchpathcon?
>> Can it accomplish the same goal via "chcon ...;
>> install --preserve-context ..."?
>
> It allows install to correctly label for different policies, including
> policies distributed separately from the application. Otherwise the
> makefile must hardcode all possible labels in the chcon statements or
> provide a mechanism that is essentially matchpathcon.
>
> This could be done with the separate matchpatcon utility though, so I
> wouldn't be against dropping this.

Thanks for explaining.
If install really needs -Z, I'd prefer to drop its internal
use of matchpathcon.

--
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.

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

[Daniel J Walsh]

Jim Meyering wrote:
> Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:
>
>   
>> On Fri, 2006-08-11 at 15:58 +0200, Jim Meyering wrote:
>>     
>>> Hello again,
>>>
>>> With clear agreement that neither cp nor mv needs the --context=CTX (-Z)
>>> option, I am nearly convinced that the this option does not belong in any
>>> other program in upstream coreutils.  [of course, I expect it to remain
>>> in RHEL and probably in Fedora for some time]  Upstream coreutils will
>>> display contexts (stat, ls, uname), and preserve them (cp, mv, install?),
>>> and add chcon+runcon, but that's all.
>>>
>>> For a little context on why, ...
>>> I'm also considering the xattr patch that's been floating around for
>>> years.  Currently it's part of SuSE's coreutils patch set.  It ensures
>>> that mv and cp -p preserve any (selected) XATTR attributes.
>>>       
>> Only selected attributes or you can optionally preserve only a subset?
>> I.e., is the default to preserve all?
>>     
>
> mv tries to preserve all of them.
> That patch set adds this option to cp:
>
>       --attributes=regex       preserve extended attributes whose name
>                                matches the specified regular expression
>                                (defaults to preserving all extended
>                                attributes except file permissions;
>                                regex=`-' preserves no extended attributes).
>
>   
>>>   There is
>>> no option to let install(1) apply XATTR attributes.
>>>       
>> Is there a need for this? I have no idea.
>>
>>     
>>>   Nor mkdir, mkfifo,
>>> mknod.  Similarly for the ACL support that's widely available, there is
>>> no option to let those programs apply a specified ACL.  Why should
>>> SELinux security contexts be treated differently?
>>>       
>> Acls are a discretionary mechanism and it is, therefore, appropriate for
>> them to be applied by users after file creation.
>>
>> SELinux is fundamentally different as a mandatory mechanism and a core
>> property is that objects should be labeled correctly at creation time.
>>     
>
> If using chcon is sometimes not an option for a user who must be able
> to create files in a non-default context, then we have to choose between:
>
>   1) adding the --context=CTX (-Z) option to many of the programs
>       that create a named output file.
>
>   2) providing a tool to change the fscreate context for an exec'd program
>
> The latter seems much cleaner.
> Is there any hope on that front?
> The problem is that if I add an options upstream, it's
> a big deal/hassle to remove it later, if a more appropriate
> mechanism becomes available.  As long as there's a hint
> of hope for a cleaner approach, I'm extremely reluctant
> to impose on the coreutils something that looks like a kludge.
>
> ...
>   
>>> BTW, what makes install so special that it needs to call matchpathcon?
>>> Can it accomplish the same goal via "chcon ...;
>>> install --preserve-context ..."?
>>>       
>> It allows install to correctly label for different policies, including
>> policies distributed separately from the application. Otherwise the
>> makefile must hardcode all possible labels in the chcon statements or
>> provide a mechanism that is essentially matchpathcon.
>>
>> This could be done with the separate matchpatcon utility though, so I
>> wouldn't be against dropping this.
>>     
>
> Thanks for explaining.
> If install really needs -Z, I'd prefer to drop its internal
> use of matchpathcon.
>   
-Z implies that the builder of the application knows the security 
context for all possible environemnts.  Matchpatchcon asks the system 
how a file in a certain path should be labeled.  They are very different 
things.

Two different machines running the same install could/should have 
different end file context.  For example a strict policy machine might 
label firefox, mozilla_exec_t, while a targeted might label it bin_t.
> --
> 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.
>   


--
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.

install vs. matchpathcon(8) [Re: justifying --context=CTX (-Z) ...

[Jim Meyering]

Daniel J Walsh <dwalsh@redhat.com> wrote:
> Jim Meyering wrote:
>>>> BTW, what makes install so special that it needs to call matchpathcon?
>>>> Can it accomplish the same goal via "chcon ...;
>>>> install --preserve-context ..."?
...
>> Thanks for explaining.
>> If install really needs -Z, I'd prefer to drop its internal
>> use of matchpathcon.
>>
> -Z implies that the builder of the application knows the security
> context for all possible environemnts.  Matchpatchcon asks the system
> how a file in a certain path should be labeled.  They are very different
> things.
>
> Two different machines running the same install could/should have
> different end file context.  For example a strict policy machine might
> label firefox, mozilla_exec_t, while a targeted might label it bin_t.

[Oh!  I see I never send this reply. ]

I'm inclined to keep upstream GNU install minimalist.  So if there's
a way to accomplish this task without embedding the specialized
matchpathcon-related code, I have to ask "why embed?".  If by adding
only -Z (or providing an fscon program), I don't absolutely need to
include the matchpathcon-calling code in install.c, then I'd rather not.

For example, can't one use the matchpathcon _program_ like this?

  install -Z $(matchpathcon -n $bindir/SOME_EXECUTABLE) SOME_EXECUTABLE $bindir

This seems better, since it'd work any version of install:

  fscon -Z $(matchpathcon -n $bindir/SOME_EXECUTABLE) \
    install SOME_EXECUTABLE $bindir

Obviously, that's more verbose than we'd prefer, but an
selinux-specific wrapper script could do the job transparently.
Then, the only change would be to build via "make INSTALL=install-con".

--
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.

Re: install vs. matchpathcon(8) [Re: justifying --context=CTX (-Z) ...

[Stephen Smalley]

On Fri, 2006-08-18 at 12:37 +0200, Jim Meyering wrote:
> Daniel J Walsh <dwalsh@redhat.com> wrote:
> > Jim Meyering wrote:
> >>>> BTW, what makes install so special that it needs to call matchpathcon?
> >>>> Can it accomplish the same goal via "chcon ...;
> >>>> install --preserve-context ..."?
> ...
> >> Thanks for explaining.
> >> If install really needs -Z, I'd prefer to drop its internal
> >> use of matchpathcon.
> >>
> > -Z implies that the builder of the application knows the security
> > context for all possible environemnts.  Matchpatchcon asks the system
> > how a file in a certain path should be labeled.  They are very different
> > things.
> >
> > Two different machines running the same install could/should have
> > different end file context.  For example a strict policy machine might
> > label firefox, mozilla_exec_t, while a targeted might label it bin_t.
> 
> [Oh!  I see I never send this reply. ]
> 
> I'm inclined to keep upstream GNU install minimalist.  So if there's
> a way to accomplish this task without embedding the specialized
> matchpathcon-related code, I have to ask "why embed?".  If by adding
> only -Z (or providing an fscon program), I don't absolutely need to
> include the matchpathcon-calling code in install.c, then I'd rather not.
> 
> For example, can't one use the matchpathcon _program_ like this?
> 
>   install -Z $(matchpathcon -n $bindir/SOME_EXECUTABLE) SOME_EXECUTABLE $bindir
> 
> This seems better, since it'd work any version of install:
> 
>   fscon -Z $(matchpathcon -n $bindir/SOME_EXECUTABLE) \
>     install SOME_EXECUTABLE $bindir
> 
> Obviously, that's more verbose than we'd prefer, but an
> selinux-specific wrapper script could do the job transparently.
> Then, the only change would be to build via "make INSTALL=install-con".

This breaks down when you are installing multiple files that should have
different contexts to a single destination directory via a single
install command.  And the point of the install modification to use
matchpathcon was to provide transparency for users, so that when a
typical admin does a 'make install' of his favorite third party software
that is not packaged as an rpm, the installed files are labeled
correctly.

-- 
Stephen Smalley
National Security Agency


--
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.

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

[Karl MacMillan]

On Fri, 2006-08-11 at 18:45 +0200, Jim Meyering wrote:
> Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:
> 

<snip>

> >>   Nor mkdir, mkfifo,
> >> mknod.  Similarly for the ACL support that's widely available, there is
> >> no option to let those programs apply a specified ACL.  Why should
> >> SELinux security contexts be treated differently?
> >
> > Acls are a discretionary mechanism and it is, therefore, appropriate for
> > them to be applied by users after file creation.
> >
> > SELinux is fundamentally different as a mandatory mechanism and a core
> > property is that objects should be labeled correctly at creation time.
> 
> If using chcon is sometimes not an option for a user who must be able
> to create files in a non-default context, then we have to choose between:
> 
>   1) adding the --context=CTX (-Z) option to many of the programs
>       that create a named output file.
> 
>   2) providing a tool to change the fscreate context for an exec'd program
> 
> The latter seems much cleaner.
> Is there any hope on that front?
> The problem is that if I add an options upstream, it's
> a big deal/hassle to remove it later, if a more appropriate
> mechanism becomes available.  As long as there's a hint
> of hope for a cleaner approach, I'm extremely reluctant
> to impose on the coreutils something that looks like a kludge.
> 

So your thinking is that the user would have to run a tool - e.g.:

fscon -t httpd_sys_content_t touch foo.html

Whether this is cleaner from an implementation perspective I think is
questionable, particularly because the restrictions (must have same
context as caller) will be confusing. This is especially with MLS.
Additionally, how are we going to then handle cases where the contexts
don't match (for example, running install in a different context to
limit what contexts it can set)?

More importantly to me, though, is that this mechanism will be much
harder to find for users and will break several years of documented
behavior. I think that the explicit options are the correct model from a
user perspective.

Karl


--
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.

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

[Jim Meyering]

Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:
...
>> > Acls are a discretionary mechanism and it is, therefore, appropriate for
>> > them to be applied by users after file creation.
>> >
>> > SELinux is fundamentally different as a mandatory mechanism and a core
>> > property is that objects should be labeled correctly at creation time.
>>
>> If using chcon is sometimes not an option for a user who must be able
>> to create files in a non-default context, then we have to choose between:
>>
>>   1) adding the --context=CTX (-Z) option to many of the programs
>>       that create a named output file.
>>
>>   2) providing a tool to change the fscreate context for an exec'd program
>>
>> The latter seems much cleaner.
>> Is there any hope on that front?
>> The problem is that if I add an options upstream, it's
>> a big deal/hassle to remove it later, if a more appropriate
>> mechanism becomes available.  As long as there's a hint
>> of hope for a cleaner approach, I'm extremely reluctant
>> to impose on the coreutils something that looks like a kludge.

Hi Karl,

> So your thinking is that the user would have to run a tool - e.g.:
>
> fscon -t httpd_sys_content_t touch foo.html

Exactly.
Your example brings up the question of whether touch needs -Z CTX.
The user-specified context would be relevant only when creating a file,
not when merely updating atime or mtime, and hence, it'd be used only
when creating an _empty_ file.  Can you think of a context in which the
context of a regular, zero-length file actually matters?  I couldn't.
I.e., there's no risk of a race: if the context matters, applying it
via chcon as a separate step, after invoking touch would be safe.
Maybe that's why touch (on an SELinux system) doesn't already have
this option.

> Whether this is cleaner from an implementation perspective I think is
> questionable, particularly because the restrictions (must have same
> context as caller) will be confusing. This is especially with MLS.
> Additionally, how are we going to then handle cases where the contexts
> don't match (for example, running install in a different context to
> limit what contexts it can set)?

Can't we use runcon to work around that limitation?

  runcon -Z ... fscon -t httpd_sys_content_t touch foo.html

> More importantly to me, though, is that this mechanism will be much
> harder to find for users and will break several years of documented
> behavior. I think that the explicit options are the correct model from a
> user perspective.

I wouldn't expect anything in FCx or RHEL to change overnight.
The usual routine is to let the option in question continue to work
for some time, but with an added diagnostic saying that it is slated
to be removed, and suggesting the new/preferred approach.  Then, only
a couple of years later, would it actually be removed.

Jim

--
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.

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

[Karl MacMillan]

On Mon, 2006-08-14 at 17:53 +0200, Jim Meyering wrote:
> Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:
> ...
> >> > Acls are a discretionary mechanism and it is, therefore, appropriate for
> >> > them to be applied by users after file creation.
> >> >
> >> > SELinux is fundamentally different as a mandatory mechanism and a core
> >> > property is that objects should be labeled correctly at creation time.
> >>
> >> If using chcon is sometimes not an option for a user who must be able
> >> to create files in a non-default context, then we have to choose between:
> >>
> >>   1) adding the --context=CTX (-Z) option to many of the programs
> >>       that create a named output file.
> >>
> >>   2) providing a tool to change the fscreate context for an exec'd program
> >>
> >> The latter seems much cleaner.
> >> Is there any hope on that front?
> >> The problem is that if I add an options upstream, it's
> >> a big deal/hassle to remove it later, if a more appropriate
> >> mechanism becomes available.  As long as there's a hint
> >> of hope for a cleaner approach, I'm extremely reluctant
> >> to impose on the coreutils something that looks like a kludge.
> 
> Hi Karl,
> 
> > So your thinking is that the user would have to run a tool - e.g.:
> >
> > fscon -t httpd_sys_content_t touch foo.html
> 
> Exactly.
> Your example brings up the question of whether touch needs -Z CTX.
> The user-specified context would be relevant only when creating a file,
> not when merely updating atime or mtime, and hence, it'd be used only
> when creating an _empty_ file.  Can you think of a context in which the
> context of a regular, zero-length file actually matters?  I couldn't.
> I.e., there's no risk of a race: if the context matters, applying it
> via chcon as a separate step, after invoking touch would be safe.
> Maybe that's why touch (on an SELinux system) doesn't already have
> this option.
> 

Again, you are assuming that relabeling is always possible. It is
possible for the policy to severely limit or completely prohibit
relabeling. I don't know that the option is needed, though.

> > Whether this is cleaner from an implementation perspective I think is
> > questionable, particularly because the restrictions (must have same
> > context as caller) will be confusing. This is especially with MLS.
> > Additionally, how are we going to then handle cases where the contexts
> > don't match (for example, running install in a different context to
> > limit what contexts it can set)?
> 
> Can't we use runcon to work around that limitation?
> 
>   runcon -Z ... fscon -t httpd_sys_content_t touch foo.html
> 

Well, maybe, but that is not exactly user friendly.

> > More importantly to me, though, is that this mechanism will be much
> > harder to find for users and will break several years of documented
> > behavior. I think that the explicit options are the correct model from a
> > user perspective.
> 
> I wouldn't expect anything in FCx or RHEL to change overnight.
> The usual routine is to let the option in question continue to work
> for some time, but with an added diagnostic saying that it is slated
> to be removed, and suggesting the new/preferred approach.  Then, only
> a couple of years later, would it actually be removed.
> 

My point is less about backwards compatibility and more about usability.
A separate utility is much more difficult to find and harder for the
user to understand (for example, they would likely never find it looking
in the man page for install).

Your runcon workaround above is a perfect example - that would be very
difficult to explain to most users without quickly diving into
implementation details that should not and probably do not care about.

Karl

--
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.

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

[Jim Meyering]

Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:
> On Mon, 2006-08-14 at 17:53 +0200, Jim Meyering wrote:
>> Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:
>> ...
>> >> > Acls are a discretionary mechanism and it is, therefore, appropriate for
>> >> > them to be applied by users after file creation.
>> >> >
>> >> > SELinux is fundamentally different as a mandatory mechanism and a core
>> >> > property is that objects should be labeled correctly at creation time.
>> >>
>> >> If using chcon is sometimes not an option for a user who must be able
>> >> to create files in a non-default context, then we have to choose between:
>> >>
>> >>   1) adding the --context=CTX (-Z) option to many of the programs
>> >>       that create a named output file.
>> >>
>> >>   2) providing a tool to change the fscreate context for an exec'd program
>> >>
>> >> The latter seems much cleaner.
>> >> Is there any hope on that front?
>> >> The problem is that if I add an options upstream, it's
>> >> a big deal/hassle to remove it later, if a more appropriate
>> >> mechanism becomes available.  As long as there's a hint
>> >> of hope for a cleaner approach, I'm extremely reluctant
>> >> to impose on the coreutils something that looks like a kludge.
>>
>> Hi Karl,
>>
>> > So your thinking is that the user would have to run a tool - e.g.:
>> >
>> > fscon -t httpd_sys_content_t touch foo.html
>>
>> Exactly.
>> Your example brings up the question of whether touch needs -Z CTX.
>> The user-specified context would be relevant only when creating a file,
>> not when merely updating atime or mtime, and hence, it'd be used only
>> when creating an _empty_ file.  Can you think of a context in which the
>> context of a regular, zero-length file actually matters?  I couldn't.
>> I.e., there's no risk of a race: if the context matters, applying it
>> via chcon as a separate step, after invoking touch would be safe.
>> Maybe that's why touch (on an SELinux system) doesn't already have
>> this option.
>>
>
> Again, you are assuming that relabeling is always possible. It is
> possible for the policy to severely limit or completely prohibit
> relabeling. I don't know that the option is needed, though.

No.  I'm simply assuming that anyone who needs to create a file
with a non-default context will be working in an environment that
permits relabeling.  I've tried to make the point that it's not
feasible to change every named-file-writing program to accept a new
SELinux-context-specifying argument.  Sure, people can modify the most
commonly used ones, but I think they shouldn't have to.  Remember that
this is Unix, with it's pipes and the one-task-one-tool philosophy.

>> > Whether this is cleaner from an implementation perspective I think is
>> > questionable, particularly because the restrictions (must have same
>> > context as caller) will be confusing. This is especially with MLS.
>> > Additionally, how are we going to then handle cases where the contexts
>> > don't match (for example, running install in a different context to
>> > limit what contexts it can set)?
>>
>> Can't we use runcon to work around that limitation?
>>
>>   runcon -Z ... fscon -t httpd_sys_content_t touch foo.html
>>
>
> Well, maybe, but that is not exactly user friendly.

User friendly is nice, but there's a tension between keeping code
maintainable (e.g., small or even minimal) and providing features.
That's one of the reasons it's so hard to justify adding a new option
to ls :-)  When supporting a new "feature" requires adding an option to
nearly every program that writes a file, then isn't it time to look for
a less invasive approach?

>> > More importantly to me, though, is that this mechanism will be much
>> > harder to find for users and will break several years of documented
>> > behavior. I think that the explicit options are the correct model from a
>> > user perspective.
>>
>> I wouldn't expect anything in FCx or RHEL to change overnight.
>> The usual routine is to let the option in question continue to work
>> for some time, but with an added diagnostic saying that it is slated
>> to be removed, and suggesting the new/preferred approach.  Then, only
>> a couple of years later, would it actually be removed.
>>
>
> My point is less about backwards compatibility and more about usability.

We all know that security and usability are often (always?) at odds.
When you add software complexity into the mix, most agree that keeping
code/interfaces as simple as possible is one of the keys to keeping
is robust.  If the code to set the default fscreate context is in one
place (the hypothetical fscon program), then it's far easier to audit
and maintain than if the code is smeared across the tens or hundreds of
programs that accept a -Z CTX option.

> A separate utility is much more difficult to find and harder for the
> user to understand (for example, they would likely never find it looking
> in the man page for install).

If my hopes pan out, RHEL's install -Z option won't go away any time
soon, and there would be a long transition period, with diagnostics
to help affected users learn the new way.  Besides, won't most of
the affected users be ones who actually read (or know how to read)
documentation?  With a little luck, by the time install's -Z option goes
away, there would be plenty of documentation explaining how things work.

> Your runcon workaround above is a perfect example - that would be very
> difficult to explain to most users without quickly diving into
> implementation details that should not and probably do not care about.

I agree that it's not a trivial way to use programs, but isn't the
scenario that'd require such usage a little bit off the beaten track?
If it were something that Joe user would have to run before clicking on
the icon to start OpenOffice, then I'd agree completely.  Even if it
were something that an average command-line-savvy user would have to
do... maybe.  But that seems more like something a package maintainer
would do.  Or more likely, an SELinux guru would do it, in order to
help the package maintainer get his job done safely.  Then, if it needs
to be done for too many packages, it'd be documented -- then package
maintainers would learn.

But of course, my whole scenario depends on SELinux
making it possible to write a program like fscon.

--
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.

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

[Jim Meyering]

Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Mon, 2006-08-14 at 19:18 +0200, Jim Meyering wrote:
>> I agree that it's not a trivial way to use programs, but isn't the
>> scenario that'd require such usage a little bit off the beaten track?
>
> I'm not sure that this is a valid assumption.  It might be educational
> (or perhaps not) to take your proposal to fedora-selinux-list, and seek
> feedback there, as I think they have a much larger subscriber base and

As you've probably noticed, I posted to the lists, as you suggested:
  https://www.redhat.com/archives/fedora-list/2006-August/msg02264.html (long)

I suppose it's still early, but so far, all I have is positive feedback:

  http://lists.gnu.org/archive/html/bug-coreutils/2006-08/msg00147.html

Support (and even rebuttal) welcomed.
Even silence is ok, as long as it implies consent :)

> have people who are more representative of ordinary users.  Or even
> fedora-list itself, as plenty of people are using Fedora w/SELinux
> without even subscribing to any of the SELinux-specific lists.
>
>> But of course, my whole scenario depends on SELinux
>> making it possible to write a program like fscon.
>
> I'm not convinced that even if SELinux supported such a program that it
> should replace the -Z options in coreutils.  I'd see that more as a way
> of applying SELinux to the much larger set of utils, particularly third
> party ones, that are truly not feasible for us to patch.

FYI, I learned of another tool, like the proposed fscon, that performs a
kernel state change just before exec'ing some other program: setarch(8):

  $ man setarch
  SETARCH(8)                 Linux Programmer's Manual                SETARCH(8)

  NAME
         setarch - change reported architecture in new program environment
         and set personality flags

  SYNOPSIS
         setarch <arch> [options] [program [arguments]]

         arch [options] [program [arguments]]

  DESCRIPTION
         setarch This utility currently only affects the output  of  uname
         -m.  For  example, on an AMD64 system, running 'setarch i386 pro-
         gram' will cause 'program' to see i686 (or other  relevant  arch)
         instead  of x86_64 as machine type. It also allows to set various
         personality options.
  ...

--
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.

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

[Christopher J. PeBenito]

On Mon, 2006-08-21 at 17:58 +0200, Jim Meyering wrote:
> Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Mon, 2006-08-14 at 19:18 +0200, Jim Meyering wrote:
> >> I agree that it's not a trivial way to use programs, but isn't the
> >> scenario that'd require such usage a little bit off the beaten track?
> >
> > I'm not sure that this is a valid assumption.  It might be educational
> > (or perhaps not) to take your proposal to fedora-selinux-list, and seek
> > feedback there, as I think they have a much larger subscriber base and
> 
> As you've probably noticed, I posted to the lists, as you suggested:
>   https://www.redhat.com/archives/fedora-list/2006-August/msg02264.html (long)
> 
> I suppose it's still early, but so far, all I have is positive feedback:
> 
>   http://lists.gnu.org/archive/html/bug-coreutils/2006-08/msg00147.html
> 
> Support (and even rebuttal) welcomed.
> Even silence is ok, as long as it implies consent :)

It has mentioned before but I think it needs to be said again.  Since
SELinux support is being merged upstream, it should be treated like a
first class citizen.  Many of the tools have the -m options, and the
mode is to Linux DAC as the context is to SELinux; therefore, the -Z
options should be kept.  Any coreutils program that has a -m option
should likely have a -Z option.

Fscon has security implications.  For example, if the program fscon
exec's transitions to a different domain, either it would have to be
disallowed across a transition, or we would have to add a permission to
allow it to work across transitions.  If a misbehaving program doesn't
clear its fscreate, then all its child programs will be broken by trying
to create programs in the wrong context, which would be common for the
non-transitioning exec() case.

Fscon doesn't work for any program that isn't simple like coreutils
programs.  For example, it does not work for any program that creates
multiple files in different locations, because using fscon assumes that
they should all be the same context, when they likely shouldn't.

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


--
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.

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

[Jim Meyering]

"Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
...
> It has mentioned before but I think it needs to be said again.  Since
> SELinux support is being merged upstream, it should be treated like a
> first class citizen.  Many of the tools have the -m options, and the
> mode is to Linux DAC as the context is to SELinux; therefore, the -Z
> options should be kept.

IMHO, that doesn't follow, IF there is a better way, like via fscon.

[ Your use of "kept" is a little ambiguous.  Just to be clear,
  I suspect the -Z CTX options of mkdir, install, mkfifo, mknod will be
  "kept" in FC and Red Hat products for some time to come.  This is about
  whether they should propagate to upstream coreutils.  ]

> Any coreutils program that has a -m option
> should likely have a -Z option.

Alternatively, there should be a tool by which to make each of those
coreutils programs produce the same net effect.

> Fscon has security implications.  For example, if the program fscon
> exec's transitions to a different domain, either it would have to be
> disallowed across a transition, or we would have to add a permission to

I understood that making fscon disallow a transition would be fine.
Any cross-transition use could be achieved via runcon.

> allow it to work across transitions.  If a misbehaving program doesn't
> clear its fscreate, then all its child programs will be broken by trying
> to create programs in the wrong context, which would be common for the
> non-transitioning exec() case.
>
> Fscon doesn't work for any program that isn't simple like coreutils
> programs.

But there are many others that *would* benefit.

> For example, it does not work for any program that creates
> multiple files in different locations, because using fscon assumes that
> they should all be the same context, when they likely shouldn't.

And no one would even try to use fscon with such programs.  Besides, to
work properly, wouldn't such a program have to set the fscreate context
of each different output file explicitly?  In that case, the default
set by fscon would have no effect.

--
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.

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

[Joshua Brindle]

Jim Meyering wrote:
> "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
<snip>
>> Fscon has security implications.  For example, if the program fscon
>> exec's transitions to a different domain, either it would have to be
>> disallowed across a transition, or we would have to add a permission to
> 
> I understood that making fscon disallow a transition would be fine.
> Any cross-transition use could be achieved via runcon.
> 
>> allow it to work across transitions.  If a misbehaving program doesn't
>> clear its fscreate, then all its child programs will be broken by trying
>> to create programs in the wrong context, which would be common for the
>> non-transitioning exec() case.
>>
>> Fscon doesn't work for any program that isn't simple like coreutils
>> programs.
> 
> But there are many others that *would* benefit.
> 

You didn't respond to this and its probably the most important point. 
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.

--
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.

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

[Jim Meyering]

Joshua Brindle <jbrindle@tresys.com> wrote:
> Jim Meyering wrote:
>> "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
> <snip>
>>> Fscon has security implications.  For example, if the program fscon
>>> exec's transitions to a different domain, either it would have to be
>>> disallowed across a transition, or we would have to add a permission to
>> I understood that making fscon disallow a transition would be fine.
>> Any cross-transition use could be achieved via runcon.
>>
>>> allow it to work across transitions.  If a misbehaving program doesn't
>>> clear its fscreate, then all its child programs will be broken by trying
>>> to create programs in the wrong context, which would be common for the
>>> non-transitioning exec() case.
>>>
>>> Fscon doesn't work for any program that isn't simple like coreutils
>>> programs.
>> But there are many others that *would* benefit.
>
> You didn't respond to this and its probably the most important point.

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"?

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.

  [ I wrote the following a week or so ago: ]
  I see that setexeccon sets the context to be used for next execve call.
  And then there's setfscreatecon.  I want something similar that sets
  the fscreate context for the next execve call.  Does such a function exist?
  Is there some other way to do what I want?

It sounds like you're expecting the exec'd process to inherit
unconditionally the fscreate context that the calling process had
when it called execve.  Of course, that behavior would throw everyone
for a loop.  The former would be a lot less disruptive, and
Stephen Smalley said providing it might be feasible.

> 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.

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.

--
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.

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

[Joshua Brindle]

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.

> 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.

>   [ I wrote the following a week or so ago: ]
>   I see that setexeccon sets the context to be used for next execve call.
>   And then there's setfscreatecon.  I want something similar that sets
>   the fscreate context for the next execve call.  Does such a function exist?
>   Is there some other way to do what I want?
> 
> It sounds like you're expecting the exec'd process to inherit
> unconditionally the fscreate context that the calling process had
> when it called execve.  Of course, that behavior would throw everyone
> for a loop.  The former would be a lot less disruptive, and
> Stephen Smalley said providing it might be feasible.
> 

fine, retracted.

> > 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.

> 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. 

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.


--
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.

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

[Jim Meyering]

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.

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

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 3230 bytes --]

On Tue, 2006-08-22 at 19:16 +0200, Jim Meyering wrote:

> >> 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.

 I think their argument is, that atm. you have:

        setexeccon
        [...stuff which isn't exec...]
        exec <-- affects this.
        
        setfscreatecon
        [...stuff which isn't open(O_CREAT)...]
        open(O_CREAT) <-- affects this.
        
...and you want:

        setfspostexeccon
        [...stuff which isn't exec...]
        exec
        [...stuff which isn't open(O_CREAT)...]
        open(O_CREAT) <-- affects this.


> It's more of the one task, one tool Unix approach to problem solving.

 Personally I don't believe this has been the case for decades, but
anyway...

> Another program that works this way: setarch.

 It doesn't work that way, setarch calls the personality() syscall. This
is basically a global variable inside the kernel. For instance:

% cat ~/personality.c
#include <sys/personality.h>

int main(void)
{
        personality(-1);
        return 0;
}
% gcc -Wall -W -o ~/personality ~/personality.c
% strace -e trace=personality setarch i386 ~/personality
personality(PER_LINUX32)                = 0
personality(0xffffffff /* PER_??? */)   = 8
Process 9009 detached
% strace -e trace=personality setarch i386 sh -c ~/personality
personality(PER_LINUX32)                = 0
personality(0xffffffff /* PER_??? */)   = 8
Process 9013 detached

> 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.
[...]
> The patch program (which I also mentioned) is a better example.

 As someone else said, I think people want -Z (and/or matchpathcon) on
commands that have -m and preservation on commands that have
owner/mode/etc. preservation. Patch doesn't do either of those.
 mknod/mkfifo/mkdir do have -m, so it seems natural to have -Z (and
setting umask before could have worked, but having -m options was deemed
to be better).

 You would never want -Z in tar to do what you said, AFAICS.

-- 
James Antill - <james.antill@redhat.com>
setsockopt(fd, IPPROTO_TCP, TCP_CONGESTION, ...);
setsockopt(fd, IPPROTO_TCP, TCP_DEFER_ACCEPT, ...);
setsockopt(fd, SOL_SOCKET,  SO_ATTACH_FILTER, ...);


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jim Meyering]

[strange.  I sent this message a week ago, but it returned to me today with
 "unknown mail transport error" for each recipient.  No wonder I received no
 reply.  I'll watch the list and my queue more carefully, now. ]

James Antill <james.antill@redhat.com> wrote:
> On Tue, 2006-08-22 at 19:16 +0200, Jim Meyering wrote:
...
>> 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.
>
>  I think their argument is, that atm. you have:
>
>         setexeccon
>         [...stuff which isn't exec...]
>         exec <-- affects this.
>
>         setfscreatecon
>         [...stuff which isn't open(O_CREAT)...]
>         open(O_CREAT) <-- affects this.
>
> ...and you want:
>
>         setfspostexeccon
>         [...stuff which isn't exec...]
>         exec
>         [...stuff which isn't open(O_CREAT)...]
>         open(O_CREAT) <-- affects this.

Hi James,

That's a good description.  And I like the new function name.
As you know, functions other than file-creating-open are affected, too:
mkfifo, mknod, symlink, creat.  And it's not quite like setexeccon, where
at most one execve call is affected.
Also, any use of setfscreatecon-with-non-NULL-arg in the exec'd process
would cancel the effect of a parent's setfspostexeccon.  I think an initial
setfscreatecon(NULL) in the exec'd process would be a no-op.
So here's what I want:

        setfspostexeccon
        [...stuff which isn't exec...]
        exec
        [...operations that don't create files
            and that don't call setfscreatecon...]
        open(O_CREAT), or mkfifo, etc. <-- affects this.
        [...still no setfscreatecon...]
        symlink, or mknod, etc.        <-- and this.

How is this an argument against making fscon possible?

>> It's more of the one task, one tool Unix approach to problem solving.
>
>  Personally I don't believe this has been the case for decades, but
> anyway...
>
>> Another program that works this way: setarch.
>
>  It doesn't work that way, setarch calls the personality() syscall. This
> is basically a global variable inside the kernel. For instance:
...

Thanks for explaining.
I didn't do enough homework there.  Shouldn't have taken the bait :)

Sounds like sour grapes, but are implementation details really relevant?
Or maybe the argument is that it is not possible (or reasonable)
to implement fscon?

Regardless of how it's implemented, I think it is clear that a program
like fscon would make it possible for more tools to work more easily
with SELinux.

As upstream maintainer, I can't provide a "-Z CTX"-like option for SELinux,
and then say "No" to proposals to add ones for other MAC-based system.
Eventually we'd have an unmaintainable mess, with per-scheme code for
option handling, portability infrastructure, and actual implementation
(however simple) being duplicated in at least these four coreutils
programs.  And that's not counting the eventual code that might have
to detect and diagnose when people try to mix and match options for
incompatible schemes.

Sure, I'm looking ahead a little (would AppArmor be a contender?
I don't know), but that's part of the "upstream" job.

Remember, if there is agreement that providing SELinux infrastructure
to implement a program like fscon is not feasible, then we're done.
But I heard exactly the opposite conclusion already.

>> 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.
> [...]
>> The patch program (which I also mentioned) is a better example.
>
>  As someone else said, I think people want -Z (and/or matchpathcon) on
> commands that have -m and preservation on commands that have
> owner/mode/etc. preservation. Patch doesn't do either of those.

On the contrary, patch does preserve permissions.  It tries to apply
the permissions (st_mode) of the input file to the output file:

    $ echo a > 1; touch 2 3; diff 2 1 | strace -e chmod patch 3 -
    patching file 3
    chmod("3", 0100644)                     = 0
    Process 25711 detached

But that's just a detail.  *preserving* attributes like owner/mode/etc.
is no reason to use fscon or to add a "-Z CTX" option.  So now, I think
that patch does *not* need such an option.  I must have put patch and
tar on my list of potentially affected programs before we came to the
conclusion that merely preserving permissions (as done by mv and cp)
does not justify adding a "-Z CTX" option.

>  mknod/mkfifo/mkdir do have -m, so it seems natural to have -Z (and
> setting umask before could have worked, but having -m options was deemed
> to be better).

Note that tar does have a --mode option.  From --help:

      --mode=CHANGES         force (symbolic) mode CHANGES for added files

but it merely changes what's recorded in the archive, and it doesn't set
the default used at extract-time.  So although it might be justified to
add a new option to permit specifying an ACL, XATTR, or an SELinux security
context in the same way, it's not relevant to the fscon discussion.


If there's serious disagreement, to the point that fscon is never
implementable, then I'll consider keeping the relatively small "-Z CTX"
diffs separate.  I could even maintain patches, much the way that is done
with rsync development.  If it turns out everyone who uses the upstream
coreutils also applies a certain patch, eventually I might have no choice
but to accept it.

--
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.

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

[Joshua Brindle]

On Wed, 2006-08-23 at 12:43 +0200, Jim Meyering wrote:
<snip>
> Hi James,
> 
> That's a good description.  And I like the new function name.
> As you know, functions other than file-creating-open are affected, too:
> mkfifo, mknod, symlink, creat.  And it's not quite like setexeccon, where
> at most one execve call is affected.
> Also, any use of setfscreatecon-with-non-NULL-arg in the exec'd process
> would cancel the effect of a parent's setfspostexeccon.  I think an initial
> setfscreatecon(NULL) in the exec'd process would be a no-op.
> So here's what I want:
> 
>         setfspostexeccon
>         [...stuff which isn't exec...]
>         exec
>         [...operations that don't create files
>             and that don't call setfscreatecon...]
>         open(O_CREAT), or mkfifo, etc. <-- affects this.
>         [...still no setfscreatecon...]
>         symlink, or mknod, etc.        <-- and this.
> 
> How is this an argument against making fscon possible?
> 

Its a very broken design, we want to taint the new process as little as
possible and this is a big nasty piece of environment you want to place
solidly in the upcoming process, further you are saying you want to make
it more difficult for the child to ignore it?!

Consider what would happen if you were able to set the mode for files
opened by the next process, something like:

setmostexecmode(S_IROTH | S_IWOTH)
exec(/usr/bin/passwd)
and the resulting shadow is readable and writable by everyone?

Granted this particular piece of environment would have to be removed
with ATSECURE which means domain transitions could also eliminate it but
with the targeted policy I don't think we want unconfined_t using this
which means fscon would be unusable anyway. Also, the command line
syntax is all but intuitive, even for seasoned UNIX people who are
probably much more familiar with using command line arguments,
especially when you need to domain transition manually *and* set the
file context this way, noone will ever do it. 

> >> It's more of the one task, one tool Unix approach to problem solving.
> >
> >  Personally I don't believe this has been the case for decades, but
> > anyway...
> >
> >> Another program that works this way: setarch.
> >
> >  It doesn't work that way, setarch calls the personality() syscall. This
> > is basically a global variable inside the kernel. For instance:
> ...
> 
> Thanks for explaining.
> I didn't do enough homework there.  Shouldn't have taken the bait :)
> 
> Sounds like sour grapes, but are implementation details really relevant?
> Or maybe the argument is that it is not possible (or reasonable)
> to implement fscon?
> 

its possible, I think it is a very terrible idea though.

> Regardless of how it's implemented, I think it is clear that a program
> like fscon would make it possible for more tools to work more easily
> with SELinux.
> 
> As upstream maintainer, I can't provide a "-Z CTX"-like option for SELinux,
> and then say "No" to proposals to add ones for other MAC-based system.

you can if those others aren't in the mainline kernel.

> Eventually we'd have an unmaintainable mess, with per-scheme code for
> option handling, portability infrastructure, and actual implementation
> (however simple) being duplicated in at least these four coreutils
> programs.  And that's not counting the eventual code that might have
> to detect and diagnose when people try to mix and match options for
> incompatible schemes.
> 
> Sure, I'm looking ahead a little (would AppArmor be a contender?
> I don't know), but that's part of the "upstream" job.
> 

apparmor doesn't label files, they use paths, no it is not a contender.

> Remember, if there is agreement that providing SELinux infrastructure
> to implement a program like fscon is not feasible, then we're done.
> But I heard exactly the opposite conclusion already.
<snip>
> 
> If there's serious disagreement, to the point that fscon is never
> implementable, then I'll consider keeping the relatively small "-Z CTX"
> diffs separate.  I could even maintain patches, much the way that is done
> with rsync development.  If it turns out everyone who uses the upstream
> coreutils also applies a certain patch, eventually I might have no choice
> but to accept it.

Personally I don't think any distro will ever use fscon, at least
Gentoo, possibly Red Hat and Debian will continue to maintain patches to
keep the -Z behavior and this whole discussion was a waste of time. 

And I still disagree with your notion that its ok to silently ignore the
user input if they invoke fscon with a context and the next process
overwrites it. The next process should always have precedence but
silently dropping user input with no explanation of why what they are
trying is not succeeding is very bad user interface design.


--
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.

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

[Stephen Smalley]

On Mon, 2006-08-28 at 08:23 -0400, Joshua Brindle wrote:
> On Wed, 2006-08-23 at 12:43 +0200, Jim Meyering wrote:
> <snip>
> > Hi James,
> > 
> > That's a good description.  And I like the new function name.
> > As you know, functions other than file-creating-open are affected, too:
> > mkfifo, mknod, symlink, creat.  And it's not quite like setexeccon, where
> > at most one execve call is affected.
> > Also, any use of setfscreatecon-with-non-NULL-arg in the exec'd process
> > would cancel the effect of a parent's setfspostexeccon.  I think an initial
> > setfscreatecon(NULL) in the exec'd process would be a no-op.
> > So here's what I want:
> > 
> >         setfspostexeccon
> >         [...stuff which isn't exec...]
> >         exec
> >         [...operations that don't create files
> >             and that don't call setfscreatecon...]
> >         open(O_CREAT), or mkfifo, etc. <-- affects this.
> >         [...still no setfscreatecon...]
> >         symlink, or mknod, etc.        <-- and this.
> > 
> > How is this an argument against making fscon possible?
> > 
> 
> Its a very broken design, we want to taint the new process as little as
> possible and this is a big nasty piece of environment you want to place
> solidly in the upcoming process, further you are saying you want to make
> it more difficult for the child to ignore it?!

The last part is definitely problematic, I agree.  The first part would
be addressed by resetting the attribute upon a context-changing exec
either unconditionally in all cases or based on some new permission
check modeled after noatsecure, rlimitinh, and siginh for other kinds of
state inheritance across a context change.  

> Consider what would happen if you were able to set the mode for files
> opened by the next process, something like:
> 
> setmostexecmode(S_IROTH | S_IWOTH)
> exec(/usr/bin/passwd)
> and the resulting shadow is readable and writable by everyone?
> 
> Granted this particular piece of environment would have to be removed
> with ATSECURE

More like rlimitinh/siginh, since the kernel can directly handle both
the checking and sanitization of this piece of state, unlike the
environment purging by glibc (where the kernel just provides the
decision via AT_SECURE).  

>  which means domain transitions could also eliminate it but
> with the targeted policy I don't think we want unconfined_t using this
> which means fscon would be unusable anyway.

I was following you up to this point, but don't follow this statement.
Why can't unconfined_t use fscon? 

>  Also, the command line
> syntax is all but intuitive, even for seasoned UNIX people who are
> probably much more familiar with using command line arguments,
> especially when you need to domain transition manually *and* set the
> file context this way, noone will ever do it.

The runcon piece of this puzzle is actually a bit more of a problem,
because of entrypoint controls.  You can't just say:
	runcon <context> fscon -t type <program> <args>
because program is the authorized entrypoint for <context>, not fscon.
fscon would have to become a shared entrypoint for all such contexts,
and that would be a bad thing.

-- 
Stephen Smalley
National Security Agency


--
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.

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

[Stephen Smalley]

On Mon, 2006-08-28 at 16:24 -0400, Stephen Smalley wrote:
> On Mon, 2006-08-28 at 08:23 -0400, Joshua Brindle wrote:
> > On Wed, 2006-08-23 at 12:43 +0200, Jim Meyering wrote:
> > <snip>
> > > Hi James,
> > > 
> > > That's a good description.  And I like the new function name.
> > > As you know, functions other than file-creating-open are affected, too:
> > > mkfifo, mknod, symlink, creat.  And it's not quite like setexeccon, where
> > > at most one execve call is affected.
> > > Also, any use of setfscreatecon-with-non-NULL-arg in the exec'd process
> > > would cancel the effect of a parent's setfspostexeccon.  I think an initial
> > > setfscreatecon(NULL) in the exec'd process would be a no-op.
> > > So here's what I want:
> > > 
> > >         setfspostexeccon
> > >         [...stuff which isn't exec...]
> > >         exec
> > >         [...operations that don't create files
> > >             and that don't call setfscreatecon...]
> > >         open(O_CREAT), or mkfifo, etc. <-- affects this.
> > >         [...still no setfscreatecon...]
> > >         symlink, or mknod, etc.        <-- and this.
> > > 
> > > How is this an argument against making fscon possible?
> > > 
> > 
> > Its a very broken design, we want to taint the new process as little as
> > possible and this is a big nasty piece of environment you want to place
> > solidly in the upcoming process, further you are saying you want to make
> > it more difficult for the child to ignore it?!
> 
> The last part is definitely problematic, I agree.  The first part would
> be addressed by resetting the attribute upon a context-changing exec
> either unconditionally in all cases or based on some new permission
> check modeled after noatsecure, rlimitinh, and siginh for other kinds of
> state inheritance across a context change.  
> 
> > Consider what would happen if you were able to set the mode for files
> > opened by the next process, something like:
> > 
> > setmostexecmode(S_IROTH | S_IWOTH)
> > exec(/usr/bin/passwd)
> > and the resulting shadow is readable and writable by everyone?
> > 
> > Granted this particular piece of environment would have to be removed
> > with ATSECURE
> 
> More like rlimitinh/siginh, since the kernel can directly handle both
> the checking and sanitization of this piece of state, unlike the
> environment purging by glibc (where the kernel just provides the
> decision via AT_SECURE).  
> 
> >  which means domain transitions could also eliminate it but
> > with the targeted policy I don't think we want unconfined_t using this
> > which means fscon would be unusable anyway.
> 
> I was following you up to this point, but don't follow this statement.
> Why can't unconfined_t use fscon? 
> 
> >  Also, the command line
> > syntax is all but intuitive, even for seasoned UNIX people who are
> > probably much more familiar with using command line arguments,
> > especially when you need to domain transition manually *and* set the
> > file context this way, noone will ever do it.
> 
> The runcon piece of this puzzle is actually a bit more of a problem,
> because of entrypoint controls.  You can't just say:
> 	runcon <context> fscon -t type <program> <args>
> because program is the authorized entrypoint for <context>, not fscon.
> fscon would have to become a shared entrypoint for all such contexts,
> and that would be a bad thing.

Actually, I'm not sure that we would need to combine runcon with fscon
in this manner, given the intended usage.  Previously we were executing
<program> -Z <fscontext> <args>, optionally with a runcon prefix to
force it into a specified process context.  The caller was supplying the
fscontext to the program, with no kernel mediation of the fscontext at
all relative to the caller (since arguments aren't interpreted by the
kernel), just when the program itself passes it to setfscreatecon().
Under the proposed approach, we would be executing fscon <fscontext>
<program> <args> or optionally fscon <fscontext> runcon <proccontext> --
<program> <args>.  The caller is still providing the context, but now
there is a kernel mediation of the context relative to the caller when
it performs setfscreatecon(), and there can be mediation of the
inheritance across a context-changing exec based on some new permission
check.  In this case, since we were fine with the caller providing the
context in the first place, we could just allow the inheritance in the
policy, and we don't need the runcon to precede the fscon.  It is only
if we hardcode a behavior of resetting the fscreate attribute on all
context changes that we have to use runcon first, but that behavior
doesn't match the trust model that is already present in the use of the
-Z options.

Now, all of this assumes that the program in question would apply that
-Z context to all files it creates; otherwise, these are not equivalent.
That is likely true of coreutils.  For programs that create a primary
output file but also generate ancillary files for e.g. audit,
bookkeeping, statistics, etc, use of fscon may not be sufficient, but
then neither would a single -Z option.

-- 
Stephen Smalley
National Security Agency


--
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.

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

[Stephen Smalley]

On Wed, 2006-08-23 at 12:43 +0200, Jim Meyering wrote:
> James Antill <james.antill@redhat.com> wrote:
> > On Tue, 2006-08-22 at 19:16 +0200, Jim Meyering wrote:
> ...
> >> 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.
> >
> >  I think their argument is, that atm. you have:
> >
> >         setexeccon
> >         [...stuff which isn't exec...]
> >         exec <-- affects this.
> >
> >         setfscreatecon
> >         [...stuff which isn't open(O_CREAT)...]
> >         open(O_CREAT) <-- affects this.
> >
> > ...and you want:
> >
> >         setfspostexeccon
> >         [...stuff which isn't exec...]
> >         exec
> >         [...stuff which isn't open(O_CREAT)...]
> >         open(O_CREAT) <-- affects this.
> 
> Hi James,
> 
> That's a good description.  And I like the new function name.
> As you know, functions other than file-creating-open are affected, too:
> mkfifo, mknod, symlink, creat.  And it's not quite like setexeccon, where
> at most one execve call is affected.

In both cases (setfscreatecon and setexeccon), the call affects the
labeling behavior of subsequent calls by the program until either a) the
program makes another set* call or b) a new program starts execution.
They are consistent in that respect.

> Also, any use of setfscreatecon-with-non-NULL-arg in the exec'd process
> would cancel the effect of a parent's setfspostexeccon.  I think an initial
> setfscreatecon(NULL) in the exec'd process would be a no-op.

I don't see why that would be desirable.  setfscreatecon(NULL) is an
explicit request by the program to reset its labeling behavior to the
policy defaults, and should always be honored.  In practice, I wouldn't
expect many programs to do that anyway, but if they do it, they meant to
do it.   Code that wants to save, set, create, and restore the fscreate
context (like library functions) would typically do a
getfscreatecon(&orig);setfscreatecon(new);creat/mkdir/...();
setfscreatecon(orig) sequence, but in the hypothetical case where the
fscreate context was inherited from the caller, that orig context would
not be NULL.

> So here's what I want:
> 
>         setfspostexeccon
>         [...stuff which isn't exec...]
>         exec
>         [...operations that don't create files
>             and that don't call setfscreatecon...]
>         open(O_CREAT), or mkfifo, etc. <-- affects this.
>         [...still no setfscreatecon...]
>         symlink, or mknod, etc.        <-- and this.

I'd tend toward an orthogonal operation that affects inheritance of
context attributes rather than creating yet-another-fscreate-like
attribute, more along the lines of prctl(PR_SET_KEEPCAPS), ala:
	setfscreatecon(c);
	setkeepcon(TRUE);
	...
	exec that doesn't involve a context change (or that allows inheritance
of contexts across the context change via some new permission)
	[...anything other than setfscreatecon...]
	any file creation calls <-- affects this.

> How is this an argument against making fscon possible?

I don't think he was making that argument per se, just trying to
eliminate confusion with a picture.

> Regardless of how it's implemented, I think it is clear that a program
> like fscon would make it possible for more tools to work more easily
> with SELinux.

I can agree with that, particularly for third party tools and closed
source programs.  It doesn't necessarily follow that core utilities
provided by the distribution shouldn't include direct support for
SELinux.  I think that is the larger concern.  The context inheritance
issue is easily addressed by prohibiting it upon context changes or
controlling it via permission.

> As upstream maintainer, I can't provide a "-Z CTX"-like option for SELinux,
> and then say "No" to proposals to add ones for other MAC-based system.
> Eventually we'd have an unmaintainable mess, with per-scheme code for
> option handling, portability infrastructure, and actual implementation
> (however simple) being duplicated in at least these four coreutils
> programs.  And that's not counting the eventual code that might have
> to detect and diagnose when people try to mix and match options for
> incompatible schemes.

coreutils doesn't need to care which security module is being used, as
long as it handles the contexts as just strings.  

> On the contrary, patch does preserve permissions.  It tries to apply
> the permissions (st_mode) of the input file to the output file:
> 
>     $ echo a > 1; touch 2 3; diff 2 1 | strace -e chmod patch 3 -
>     patching file 3
>     chmod("3", 0100644)                     = 0
>     Process 25711 detached

I think he meant that patch doesn't preserve security context.  Which is
a problem, but not related to this.

-- 
Stephen Smalley
National Security Agency


--
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.

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

[Joshua Brindle]

On Tue, 2006-08-22 at 20:27 -0400, James Antill wrote:
> On Tue, 2006-08-22 at 19:16 +0200, Jim Meyering wrote:
> 
> > >
> > > 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.
> 
>  I think their argument is, that atm. you have:
> 
>         setexeccon
>         [...stuff which isn't exec...]
>         exec <-- affects this.
>         
>         setfscreatecon
>         [...stuff which isn't open(O_CREAT)...]
>         open(O_CREAT) <-- affects this.
>         
> ...and you want:
> 
>         setfspostexeccon
>         [...stuff which isn't exec...]
>         exec
>         [...stuff which isn't open(O_CREAT)...]
>         open(O_CREAT) <-- affects this.
> 

Yes, thank you for drawing a picture :) this is absolutely right and I
think this strange way of changing the behavior of the upcoming app
_after_ the exec is a very bad idea.

> 
> > It's more of the one task, one tool Unix approach to problem solving.
> 
>  Personally I don't believe this has been the case for decades, but
> anyway...
> 
> > Another program that works this way: setarch.
> 
>  It doesn't work that way, setarch calls the personality() syscall. This
> is basically a global variable inside the kernel. For instance:
> 
> % cat ~/personality.c
> #include <sys/personality.h>
> 
> int main(void)
> {
>         personality(-1);
>         return 0;
> }
> % gcc -Wall -W -o ~/personality ~/personality.c
> % strace -e trace=personality setarch i386 ~/personality
> personality(PER_LINUX32)                = 0
> personality(0xffffffff /* PER_??? */)   = 8
> Process 9009 detached
> % strace -e trace=personality setarch i386 sh -c ~/personality
> personality(PER_LINUX32)                = 0
> personality(0xffffffff /* PER_??? */)   = 8
> Process 9013 detached
> 

Thanks for explaining this setarch, I wasn't quite sure what it was but
I had doubts that it was analogous to this fscon idea.

> > 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.
> [...]
> > The patch program (which I also mentioned) is a better example.
> 
>  As someone else said, I think people want -Z (and/or matchpathcon) on
> commands that have -m and preservation on commands that have
> owner/mode/etc. preservation. Patch doesn't do either of those.
>  mknod/mkfifo/mkdir do have -m, so it seems natural to have -Z (and
> setting umask before could have worked, but having -m options was deemed
> to be better).
> 
>  You would never want -Z in tar to do what you said, AFAICS.
> 

Correct and correct.


--
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.

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

[Karl MacMillan]

On Mon, 2006-08-21 at 17:58 +0200, Jim Meyering wrote:
> Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Mon, 2006-08-14 at 19:18 +0200, Jim Meyering wrote:
> >> I agree that it's not a trivial way to use programs, but isn't the
> >> scenario that'd require such usage a little bit off the beaten track?
> >
> > I'm not sure that this is a valid assumption.  It might be educational
> > (or perhaps not) to take your proposal to fedora-selinux-list, and seek
> > feedback there, as I think they have a much larger subscriber base and
> 
> As you've probably noticed, I posted to the lists, as you suggested:
>   https://www.redhat.com/archives/fedora-list/2006-August/msg02264.html (long)
> 
> I suppose it's still early, but so far, all I have is positive feedback:
> 
>   http://lists.gnu.org/archive/html/bug-coreutils/2006-08/msg00147.html
> 

Response so far has not exactly been overwhelming.

> Support (and even rebuttal) welcomed.
> Even silence is ok, as long as it implies consent :)
> 

I still think that the current flags are better. Here are some reasons
(I can come up with more if you like):

1) The proposed fscon only works in some circumstances. I think that
most users will have trouble knowing when they can just use fscon and
when they have to resort to runcon + fscon. You suggest that this is a
corner case only, but I am not convinced that it won't pop up in normal
usage.

2) Fscon is in my opinion much less friendly than the direct flags.
Using runcon + fscon is not just unfriendly it is downright user
hostile. Imaging using this if you have MCS/MLS involved.

I have taught probably hundreds of users how to use SELinux (both in
formal class settings and informally). I have seen many of these
students have trouble understanding the relationship between file
contexts and process contexts - introducing a dependency between the two
with runcon and fscon will just make things that much worse.

3) This will be kernel dependent, resulting in maintenance problems. Not
only that, this kernel change will miss many major distro releases
including RHEL 5 meaning that the problem will be around for a long
time.

4) The current flags have been around for several years and are
documented everywhere. Your argument that RHEL/Fedora will likely
preserve these for years doesn't help - the whole point of upstreaming
this is to get long-term, consistent usage across distros. Switching now
doesn't help it hurts that goal.

5) It is not clear that the change in kernel semantics is desirable.

6) It makes the handling of SELinux contexts divergent from handle ACLs,
standard unix permissions, and extended attributes. It is more natural,
in my opinion, to treat the SELinux permissions as peers of these
concepts. 

7) How will fscon interact with the proposed xattr flags? Won't
applications that handle xattrs have to have logic to ignore or set the
SELinux xattrs, destroying the stated advantage of removing this support
with fscon?

Karl


--
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.

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

[Jim Meyering]

Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:
> Response so far has not exactly been overwhelming.

I noticed :)
Thanks for taking the time to read and reply.

> I still think that the current flags are better. Here are some reasons
> (I can come up with more if you like):

Yes, please.

> 1) The proposed fscon only works in some circumstances. I think that

I think we agree.  Let me rephrase it:

  In some circumstances, fscon, by itself, is insufficient.
  In those cases, you'd have to use both runcon and fscon.
  This boils down to an argument involving perceived user convenience.

> most users will have trouble knowing when they can just use fscon and
> when they have to resort to runcon + fscon. You suggest that this is a
> corner case only, but I am not convinced that it won't pop up in normal
> usage.

Even if it does come up in normal usage, I don't see it as a big
enough hurdle to warrant adding the -Z option to mkdir, mknod, mkfifo,
and install.  (Remember, those are the only four tools in question
here.  The other -Z options, that don't take an argument, have
different semantics.)  Using a separate tool seems like the proper,
Unix, approach.  If results in some process being too complicated,
people can always add wrappers to encapsulate it.

> 2) Fscon is in my opinion much less friendly than the direct flags.
> Using runcon + fscon is not just unfriendly it is downright user
> hostile. Imaging using this if you have MCS/MLS involved.

Can you give an example or two showing how/why it would be so
problematic, e.g., how using mkdir -Z CTX ... would be so
much better than this:
  fscon FS_CTX mkdir ...
or this:
  runcon X_CTX fscon FS_CTX mkdir ...

> I have taught probably hundreds of users how to use SELinux (both in
> formal class settings and informally). I have seen many of these
> students have trouble understanding the relationship between file
> contexts and process contexts - introducing a dependency between the two
> with runcon and fscon will just make things that much worse.

Do we really want to limit the design of core O/S tools so as to keep
within the bounds of what the median student can understand?  Where would
Unix be today, if it adhered to such a philosophy?  Combining conceptually
simple tools is at the core of the Unix ethic.  Is SELinux so different
that we need to change now?

> 3) This will be kernel dependent, resulting in maintenance problems. Not
> only that, this kernel change will miss many major distro releases
> including RHEL 5 meaning that the problem will be around for a long
> time.

I don't expect any maintenance-related problems in the coreutils
per se.  I have a lot of experience working around just such system-
and kernel-specific differences.  coreutils' configure process tests
for many libc- and kernel-specific features and bugs.  There are even
a few run-time tests.

Since no one would be in a hurry to phase out the -Z CTX options,
I don't see why RHEL 5 would be relevant.

> 4) The current flags have been around for several years and are
> documented everywhere. Your argument that RHEL/Fedora will likely
> preserve these for years doesn't help - the whole point of upstreaming
> this is to get long-term, consistent usage across distros. Switching now
> doesn't help it hurts that goal.

I have one additional requirement: to "do the right thing" by coreutils.
>From my perspective as an SELinux newbie, that would seem to require
a tool like fscon.  Regarding history, I see it more like: if there's
a better way and we don't switch now, it won't ever happen.

> 5) It is not clear that the change in kernel semantics is desirable.

I agree, so far.  That's why I've been working to DTRT here.
I'm trying to convince you that it is desirable, or to get a clear
indication that it's not possible.  The latter hasn't happened,
so I remain optimistic.

> 6) It makes the handling of SELinux contexts divergent from handle ACLs,
> standard unix permissions, and extended attributes. It is more natural,
> in my opinion, to treat the SELinux permissions as peers of these
> concepts.

Currently, even with distro-specific patches, I know of no coreutils
tool or option by which to _set_ ACLs or XATTRs.  So in a sense, it's
the addition of the -Z CTX option that causes divergence.  If there
were already a "-Z CTX"-analog for ACLs or XATTRs, it'd be different.
The problem is that once we (upstream) open the door with an option for
setting SELinux context, we're in no position to argue against adding a
new option to set each of ACLs and XATTRs, and whatever other MAC-based
system people are using.  That is what I'm trying to avoid.

I have no problem *preserving* any and all attributes, and the upstream
mv, cp, and install will do that, before long.  It's only the *setting*
(via -Z CTX) that is problematic, because the semantics seem too basic
and easily factored out to require embedding in each of those programs --
and many others.

> 7) How will fscon interact with the proposed xattr flags? Won't
> applications that handle xattrs have to have logic to ignore or set the
> SELinux xattrs, destroying the stated advantage of removing this support
> with fscon?

If I understand the question, they're entirely independent, since the
only explicitly XATTR-related code is that which *preserves* XATTRs
in copy.c (used by mv, cp, install).  And the --preserve=xattr option
I suggested would apply only to cp.  Of those three, only install has
-Z CTX (since we've agreed that cp's -Z CTX option can be removed).
Let's say someone uses fscon to set cp's fscreate context anyhow, e.g.,

  fscon CTX cp --preserve=xattr SRC DEST

Then, I think the default fscreate context would be largely irrelevant,
since the request to preserve xattrs means to perform the copy, and to
make the XATTRs of DEST be identical (or as close as possible) to those
of SRC.  However, CTX would determine the SELinux context of DEST in the
window between when it's created and when its XATTRs are set, so this
could be viewed as a way of improving security by closing that window.

Jim

--
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.

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

[James Antill]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Fri, 2006-08-11 at 15:58 +0200, Jim Meyering wrote:
> For a little context on why, ...
> I'm also considering the xattr patch that's been floating around for
> years.  Currently it's part of SuSE's coreutils patch set.  It ensures
> that mv and cp -p preserve any (selected) XATTR attributes.

 Note that I did a patch, which is different from the SuSE patch ... it
doesn't include the regexp handling but mv does Do The Right
Thing(tm)[1]:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201088
http://people.redhat.com/jantill/patches/coreutils-5.97-xattrs.patch

 It also makes preservation of xattrs a hard error, unless it's because
of ENOTSUPP ... and there's no way to turn just preservation of xattrs
off (would you want this before accepting upstream)?


[1] If you "mv src x/dst" and x is a different fs, then you need to
remove all the xattrs from dst so you _only_ get the ones from src ...
which is what rename would do.

-- 
James Antill <jantill@redhat.com>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jim Meyering]

James Antill <jantill@redhat.com> wrote:
> On Fri, 2006-08-11 at 15:58 +0200, Jim Meyering wrote:
>> For a little context on why, ...
>> I'm also considering the xattr patch that's been floating around for
>> years.  Currently it's part of SuSE's coreutils patch set.  It ensures
>> that mv and cp -p preserve any (selected) XATTR attributes.
>
>  Note that I did a patch, which is different from the SuSE patch ... it
> doesn't include the regexp handling but mv does Do The Right
> Thing(tm)[1]:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201088
> http://people.redhat.com/jantill/patches/coreutils-5.97-xattrs.patch

Your patch looks good, but shouldn't it also preserve attributes
on directories and other non-regular files?

Since I rarely use ACLs, I'm not in a good position to gauge the
value of Andreas' cp option to select via regexp.

Also, in looking through your patch, I wondered if there is some scenario
where it'd be worthwhile to attempt to preserve xattrs even if fchmod
fails.  Or even to attempt to preserve xattrs *before* calling fchmod?

>  It also makes preservation of xattrs a hard error, unless it's because
> of ENOTSUPP ... and there's no way to turn just preservation of xattrs
> off (would you want this before accepting upstream)?

For upstream at least, the 5.9x branch is a bug-fix-only branch.
New features like xattr support will go on the trunk.

What do you think about adding a new cp option: --preserve=xattr ?
That would be in line with the --preserve=context option (added to cp)
that's part of the SELinux patch.
Which means it could be turned off via --no-preserve=xattr.

Currently, cp's --preserve option treats ACLs like mode bits.  I.e. both
cp -p and cp --preserve=mode copy ACLs.  mv preserves ACLs, too.
As mentioned before, failing to preserve an ACL has different consequences
in cp -p (warn and exit nonzero) and mv (warn, but exit successfully).

So should cp have a separate --preserve=acl option, too?

This brings up the question of whether cp's -p should also
imply --preserve=xattr.

> [1] If you "mv src x/dst" and x is a different fs, then you need to
> remove all the xattrs from dst so you _only_ get the ones from src ...
> which is what rename would do.

Good catch.
If you have a test script or two to exercise things like this,
they'd be welcome additions upstream.

--
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.

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

[Stephen Smalley]

On Wed, 2006-08-16 at 23:18 +0200, Jim Meyering wrote:
> James Antill <jantill@redhat.com> wrote:
> > On Fri, 2006-08-11 at 15:58 +0200, Jim Meyering wrote:
> >> For a little context on why, ...
> >> I'm also considering the xattr patch that's been floating around for
> >> years.  Currently it's part of SuSE's coreutils patch set.  It ensures
> >> that mv and cp -p preserve any (selected) XATTR attributes.
> >
> >  Note that I did a patch, which is different from the SuSE patch ... it
> > doesn't include the regexp handling but mv does Do The Right
> > Thing(tm)[1]:
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201088
> > http://people.redhat.com/jantill/patches/coreutils-5.97-xattrs.patch
> 
> Your patch looks good, but shouldn't it also preserve attributes
> on directories and other non-regular files?
> 
> Since I rarely use ACLs, I'm not in a good position to gauge the
> value of Andreas' cp option to select via regexp.
> 
> Also, in looking through your patch, I wondered if there is some scenario
> where it'd be worthwhile to attempt to preserve xattrs even if fchmod
> fails.  Or even to attempt to preserve xattrs *before* calling fchmod?
> 
> >  It also makes preservation of xattrs a hard error, unless it's because
> > of ENOTSUPP ... and there's no way to turn just preservation of xattrs
> > off (would you want this before accepting upstream)?
> 
> For upstream at least, the 5.9x branch is a bug-fix-only branch.
> New features like xattr support will go on the trunk.
> 
> What do you think about adding a new cp option: --preserve=xattr ?
> That would be in line with the --preserve=context option (added to cp)
> that's part of the SELinux patch.
> Which means it could be turned off via --no-preserve=xattr.
> 
> Currently, cp's --preserve option treats ACLs like mode bits.  I.e. both
> cp -p and cp --preserve=mode copy ACLs.  mv preserves ACLs, too.
> As mentioned before, failing to preserve an ACL has different consequences
> in cp -p (warn and exit nonzero) and mv (warn, but exit successfully).
> 
> So should cp have a separate --preserve=acl option, too?
> 
> This brings up the question of whether cp's -p should also
> imply --preserve=xattr.

Caveat:  A process may be able to copy a file and preserve its
discretionary attributes, but not its MAC/SELinux attribute.  That
shouldn't be fatal to the copy itself.

-- 
Stephen Smalley
National Security Agency


--
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.

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

[Stephen Smalley]

On Mon, 2006-08-28 at 16:00 -0400, Stephen Smalley wrote:
> On Wed, 2006-08-16 at 23:18 +0200, Jim Meyering wrote:
> > James Antill <jantill@redhat.com> wrote:
> > > On Fri, 2006-08-11 at 15:58 +0200, Jim Meyering wrote:
> > >> For a little context on why, ...
> > >> I'm also considering the xattr patch that's been floating around for
> > >> years.  Currently it's part of SuSE's coreutils patch set.  It ensures
> > >> that mv and cp -p preserve any (selected) XATTR attributes.
> > >
> > >  Note that I did a patch, which is different from the SuSE patch ... it
> > > doesn't include the regexp handling but mv does Do The Right
> > > Thing(tm)[1]:
> > >
> > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201088
> > > http://people.redhat.com/jantill/patches/coreutils-5.97-xattrs.patch
> > 
> > Your patch looks good, but shouldn't it also preserve attributes
> > on directories and other non-regular files?
> > 
> > Since I rarely use ACLs, I'm not in a good position to gauge the
> > value of Andreas' cp option to select via regexp.
> > 
> > Also, in looking through your patch, I wondered if there is some scenario
> > where it'd be worthwhile to attempt to preserve xattrs even if fchmod
> > fails.  Or even to attempt to preserve xattrs *before* calling fchmod?
> > 
> > >  It also makes preservation of xattrs a hard error, unless it's because
> > > of ENOTSUPP ... and there's no way to turn just preservation of xattrs
> > > off (would you want this before accepting upstream)?
> > 
> > For upstream at least, the 5.9x branch is a bug-fix-only branch.
> > New features like xattr support will go on the trunk.
> > 
> > What do you think about adding a new cp option: --preserve=xattr ?
> > That would be in line with the --preserve=context option (added to cp)
> > that's part of the SELinux patch.
> > Which means it could be turned off via --no-preserve=xattr.
> > 
> > Currently, cp's --preserve option treats ACLs like mode bits.  I.e. both
> > cp -p and cp --preserve=mode copy ACLs.  mv preserves ACLs, too.
> > As mentioned before, failing to preserve an ACL has different consequences
> > in cp -p (warn and exit nonzero) and mv (warn, but exit successfully).
> > 
> > So should cp have a separate --preserve=acl option, too?
> > 
> > This brings up the question of whether cp's -p should also
> > imply --preserve=xattr.
> 
> Caveat:  A process may be able to copy a file and preserve its
> discretionary attributes, but not its MAC/SELinux attribute.  That
> shouldn't be fatal to the copy itself.

Sorry..."unless the caller explicitly requested copying of the
MAC/SELinux attribute or all attributes".  Which isn't the case for just
cp -p and others that imply -p, like -a.  Otherwise, you'll encounter
breakage in existing usage.

-- 
Stephen Smalley
National Security Agency


--
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.