su and context

su and context

[Ted X Toth]

Why doesn't my context change when I 'su' to a different user?

--
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: su and context

[Michael C Thompson]

Ted X Toth wrote:
> Why doesn't my context change when I 'su' to a different user?

I'm pretty sure su isn't SELinux aware like newrole is -- not 
investigated the source enough to save 100%, but pretty sure.

Is there a reason why you would want it to affect your context?

DAC and MAC are not intended to be related I thought.

Mike


--
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: su and context

[Stephen Smalley]

On Mon, 2007-02-12 at 10:39 -0600, Michael C Thompson wrote:
> Ted X Toth wrote:
> > Why doesn't my context change when I 'su' to a different user?
> 
> I'm pretty sure su isn't SELinux aware like newrole is -- not 
> investigated the source enough to save 100%, but pretty sure.
> 
> Is there a reason why you would want it to affect your context?
> 
> DAC and MAC are not intended to be related I thought.

The behavior has actually changed over time; you'll find discussions
about it in the mailing list archives.  The original SELinux kept su
separate from security context changes.  Earlier versions of Fedora (and
RHEL 4) integrated them (via pam_selinux) in an effort to provide
greater transparency, but this caused its own set of problems (e.g. use
of su from init scripts, losing continuity of context across su when you
want it for roles and levels).  More recent versions of Fedora (and RHEL
5) split them back out again.  One might add an option to su to support
simultaneous newrole, but you don't want it by default.

-- 
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: su and context

[Michael C Thompson]

Stephen Smalley wrote:
> The behavior has actually changed over time; you'll find discussions
> about it in the mailing list archives.  The original SELinux kept su
> separate from security context changes.  Earlier versions of Fedora (and
> RHEL 4) integrated them (via pam_selinux) in an effort to provide
> greater transparency, but this caused its own set of problems (e.g. use
> of su from init scripts, losing continuity of context across su when you
> want it for roles and levels).  More recent versions of Fedora (and RHEL
> 5) split them back out again.  One might add an option to su to support
> simultaneous newrole, but you don't want it by default.

I can see having both the functionality of su and newrole in one tool 
being a nice short-cut, but then you really still need the distinctive 
functionality to be supported, the is: changing DAC and changing MAC.

You will need to be able to specify which admin role you wish to 
transition to, much in the same way you can specify the UID/uname to 
change to. However, it would not be possible to specify a default role 
to transition to (without a config file) since SELinux has no 
pre-defined admin role (like root).

I'd just leave them separate.

Mike


--
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: su and context

[Ronan Waide]

On Mon, 2007-02-12 at 16:53, Stephen Smalley wrote:
> The behavior has actually changed over time; you'll find discussions
> about it in the mailing list archives.  The original SELinux kept su
> separate from security context changes.  Earlier versions of Fedora (and
> RHEL 4) integrated them (via pam_selinux) in an effort to provide
> greater transparency, but this caused its own set of problems (e.g. use
> of su from init scripts, losing continuity of context across su when you
> want it for roles and levels).  More recent versions of Fedora (and RHEL
> 5) split them back out again.  One might add an option to su to support
> simultaneous newrole, but you don't want it by default.

On the subject of interaction between "old" and "new" security, I was
briefly stumped in my quest to create a bind role account by the fact
that the rndc binary (on FC6) is not actually executable by anyone other
than root, so granting rndc_exec_t doesn't help unless you also change
the binary's permissions. Is this intentional? I had hoped that SELinux
rather than the filesystem would be taken as authoritative on who gets
access, but I can see reasons why this maybe shouldn't be the case, and
perhaps the 'bug' is with the installed permissions?

Cheers,
Waider.
-- 
Ronan Waide / TechOps EU Systems Engineer / waider@amazon.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: su and context

[Stephen Smalley]

On Mon, 2007-02-12 at 17:38 +0000, Ronan Waide wrote:
> On Mon, 2007-02-12 at 16:53, Stephen Smalley wrote:
> > The behavior has actually changed over time; you'll find discussions
> > about it in the mailing list archives.  The original SELinux kept su
> > separate from security context changes.  Earlier versions of Fedora (and
> > RHEL 4) integrated them (via pam_selinux) in an effort to provide
> > greater transparency, but this caused its own set of problems (e.g. use
> > of su from init scripts, losing continuity of context across su when you
> > want it for roles and levels).  More recent versions of Fedora (and RHEL
> > 5) split them back out again.  One might add an option to su to support
> > simultaneous newrole, but you don't want it by default.
> 
> On the subject of interaction between "old" and "new" security, I was
> briefly stumped in my quest to create a bind role account by the fact
> that the rndc binary (on FC6) is not actually executable by anyone other
> than root, so granting rndc_exec_t doesn't help unless you also change
> the binary's permissions. Is this intentional? I had hoped that SELinux
> rather than the filesystem would be taken as authoritative on who gets
> access, but I can see reasons why this maybe shouldn't be the case, and
> perhaps the 'bug' is with the installed permissions?

