provoking fsetfilecon failure in a test case

provoking fsetfilecon failure in a test case

[Jim Meyering]

I'm adding a test case for the 'cp -a' failure reported here:

  http://bugzilla.redhat.com/219900

In my comment there, I asked this:

  I'd like to add a test script to exercise this fix, but depending on
  the existence of a writable, NFS-mounted partition is not a recipe for
  good coverage. Can anyone suggest an easier way to provoke fsetfilecon
  failure on a file we've just opened (but not created -- it already
  existed) for writing?

Any ideas?

--
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: provoking fsetfilecon failure in a test case

[Stephen Smalley]

On Tue, 2007-01-30 at 20:33 +0100, Jim Meyering wrote:
> I'm adding a test case for the 'cp -a' failure reported here:
> 
>   http://bugzilla.redhat.com/219900
> 
> In my comment there, I asked this:
> 
>   I'd like to add a test script to exercise this fix, but depending on
>   the existence of a writable, NFS-mounted partition is not a recipe for
>   good coverage. Can anyone suggest an easier way to provoke fsetfilecon
>   failure on a file we've just opened (but not created -- it already
>   existed) for writing?
> 
> Any ideas?

fsetfilecon will fail if any of the following apply:
- the filesystem was mounted with a context= option or the filesystem
doesn't support setxattr for the security namespace (EOPNOTSUPP),
- the process fsuid doesn't match the file's uid and the process lacks
CAP_FOWNER (EPERM),
- the process lacks relabelfrom permission to the old file context,
- the new context isn't valid (EINVAL),
- the process lacks relabelto permission to the new file context,
- the relationship between the old and new file contexts violates a
validatetrans constraint,
- the new file context is not allowed to be associated with the
filesystem context.

-- 
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: provoking fsetfilecon failure in a test case

[Jim Meyering]

Stephen Smalley <sds@tycho.nsa.gov> wrote:

> On Tue, 2007-01-30 at 20:33 +0100, Jim Meyering wrote:
>> I'm adding a test case for the 'cp -a' failure reported here:
>>
>>   http://bugzilla.redhat.com/219900
>>
>> In my comment there, I asked this:
>>
>>   I'd like to add a test script to exercise this fix, but depending on
>>   the existence of a writable, NFS-mounted partition is not a recipe for
>>   good coverage. Can anyone suggest an easier way to provoke fsetfilecon
>>   failure on a file we've just opened (but not created -- it already
>>   existed) for writing?
>>
>> Any ideas?
>
> fsetfilecon will fail if any of the following apply:
> - the filesystem was mounted with a context= option or the filesystem
> doesn't support setxattr for the security namespace (EOPNOTSUPP),
> - the process fsuid doesn't match the file's uid and the process lacks
> CAP_FOWNER (EPERM),
> - the process lacks relabelfrom permission to the old file context,
> - the new context isn't valid (EINVAL),
> - the process lacks relabelto permission to the new file context,
> - the relationship between the old and new file contexts violates a
> validatetrans constraint,
> - the new file context is not allowed to be associated with the
> filesystem context.

Thank you for the reply.
In the interest of reproducing the conditions of the "cp -a" failure
for my test script, I'd prefer to run as non-root: far fewer users run
coreutils' root-requiring tests.  But so far, even with your list above,
unless the test can find a writable NFS partition, it looks like having
a non-root test is not feasible.  Can you see a way?

However, I've just confirmed that I can reproduce the conditions
(as root, of course) by creating a temporary partition mounted via
"mount -oloop,context=system_u:object_r:removable_t".  So at least
a root-only test won't also require NFS.

