setexeccon vs. setfscreatecon

setexeccon vs. setfscreatecon

[Jim Meyering]

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?

In case you're wondering, here's my motivation: I'm merging some
coreutils selinux changes into upstream and noticed that they would break
thread-safety in coreutils' copying engine, src/copy.c -- because they
introduce calls to setfscreatecon.  From reading the man page for that
function, I gather that the fscreate-context is a per-process attribute.
As such (like umask and cwd), changing it affects all threads, and its
use should be avoided in library-esque code.

What I would like to do is merge the context-printing and
context-preserving parts of that patch, but not the context-setting
parts (--context=CTX in cp, mkdir, mkfifo, mknod, install).  Instead,
I'm trying to add an option to runcon that would let me also set the
fscreate context for the process it runs.  Then, all of the individual
context-setting options would be unnecessary.

Does this sound reasonable?  Feasible?

Thanks,

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: setexeccon vs. setfscreatecon

[Stephen Smalley]

On Tue, 2006-08-08 at 15:16 +0200, Jim Meyering wrote:
> 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?
> 
> In case you're wondering, here's my motivation: I'm merging some
> coreutils selinux changes into upstream and noticed that they would break
> thread-safety in coreutils' copying engine, src/copy.c -- because they
> introduce calls to setfscreatecon.  From reading the man page for that
> function, I gather that the fscreate-context is a per-process attribute.
> As such (like umask and cwd), changing it affects all threads, and its
> use should be avoided in library-esque code.
> 
> What I would like to do is merge the context-printing and
> context-preserving parts of that patch, but not the context-setting
> parts (--context=CTX in cp, mkdir, mkfifo, mknod, install).  Instead,
> I'm trying to add an option to runcon that would let me also set the
> fscreate context for the process it runs.  Then, all of the individual
> context-setting options would be unnecessary.
> 
> Does this sound reasonable?  Feasible?

At present, the kernel resets the process attributes (exec, fscreate,
and more recent additions like keycreate and sockcreate) upon each
execve so that each program starts life with the default policy
behaviors for its execve and file creation calls, and follows that
behavior unless the program itself explicitly sets the attributes.

With regard to the thread issue, the kernel actually supports per-thread
attributes (per-Linux task), but libselinux doesn't presently access it
in a manner that allows you to leverage it (via /proc/self rather
than /proc/self/task/<tid>).  At present, any child thread will just
fail upon the libselinux calls since it will be viewed by the kernel as
attempting to change the attribute of the thread group leader from a
different thread, and we only allow a thread to change its own
attributes.  libselinux could be changed to use /proc/self/task/<tid>,
at which point the kernel would do the right thing, I think.

-- 
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: setexeccon vs. setfscreatecon

[Jim Meyering]

Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Tue, 2006-08-08 at 15:16 +0200, Jim Meyering wrote:
>> 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?
>>
>> In case you're wondering, here's my motivation: I'm merging some
>> coreutils selinux changes into upstream and noticed that they would break
>> thread-safety in coreutils' copying engine, src/copy.c -- because they
>> introduce calls to setfscreatecon.  From reading the man page for that
>> function, I gather that the fscreate-context is a per-process attribute.
>> As such (like umask and cwd), changing it affects all threads, and its
>> use should be avoided in library-esque code.
>>
>> What I would like to do is merge the context-printing and
>> context-preserving parts of that patch, but not the context-setting
>> parts (--context=CTX in cp, mkdir, mkfifo, mknod, install).  Instead,
>> I'm trying to add an option to runcon that would let me also set the
>> fscreate context for the process it runs.  Then, all of the individual
>> context-setting options would be unnecessary.
>>
>> Does this sound reasonable?  Feasible?
>
> At present, the kernel resets the process attributes (exec, fscreate,
> and more recent additions like keycreate and sockcreate) upon each execve

Thanks for the quick reply!

What you're saying seems to be at odds with setexeccon.1
as well as with this demonstration (using 2.6.17-1.2462.fc6):

    $ id -Z
    user_u:system_r:unconfined_t
    $ runcon -r object_r -- ./id -Z
    user_u:object_r:unconfined_t

since runcon's call to setexeccon does what the man page says it does
(set exec context for subsequent execve call) and changes the role from
system_r to object_r.  Does that mean this behavior is Red Hat/Fedora-
specific?

Is there any hope that I could get an interface to allow something
similar with respect to the fscreate context?
With such a function, it would be trivial to set the context of
files created by an arbitrary program: simply run it via e.g.,

  runcon --fs-create-context=FS_CREATE_CONTEXT -- EXEC_CONTEXT PROGRAM ARG...

Without it, most file-creating programs will have to be modified
(manually and tediously) to accept a new option allowing the user to
select an fs-create context.

> so that each program starts life with the default policy
> behaviors for its execve and file creation calls, and follows that
> behavior unless the program itself explicitly sets the attributes.
>
> With regard to the thread issue, the kernel actually supports per-thread
> attributes (per-Linux task), but libselinux doesn't presently access it

I've heard of the Linux option to convert normally-per-process attributes
into per-task ones.  However that seems like an overly large stick to
shake at this problem.  Isn't it onerous, and even dangerous, for a
library to require that a multi-threaded application flip that switch
in Linux?  Some other library used by the application could assume
certain attributes are per-process.

> in a manner that allows you to leverage it (via /proc/self rather
> than /proc/self/task/<tid>).  At present, any child thread will just
> fail upon the libselinux calls since it will be viewed by the kernel as
> attempting to change the attribute of the thread group leader from a
> different thread, and we only allow a thread to change its own
> attributes.  libselinux could be changed to use /proc/self/task/<tid>,
> at which point the kernel would do the right thing, I think.