It is intentional; we didn't want SELinux to expose the system to
greater risk, so it only further restricts access (and that is
conventional for MAC).  Some people have experimented with modified
forms of SELinux where it is authoritative or selectively authoritative,
but you have to be careful there about your policy configuration and
userland assumptions.

-- 
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: su and context

[Russell Coker]

On Tuesday 13 February 2007 04:59, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On the subject of interaction between "old" and "new" security, I was
> > briefly stumped in my quest to create a bind role account by the fact
> > that the rndc binary (on FC6) is not actually executable by anyone other
> > than root, so granting rndc_exec_t doesn't help unless you also change
> > the binary's permissions. Is this intentional? I had hoped that SELinux
> > rather than the filesystem would be taken as authoritative on who gets
> > access, but I can see reasons why this maybe shouldn't be the case, and
> > perhaps the 'bug' is with the installed permissions?
>
> It is intentional; we didn't want SELinux to expose the system to
> greater risk, so it only further restricts access (and that is

As a tangent to this, you should be able to just use chown and chmod to make 
rndc usable by non-root.  rndc in recent versions of bind just seems to need 
to read the key file - which could be made readable by non-root.

Also with the strict policy you can have root as a non-privileged account 
(although this is not recommended in most situations).

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: su and context

[Ronan Waide]

On Thu, 2007-02-15 at 07:43, Russell Coker wrote:
> As a tangent to this, you should be able to just use chown and chmod to make 
> rndc usable by non-root.  rndc in recent versions of bind just seems to need 
> to read the key file - which could be made readable by non-root.

Oh yeah, that's what I've done - to the extent that I've an RPM trigger
that will fix the permissions on the file if I upgrade bind. The default
ISC installation doesn't lock the binary down in this way (and it makes
little sense; the binary's not setuid, and you could simply copy in a
binary from another machine if your target machine were in a non-selinux
environment) so I guess I should take it up with the Fedora packagers.
The key is actually in a different context, too, so you can block access
to it through SELinux.

Cheers,
Waider.
-- 
Ronan Waide / TechOps EU Systems Engineer / waider@amazon.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: su and context

[Ted X Toth]

Stephen Smalley wrote:
> On Mon, 2007-02-12 at 10:39 -0600, Michael C Thompson wrote:
>   
>> Ted X Toth wrote:
>>     
>>> Why doesn't my context change when I 'su' to a different user?
>>>       
>> I'm pretty sure su isn't SELinux aware like newrole is -- not 
>> investigated the source enough to save 100%, but pretty sure.
>>
>> Is there a reason why you would want it to affect your context?
>>
>> DAC and MAC are not intended to be related I thought.
>>     
>
> The behavior has actually changed over time; you'll find discussions
> about it in the mailing list archives.  The original SELinux kept su
> separate from security context changes.  Earlier versions of Fedora (and
> RHEL 4) integrated them (via pam_selinux) in an effort to provide
> greater transparency, but this caused its own set of problems (e.g. use
> of su from init scripts, losing continuity of context across su when you
> want it for roles and levels).  More recent versions of Fedora (and RHEL
> 5) split them back out again.  One might add an option to su to support
> simultaneous newrole, but you don't want it by default.
>
>   
My concern was that when I su I may have a context which is invalid for 
the user. What I was thinking was that my context should be the default 
for the user I've su'd to as defined in default_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: su and context

[Stephen Smalley]

On Tue, 2007-02-13 at 10:51 -0600, Ted X Toth wrote:
> Stephen Smalley wrote:
> > On Mon, 2007-02-12 at 10:39 -0600, Michael C Thompson wrote:
> >   
> >> Ted X Toth wrote:
> >>     
> >>> Why doesn't my context change when I 'su' to a different user?
> >>>       
> >> I'm pretty sure su isn't SELinux aware like newrole is -- not 
> >> investigated the source enough to save 100%, but pretty sure.
> >>
> >> Is there a reason why you would want it to affect your context?
> >>
> >> DAC and MAC are not intended to be related I thought.
> >>     
> >
> > The behavior has actually changed over time; you'll find discussions
> > about it in the mailing list archives.  The original SELinux kept su
> > separate from security context changes.  Earlier versions of Fedora (and
> > RHEL 4) integrated them (via pam_selinux) in an effort to provide
> > greater transparency, but this caused its own set of problems (e.g. use
> > of su from init scripts, losing continuity of context across su when you
> > want it for roles and levels).  More recent versions of Fedora (and RHEL
> > 5) split them back out again.  One might add an option to su to support
> > simultaneous newrole, but you don't want it by default.
> >
> >   
> My concern was that when I su I may have a context which is invalid for 
> the user. What I was thinking was that my context should be the default 
> for the user I've su'd to as defined in default_contexts.

The Linux uid and the SELinux security context don't have to be linked
together and you generally don't want them linked except when a new
login session is created, as you want to preserve context for the
lifetime of the session.  When you su to root to perform an admin
action, you don't want to lose your level and role information and
always switch to a single role and level for root.

su'ing to a user isn't the same as logging in as that user; from an
accountability and label preservation POV, the actions should remain
traceable to (and limited by the label of) the original user.

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