Interestingly, when trying to copy one file from that
partition to another location on the same partition, fsetxattr
failed to set the context of the destination file, even though
the desired context is the default one (specified by context=... above).
Would it make sense to allow fsetxattr to succeed in that special case?
Probably not, just as it's probably not right for cp to detect
the condition and skip the fsetxattr call.

    $ echo foo > f; cp f ff; /bin/cp -a f ff; ls -ng f ff
    -rw-r--r-- 1 4 Jan 31 18:03 f
    -rw-r--r-- 1 0 Jan 31 18:03 ff
    $ echo foo > f; cp f ff; $cp --preserve=context f ff; ls -l f ff
    /t/coreutils-6.7-dirty/src/cp: failed to set the security context of `ff' \
        to `user_u:object_r:removable_t': Operation not supported
    -rw-r--r-- 1 4 Jan 31 18:08 f
    -rw-r--r-- 1 0 Jan 31 18:08 ff
    $ echo foo > f; cp f ff; $cp -a f ff; ls -ng f ff
    -rw-r--r-- 1 4 Jan 31 18:08 f
    -rw-r--r-- 1 4 Jan 31 18:08 ff
    $ /t/coreutils-6.7-dirty/src/ls -1Z f ff
    user_u:object_r:removable_t f
    user_u:object_r:removable_t ff

--
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: provoking fsetfilecon failure in a test case

[Stephen Smalley]

On Wed, 2007-01-31 at 18:26 +0100, Jim Meyering wrote:
> Stephen Smalley <sds@tycho.nsa.gov> wrote:
> 
> > On Tue, 2007-01-30 at 20:33 +0100, Jim Meyering wrote:
> >> I'm adding a test case for the 'cp -a' failure reported here:
> >>
> >>   http://bugzilla.redhat.com/219900
> >>
> >> In my comment there, I asked this:
> >>
> >>   I'd like to add a test script to exercise this fix, but depending on
> >>   the existence of a writable, NFS-mounted partition is not a recipe for
> >>   good coverage. Can anyone suggest an easier way to provoke fsetfilecon
> >>   failure on a file we've just opened (but not created -- it already
> >>   existed) for writing?
> >>
> >> Any ideas?
> >
> > fsetfilecon will fail if any of the following apply:
> > - the filesystem was mounted with a context= option or the filesystem
> > doesn't support setxattr for the security namespace (EOPNOTSUPP),
> > - the process fsuid doesn't match the file's uid and the process lacks
> > CAP_FOWNER (EPERM),
> > - the process lacks relabelfrom permission to the old file context,
> > - the new context isn't valid (EINVAL),
> > - the process lacks relabelto permission to the new file context,
> > - the relationship between the old and new file contexts violates a
> > validatetrans constraint,
> > - the new file context is not allowed to be associated with the
> > filesystem context.
> 
> Thank you for the reply.
> In the interest of reproducing the conditions of the "cp -a" failure
> for my test script, I'd prefer to run as non-root: far fewer users run
> coreutils' root-requiring tests.  But so far, even with your list above,
> unless the test can find a writable NFS partition, it looks like having
> a non-root test is not feasible.  Can you see a way?

Only by running the test in a confined domain that lacks the necessary
permissions to the file type.  Which would either require finding a
suitable domain to which you can transition in the existing policy or
creating a small test policy module (which would have to be preloaded by
a root process, of course).

> However, I've just confirmed that I can reproduce the conditions
> (as root, of course) by creating a temporary partition mounted via
> "mount -oloop,context=system_u:object_r:removable_t".  So at least
> a root-only test won't also require NFS.
> 
> Interestingly, when trying to copy one file from that
> partition to another location on the same partition, fsetxattr
> failed to set the context of the destination file, even though
> the desired context is the default one (specified by context=... above).
> Would it make sense to allow fsetxattr to succeed in that special case?
> Probably not, just as it's probably not right for cp to detect
> the condition and skip the fsetxattr call.

I would tend to say no, as the attribute hasn't been set in any
persistent sense and if the filesystem were later mounted with a
different context=, it wouldn't be preserved.