--
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: setexeccon vs. setfscreatecon

[James Antill]

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

On Tue, 2006-08-08 at 17:57 +0200, Jim Meyering wrote:

> What you're saying seems to be at odds with setexeccon.1
> as well as with this demonstration (using 2.6.17-1.2462.fc6):
> 
>     $ id -Z
>     user_u:system_r:unconfined_t
>     $ runcon -r object_r -- ./id -Z
>     user_u:object_r:unconfined_t
> 
> since runcon's call to setexeccon does what the man page says it does
> (set exec context for subsequent execve call) and changes the role from
> system_r to object_r.  Does that mean this behavior is Red Hat/Fedora-
> specific?

 No, what Steven was saying is that the label for execcon will be reset
on exec (after doing it's thing). To see this visually use "secon
--self-exec" instead of id.

% secon
user: user_u
role: system_r
type: unconfined_t
sensitivity:
clearance:
mls-range:
% secon --self-exec
user:
role:
type:
sensitivity:
clearance:
mls-range:
% runcon -r system_r secon
user: user_u
role: system_r
type: unconfined_t
sensitivity:
clearance:
mls-range:
% runcon -r system_r -- secon --self-exec
user:
role:
type:
sensitivity:
clearance:
mls-range:


-- 
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: setexeccon vs. setfscreatecon

[Stephen Smalley]

On Tue, 2006-08-08 at 17:57 +0200, Jim Meyering wrote:
> Thanks for the quick reply!
> 
> What you're saying seems to be at odds with setexeccon.1
> as well as with this demonstration (using 2.6.17-1.2462.fc6):
> 
>     $ id -Z
>     user_u:system_r:unconfined_t
>     $ runcon -r object_r -- ./id -Z
>     user_u:object_r:unconfined_t
> 
> since runcon's call to setexeccon does what the man page says it does
> (set exec context for subsequent execve call) and changes the role from
> system_r to object_r.  Does that mean this behavior is Red Hat/Fedora-
> specific?

No, it just means I didn't explain adequately ;)

When a task sets its exec context to a particular value, then that
context is applied to the transformed task as its current context upon
its next execve call rather than using the default policy-defined
transition (assuming that the caller is permitted by policy to
transition to the new context and the new context is permitted by policy
to use the new program as its entrypoint).  But the exec context itself
is reset by that execve, and is not applied to any execve calls made by
the new program / transformed task.  Those execve calls will then follow
the default behavior, which will either be to perform a policy-defined
transition or remain in the same context if no transition is defined.
So it might even look like the exec context is being propagated just due
to the latter inheritance of current context in the absence of a
transition, but it isn't.  Really.  Honest ;)

> Is there any hope that I could get an interface to allow something
> similar with respect to the fscreate context?
> With such a function, it would be trivial to set the context of
> files created by an arbitrary program: simply run it via e.g.,
> 
>   runcon --fs-create-context=FS_CREATE_CONTEXT -- EXEC_CONTEXT PROGRAM ARG...
> 
> Without it, most file-creating programs will have to be modified
> (manually and tediously) to accept a new option allowing the user to
> select an fs-create context.

In the case where the new program is running in a different context than
the caller, we definitely want to reset the attributes to prevent the
program from being maliciously influenced by the caller.  Otherwise, the
caller could try to trick the new program into creating files in a
context of its choosing rather than the policy defaults in order to gain
unauthorized access to the data.  In the case where the new program is
running in the same context as the caller, the issue is less clear, but
it seemed simpler for programs to always know that they start life
operating with the policy-defined behavior and that their initial
attribute state is always cleared and only they can set it.  I'd be
uneasy about breaking that assumption now.

> > With regard to the thread issue, the kernel actually supports per-thread
> > attributes (per-Linux task), but libselinux doesn't presently access it
> 
> I've heard of the Linux option to convert normally-per-process attributes
> into per-task ones.  However that seems like an overly large stick to
> shake at this problem.  Isn't it onerous, and even dangerous, for a
> library to require that a multi-threaded application flip that switch
> in Linux?  Some other library used by the application could assume
> certain attributes are per-process.

There is no switch for credentials; uids/gids and security contexts are
all per-task in Linux and not shareable even via clone.  There have been
various patches bandied about on linux-kernel over the years to permit
sharing, but nothing has been adopted.  The kernel keyring support might
actually be a step in that direction.

I think that changing libselinux to
read/write /proc/self/task/<tid>/attr/xxx would be fairly
straightforward, and the existing kernel would just work (i.e let you
set and get the per-thread state that already exists).  When we
originally wrote the libselinux functions, /proc/self/task didn't exist
and /proc/self was a reference to the per-thread state, but they
switched that on us early in 2.6, and we never had a real requirement to
motivate changing the libselinux functions.

-- 
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: setexeccon vs. setfscreatecon

[Jim Meyering]

Stephen Smalley <sds@tycho.nsa.gov> wrote:
...
> No, it just means I didn't explain adequately ;)
>
> When a task sets its exec context to a particular value, then that
...

Ahh... I see, now.
Thanks for taking the time.

--
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: id -Z subsumed by secon?

[James Antill]

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

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

> By the way, doesn't secon make id's -Z option unnecessary?

 Well id -a is useful as a single line of all the current permissions,
IMO. It's also a lot easier to find id -Z and runcon or secon, IMO.

-- 
James Antill <jantill@redhat.com>

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