re: id -Z subsumed by secon?

re: id -Z subsumed by secon?

[Daniel J Walsh]

>
>
> James Antill <james.antill@redhat.com> wrote:
>   
>> >  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
>>     
> ...
>
> Thanks for the example.
>
> By the way, doesn't secon make id's -Z option unnecessary?
> I'm planning not to include the 'id -Z' patches upstream,
> Instead, runcon (with neither CONTEXT nor COMMAND) will
> print the current security context -- to be analogous to how nice(1)
> works if you don't give it a command.
>
> Any objection?
>
>
>   
Yes I would like to maintain the idea of "-Z" being the way to view 
contexts.  This makes it easy for
a user to figure out how to see what context is being used.  ls -Z, ps 
-Z, netstat -Z ...


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

[Janak Desai]

On Tue, 2006-08-08 at 14:58 -0400, Daniel J Walsh wrote:
> >
> >
> > James Antill <james.antill@redhat.com> wrote:
> >   
> >> >  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
> >>     
> > ...
> >
> > Thanks for the example.
> >
> > By the way, doesn't secon make id's -Z option unnecessary?
> > I'm planning not to include the 'id -Z' patches upstream,
> > Instead, runcon (with neither CONTEXT nor COMMAND) will
> > print the current security context -- to be analogous to how nice(1)
> > works if you don't give it a command.
> >
> > Any objection?
> >
> >
> >   
> Yes I would like to maintain the idea of "-Z" being the way to view 
> contexts.  This makes it easy for
> a user to figure out how to see what context is being used.  ls -Z, ps 
> -Z, netstat -Z ...
> 
> 

We are also using "id -Z" in our evaluation tests and would like to
keep the option.

-Janak

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

stat's -Z/--context option is gone [Re: id -Z subsumed by secon?

[Jim Meyering]

Janak Desai <janak@us.ibm.com> wrote:
> On Tue, 2006-08-08 at 14:58 -0400, Daniel J Walsh wrote:
>> > James Antill <james.antill@redhat.com> wrote:
...
>> > By the way, doesn't secon make id's -Z option unnecessary?
>> > I'm planning not to include the 'id -Z' patches upstream,
>> > Instead, runcon (with neither CONTEXT nor COMMAND) will
>> > print the current security context -- to be analogous to how nice(1)
>> > works if you don't give it a command.
>> >
>> > Any objection?
>> >
>> Yes I would like to maintain the idea of "-Z" being the way to view
>> contexts.  This makes it easy for
>> a user to figure out how to see what context is being used.  ls -Z, ps
>> -Z, netstat -Z ...
>
> We are also using "id -Z" in our evaluation tests and would like to
> keep the option.

Thanks for the feedback.
With all of those arguments, I don't have much of a choice, now do I? :)

Another FYI, stat's selinux-specific --context (-Z) will not
be included upstream.
It isn't really needed, after all.  Support for --context and -Z
will probably remain in Red Hat's version, as a warned-about no-op for a while.
Instead, there is just one long format string and one short.
Each will include the selinux security context, if available.
And the new %C 'just works' -- at least on a system with selinux.

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

[Karl MacMillan]

On Tue, 2006-08-08 at 14:58 -0400, Daniel J Walsh wrote:

> >
> > Thanks for the example.
> >
> > By the way, doesn't secon make id's -Z option unnecessary?
> > I'm planning not to include the 'id -Z' patches upstream,
> > Instead, runcon (with neither CONTEXT nor COMMAND) will
> > print the current security context -- to be analogous to how nice(1)
> > works if you don't give it a command.
> >
> > Any objection?
> >
> >
> >   
> Yes I would like to maintain the idea of "-Z" being the way to view 
> contexts.  This makes it easy for
> a user to figure out how to see what context is being used.  ls -Z, ps 
> -Z, netstat -Z ...
> 
> 

Jim - I didn't see a response on this so I thought I would go ahead and
agree with Dan here. All of the "-Z" options have been documented for
_years_ - removing them now would be a real hardship on users.

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

[Jim Meyering]

Karl MacMillan <kmacmillan@mentalrootkit.com> wrote:
> Jim - I didn't see a response on this so I thought I would go ahead and
> agree with Dan here. All of the "-Z" options have been documented for
> _years_ - removing them now would be a real hardship on users.

No need to worry :)
After the first reply I was convinced.

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

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: 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 --]