>     $ echo foo > f; cp f ff; /bin/cp -a f ff; ls -ng f ff
>     -rw-r--r-- 1 4 Jan 31 18:03 f
>     -rw-r--r-- 1 0 Jan 31 18:03 ff
>     $ echo foo > f; cp f ff; $cp --preserve=context f ff; ls -l f ff
>     /t/coreutils-6.7-dirty/src/cp: failed to set the security context of `ff' \
>         to `user_u:object_r:removable_t': Operation not supported
>     -rw-r--r-- 1 4 Jan 31 18:08 f
>     -rw-r--r-- 1 0 Jan 31 18:08 ff
>     $ echo foo > f; cp f ff; $cp -a f ff; ls -ng f ff
>     -rw-r--r-- 1 4 Jan 31 18:08 f
>     -rw-r--r-- 1 4 Jan 31 18:08 ff
>     $ /t/coreutils-6.7-dirty/src/ls -1Z f ff
>     user_u:object_r:removable_t f
>     user_u:object_r:removable_t ff


-- 
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: provoking fsetfilecon failure in a test case

[Jim Meyering]

Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Wed, 2007-01-31 at 18:26 +0100, Jim Meyering wrote:
...
>> In the interest of reproducing the conditions of the "cp -a" failure
>> for my test script, I'd prefer to run as non-root: far fewer users run
>> coreutils' root-requiring tests.  But so far, even with your list above,
>> unless the test can find a writable NFS partition, it looks like having
>> a non-root test is not feasible.  Can you see a way?
>
> Only by running the test in a confined domain that lacks the necessary
> permissions to the file type.  Which would either require finding a
> suitable domain to which you can transition in the existing policy or
> creating a small test policy module (which would have to be preloaded by
> a root process, of course).

Thanks for the continued (quick!) feedback.

This sounds like it could be less invasive than mounting a temporary
file system.  Especially if I can find an existing confined domain
that works.  What do you think?  If you're running coreutils'
"make check-root" rule, which would you prefer it to use:
  - a temporary loopback file system, or
  - create/load a test policy module, assuming I can unload it,
      leaving no trace, when done, or
  - (maybe best?) use some commonly-available confined domain
    that's suitable.  Then I don't have to worry about
    creating/loading one.

If the test-policy route sounds better, can you give a small demo?
Like how to find a suitable confined domain and, if needed,
how to create and preload a small test policy.

--
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: provoking fsetfilecon failure in a test case

[Stephen Smalley]

On Wed, 2007-01-31 at 22:32 +0100, Jim Meyering wrote:
> Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Wed, 2007-01-31 at 18:26 +0100, Jim Meyering wrote:
> ...
> >> In the interest of reproducing the conditions of the "cp -a" failure
> >> for my test script, I'd prefer to run as non-root: far fewer users run
> >> coreutils' root-requiring tests.  But so far, even with your list above,
> >> unless the test can find a writable NFS partition, it looks like having
> >> a non-root test is not feasible.  Can you see a way?
> >
> > Only by running the test in a confined domain that lacks the necessary
> > permissions to the file type.  Which would either require finding a
> > suitable domain to which you can transition in the existing policy or
> > creating a small test policy module (which would have to be preloaded by
> > a root process, of course).
> 
> Thanks for the continued (quick!) feedback.
> 
> This sounds like it could be less invasive than mounting a temporary
> file system.  Especially if I can find an existing confined domain
> that works.  What do you think?  If you're running coreutils'
> "make check-root" rule, which would you prefer it to use:
>   - a temporary loopback file system, or
>   - create/load a test policy module, assuming I can unload it,
>       leaving no trace, when done, or
>   - (maybe best?) use some commonly-available confined domain
>     that's suitable.  Then I don't have to worry about
>     creating/loading one.
> 
> If the test-policy route sounds better, can you give a small demo?
> Like how to find a suitable confined domain and, if needed,
> how to create and preload a small test policy.

Sorry for not responding sooner.  Offhand, I don't see a good
domain/type pair to re-use from current policy, and rolling your own
test policy is no easier than the temporary loopback filesystem (and
both require privilege to load/mount), so I'd stay with the loopback
filesystem approach at least for now.

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