Labelling problems with a user directly running an application in a confined domain

Labelling problems with a user directly running an application in a confined domain

[Kim Lawson-Jenkins]

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

Hi,

 

I'm pretty sure my questions are basic SELinux 101 but I'm having a problem
confining an application when a user runs the application directly.  On our
system I have removed the unconfined domain and unconfined user.  When the
system initializes the confined applications run in the correct confined
domains.  However, if I use ssh to access the server, stop an application,
and then start the application again, the application will run with the
label sshd_t.  I haven't tried starting a confined application from a local
console but I'll probably encounter a similar problem.  How should I modify
the policy to allow a confined user to execute an application but  also have
the application run in the application's confined domain?

 

Kim

 


[-- Attachment #2: Type: text/html, Size: 2529 bytes --]

Re: Labelling problems with a user directly running an application in a confined domain

[Stephen Smalley]

On 04/01/2014 09:59 AM, Kim Lawson-Jenkins wrote:
> Hi,
> 
>  
> 
> I’m pretty sure my questions are basic SELinux 101 but I’m having a
> problem confining an application when a user runs the application
> directly.  On our system I have removed the unconfined domain and
> unconfined user.  When the system initializes the confined applications
> run in the correct confined domains.  However, if I use ssh to access
> the server, stop an application, and then start the application again,
> the application will run with the label sshd_t.  I haven’t tried
> starting a confined application from a local console but I’ll probably
> encounter a similar problem.  How should I modify the policy to allow a
> confined user to execute an application but  also have the application
> run in the application’s confined domain?

If it is running in sshd_t, that suggests a bug in your policy that
prevented sshd from transitioning into a user domain.

When you removed the unconfined domain and user, did you also update
your semanage login and semanage user mappings so that no user is still
being mapped to unconfined_u / unconfined_r?

RE: Labelling problems with a user directly running an application in a confined domain

[Kim Lawson-Jenkins]

Steven,

Here's the output of semanage user -l

SELinux User                SELinux Roles
appuser_u                   appuser_r
confinedapp_u          user_r, system_r
root                                staff_r, sysadm_r, system_r,
unconfined_r
staff_u                          staff_r, sysadm_r, system_r, unconfined_r
sysadm_u                    sysadm_r
system_u                     system_r unconfined_r
user_u                           user_r


I read on a SELinux-related blog that unconfined_r should be mapped to
staff_u when removing the unconfined domain, so I didn't remove unconfined
_r for all of the SELinux users.  Should I remove unconfined_r for staff_u?

Here is the output of semanage login -l

Login Name            SELinux User
__default__           staff_u
appuser                    appuser_u
root                            staff_u
system_u                system_u

Thanks for a response.

Kim

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Tuesday, April 01, 2014 11:13 AM
To: kim.lawson-jenkins@nrl.navy.mil; selinux@tycho.nsa.gov
Subject: Re: Labelling problems with a user directly running an application
in a confined domain

On 04/01/2014 09:59 AM, Kim Lawson-Jenkins wrote:
> Hi,
> 
>  
> 
> I'm pretty sure my questions are basic SELinux 101 but I'm having a 
> problem confining an application when a user runs the application 
> directly.  On our system I have removed the unconfined domain and 
> unconfined user.  When the system initializes the confined 
> applications run in the correct confined domains.  However, if I use 
> ssh to access the server, stop an application, and then start the 
> application again, the application will run with the label sshd_t.  I 
> haven't tried starting a confined application from a local console but 
> I'll probably encounter a similar problem.  How should I modify the 
> policy to allow a confined user to execute an application but  also 
> have the application run in the application's confined domain?

If it is running in sshd_t, that suggests a bug in your policy that
prevented sshd from transitioning into a user domain.

When you removed the unconfined domain and user, did you also update your
semanage login and semanage user mappings so that no user is still being
mapped to unconfined_u / unconfined_r?

Re: Labelling problems with a user directly running an application in a confined domain

[Stephen Smalley]

On 04/01/2014 01:04 PM, Kim Lawson-Jenkins wrote:
> Steven,
> 
> Here's the output of semanage user -l
> 
> SELinux User                SELinux Roles
> appuser_u                   appuser_r
> confinedapp_u          user_r, system_r
> root                                staff_r, sysadm_r, system_r,
> unconfined_r
> staff_u                          staff_r, sysadm_r, system_r, unconfined_r
> sysadm_u                    sysadm_r
> system_u                     system_r unconfined_r
> user_u                           user_r
> 
> 
> I read on a SELinux-related blog that unconfined_r should be mapped to
> staff_u when removing the unconfined domain, so I didn't remove unconfined
> _r for all of the SELinux users.  Should I remove unconfined_r for staff_u?

That doesn't make sense.  Can you cite this blog?

> Here is the output of semanage login -l
> 
> Login Name            SELinux User
> __default__           staff_u
> appuser                    appuser_u
> root                            staff_u
> system_u                system_u
> 
> Thanks for a response.

I expect you would need to update or remove all references to
unconfined_u, unconfined_r, and unconfined_t from your semanage
login/user mappings and from any of the
/etc/selinux/$SELINUXTYPE/contexts files before deleting the unconfined
module.

Is there a reason you aren't just using the mls policy if you want to
avoid the unconfined module?

RE: Labelling problems with a user directly running an application in a confined domain

[Kim Lawson-Jenkins]

Stephen,

See answers below...

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Tuesday, April 01, 2014 1:07 PM
To: kim.lawson-jenkins@nrl.navy.mil; selinux@tycho.nsa.gov
Subject: Re: Labelling problems with a user directly running an application
in a confined domain

On 04/01/2014 01:04 PM, Kim Lawson-Jenkins wrote:
> Steven,
> 
> Here's the output of semanage user -l
> 
> SELinux User                SELinux Roles
> appuser_u                   appuser_r
> confinedapp_u          user_r, system_r
> root                                staff_r, sysadm_r, system_r,
> unconfined_r
> staff_u                          staff_r, sysadm_r, system_r, unconfined_r
> sysadm_u                    sysadm_r
> system_u                     system_r unconfined_r
> user_u                           user_r
> 
> 
> I read on a SELinux-related blog that unconfined_r should be mapped to 
> staff_u when removing the unconfined domain, so I didn't remove 
> unconfined _r for all of the SELinux users.  Should I remove unconfined_r
for staff_u?

That doesn't make sense.  Can you cite this blog?

http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-eight-unconfin
ed.html  



> Here is the output of semanage login -l
> 
> Login Name            SELinux User
> __default__           staff_u
> appuser                    appuser_u
> root                            staff_u
> system_u                system_u
> 
> Thanks for a response.

I expect you would need to update or remove all references to unconfined_u,
unconfined_r, and unconfined_t from your semanage login/user mappings and
from any of the /etc/selinux/$SELINUXTYPE/contexts files before deleting the
unconfined module.

Is there a reason you aren't just using the mls policy if you want to avoid
the unconfined module?

Kim's response - I'm updating a policy for an application that ran on RHEL5
using the then-supported strict policy.  I read that removing the unconfined
domain will make the newer systems operate as the old strict policy, so I
went with this method for updating the policy.  I hadn't heard about using
mls as an alternative to removing the unconfined module.

Re: Labelling problems with a user directly running an application in a confined domain

[Stephen Smalley]

On 04/01/2014 01:42 PM, Kim Lawson-Jenkins wrote:
>> I read on a SELinux-related blog that unconfined_r should be mapped to 
>> staff_u when removing the unconfined domain, so I didn't remove 
>> unconfined _r for all of the SELinux users.  Should I remove unconfined_r
> for staff_u?
> 
> That doesn't make sense.  Can you cite this blog?
> 
> http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-eight-unconfin
> ed.html

It looks like his example was for the case where you remove only the
unconfined module, not unconfineduser.

I think you at least need to update
/etc/selinux/targeted/contexts/failsafe_context to use a different
context if fully removing unconfined_r/unconfined_t.  And certainly Red
Hat isn't testing that scenario.

> Kim's response - I'm updating a policy for an application that ran on RHEL5
> using the then-supported strict policy.  I read that removing the unconfined
> domain will make the newer systems operate as the old strict policy, so I
> went with this method for updating the policy.  I hadn't heard about using
> mls as an alternative to removing the unconfined module.

The mls policy has always been strict policy + MLS (instead of MCS).
Whether or not the specific -mls package that your distribution includes
has everything you need I don't know.

RE: Labelling problems with a user directly running an application in a confined domain

[Kim Lawson-Jenkins]

Stephen,

OK.  I understand.  Thanks for all of the responses.

Kim

-----Original Message-----
From: Stephen Smalley [mailto:sds@tycho.nsa.gov] 
Sent: Tuesday, April 01, 2014 1:53 PM
To: kim.lawson-jenkins@nrl.navy.mil; selinux@tycho.nsa.gov
Subject: Re: Labelling problems with a user directly running an application
in a confined domain

On 04/01/2014 01:42 PM, Kim Lawson-Jenkins wrote:
>> I read on a SELinux-related blog that unconfined_r should be mapped 
>> to staff_u when removing the unconfined domain, so I didn't remove 
>> unconfined _r for all of the SELinux users.  Should I remove 
>> unconfined_r
> for staff_u?
> 
> That doesn't make sense.  Can you cite this blog?
> 
> http://selinux-mac.blogspot.com/2009/06/selinux-lockdown-part-eight-un
> confin
> ed.html

It looks like his example was for the case where you remove only the
unconfined module, not unconfineduser.

I think you at least need to update
/etc/selinux/targeted/contexts/failsafe_context to use a different context
if fully removing unconfined_r/unconfined_t.  And certainly Red Hat isn't
testing that scenario.

> Kim's response - I'm updating a policy for an application that ran on 
> RHEL5 using the then-supported strict policy.  I read that removing 
> the unconfined domain will make the newer systems operate as the old 
> strict policy, so I went with this method for updating the policy.  I 
> hadn't heard about using mls as an alternative to removing the unconfined
module.

The mls policy has always been strict policy + MLS (instead of MCS).
Whether or not the specific -mls package that your distribution includes has
everything you need I don't know.