Programmatic domain change to unprivileged role

Programmatic domain change to unprivileged role

[Dan Pou]

I have an existing daemon that I am working to enable in an MLS setting,
but I am running into difficulties with calls to get a context of an
unprivileged user from the daemon context
(system_u:system_r:<name-of-service>_t:s0-s15:c0.c1023).
The deamon will run an executable with ID of an authenticated user, so I
looked at trying to replicate the method used by sshd.
When sshd calls get_default_context, there is a transition defined to go
to the user_u:user_r:user_t domain, but there is not one available from
the daemon context I have developed.
Is there a simpler example than ssh that I could look at to understand
how to specify transitions?
The daemon uses the fork+execve method, so I don't think that I need the
dyntransition method, but it is not clear to me how to specify all the
required transitions for executing any file available to an unprivileged
user.

Thanks,
Dan

--
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: Programmatic domain change to unprivileged role

[Stephen Smalley]

On 08/05/2013 03:07 PM, Dan Pou wrote:
> I have an existing daemon that I am working to enable in an MLS setting,
> but I am running into difficulties with calls to get a context of an
> unprivileged user from the daemon context
> (system_u:system_r:<name-of-service>_t:s0-s15:c0.c1023).
> The deamon will run an executable with ID of an authenticated user, so I
> looked at trying to replicate the method used by sshd.
> When sshd calls get_default_context, there is a transition defined to go
> to the user_u:user_r:user_t domain, but there is not one available from
> the daemon context I have developed.
> Is there a simpler example than ssh that I could look at to understand
> how to specify transitions?
> The daemon uses the fork+execve method, so I don't think that I need the
> dyntransition method, but it is not clear to me how to specify all the
> required transitions for executing any file available to an unprivileged
> user.

Are you looking for how to write the code to perform the context change,
or how to write the policy to permit it to happen?  Or both?

If your question has to do with policy, then the refpolicy list or
fedora selinux list may be better resources, as it will depend on the
specific policy interfaces provided by refpolicy and/or your distribution.

The result of get_default_context() is of course driven by the policy,
so your ability to use it effectively depends on having the right policy
in place first.  Your daemon's domain will presumably need several of
the interfaces defined in system/userdomain.if to permit the domain
transition, along with interfaces from kernel/domain.if to permit
switching user and role.  Possibly something like:
userdom_spec_domtrans_unpriv_users(X_t)
userdom_bin_spec_domtrans_unpriv_users(X_t)
userdom_entry_spec_domtrans_unpriv_users(X_t)
domain_subj_id_change_exemption(X_t)
domain_role_change_exemption(X_t)




--
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: Programmatic domain change to unprivileged role

[Dan Pou]

On Tue, Aug 06, 2013 at 04:15:12PM -0400, Stephen Smalley wrote:
> On 08/05/2013 03:07 PM, Dan Pou wrote:
> > I have an existing daemon that I am working to enable in an MLS setting,
> > but I am running into difficulties with calls to get a context of an
> > unprivileged user from the daemon context
> > (system_u:system_r:<name-of-service>_t:s0-s15:c0.c1023).
> > The deamon will run an executable with ID of an authenticated user, so I
> > looked at trying to replicate the method used by sshd.
> > When sshd calls get_default_context, there is a transition defined to go
> > to the user_u:user_r:user_t domain, but there is not one available from
> > the daemon context I have developed.
> > Is there a simpler example than ssh that I could look at to understand
> > how to specify transitions?
> > The daemon uses the fork+execve method, so I don't think that I need the
> > dyntransition method, but it is not clear to me how to specify all the
> > required transitions for executing any file available to an unprivileged
> > user.
> 
> Are you looking for how to write the code to perform the context change,
> or how to write the policy to permit it to happen?  Or both?

I am looking at both.

> 
> If your question has to do with policy, then the refpolicy list or
> fedora selinux list may be better resources, as it will depend on the
> specific policy interfaces provided by refpolicy and/or your distribution.
I will give those a try as well.

> 
> The result of get_default_context() is of course driven by the policy,
> so your ability to use it effectively depends on having the right policy
> in place first.  Your daemon's domain will presumably need several of
> the interfaces defined in system/userdomain.if to permit the domain
> transition, along with interfaces from kernel/domain.if to permit
> switching user and role.  Possibly something like:
> userdom_spec_domtrans_unpriv_users(X_t)
> userdom_bin_spec_domtrans_unpriv_users(X_t)
> userdom_entry_spec_domtrans_unpriv_users(X_t)
> domain_subj_id_change_exemption(X_t)
> domain_role_change_exemption(X_t)

I tried a number of these, but without success.  I always get invalid
context when I use the get_default_context_with_level() or
get_ordered_context_list_with_level() functions with the fromcon set to
my daemon context.
Should these macros add the transitions? If it were a matter of denials
I would be OK, but my confusion arises from how to add all the necessary
transitions.
I assume I am missing something else that prevents my domain from being
a valid "from" context.  The service successfully runs from run_init
(through the _exec_ transition).

Thank you,
Dan

--
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: Programmatic domain change to unprivileged role

[Stephen Smalley]

On 08/06/2013 04:37 PM, Dan Pou wrote:
> On Tue, Aug 06, 2013 at 04:15:12PM -0400, Stephen Smalley wrote:
>> On 08/05/2013 03:07 PM, Dan Pou wrote:
>>> I have an existing daemon that I am working to enable in an MLS setting,
>>> but I am running into difficulties with calls to get a context of an
>>> unprivileged user from the daemon context
>>> (system_u:system_r:<name-of-service>_t:s0-s15:c0.c1023).
>>> The deamon will run an executable with ID of an authenticated user, so I
>>> looked at trying to replicate the method used by sshd.
>>> When sshd calls get_default_context, there is a transition defined to go
>>> to the user_u:user_r:user_t domain, but there is not one available from
>>> the daemon context I have developed.
>>> Is there a simpler example than ssh that I could look at to understand
>>> how to specify transitions?
>>> The daemon uses the fork+execve method, so I don't think that I need the
>>> dyntransition method, but it is not clear to me how to specify all the
>>> required transitions for executing any file available to an unprivileged
>>> user.
>>
>> Are you looking for how to write the code to perform the context change,
>> or how to write the policy to permit it to happen?  Or both?
> 
> I am looking at both.
> 
>>
>> If your question has to do with policy, then the refpolicy list or
>> fedora selinux list may be better resources, as it will depend on the
>> specific policy interfaces provided by refpolicy and/or your distribution.
> I will give those a try as well.
> 
>>
>> The result of get_default_context() is of course driven by the policy,
>> so your ability to use it effectively depends on having the right policy
>> in place first.  Your daemon's domain will presumably need several of
>> the interfaces defined in system/userdomain.if to permit the domain
>> transition, along with interfaces from kernel/domain.if to permit
>> switching user and role.  Possibly something like:
>> userdom_spec_domtrans_unpriv_users(X_t)
>> userdom_bin_spec_domtrans_unpriv_users(X_t)
>> userdom_entry_spec_domtrans_unpriv_users(X_t)
>> domain_subj_id_change_exemption(X_t)
>> domain_role_change_exemption(X_t)
> 
> I tried a number of these, but without success.  I always get invalid
> context when I use the get_default_context_with_level() or
> get_ordered_context_list_with_level() functions with the fromcon set to
> my daemon context.
> Should these macros add the transitions? If it were a matter of denials
> I would be OK, but my confusion arises from how to add all the necessary
> transitions.
> I assume I am missing something else that prevents my domain from being
> a valid "from" context.  The service successfully runs from run_init
> (through the _exec_ transition).

Invalid context means that the user-role, role-type, or user-level
combination are invalid according to policy.  Maybe you are passing in a
level that is not authorized for the user?

libselinux has some utilities (under libselinux/utils) that can be used
to exercise the get_default_context or get_ordered_context_list
interfaces from the command-line.  In the source, these are getconlist
and getdefaultcon; they appear to be packaged by Fedora in
libselinux-utils as selinuxconlist and selinuxdefcon.




--
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: Programmatic domain change to unprivileged role

[Stephen Smalley]

On 08/07/2013 08:28 AM, Stephen Smalley wrote:
> On 08/06/2013 04:37 PM, Dan Pou wrote:
>> On Tue, Aug 06, 2013 at 04:15:12PM -0400, Stephen Smalley wrote:
>>> On 08/05/2013 03:07 PM, Dan Pou wrote:
>>>> I have an existing daemon that I am working to enable in an MLS setting,
>>>> but I am running into difficulties with calls to get a context of an
>>>> unprivileged user from the daemon context
>>>> (system_u:system_r:<name-of-service>_t:s0-s15:c0.c1023).
>>>> The deamon will run an executable with ID of an authenticated user, so I
>>>> looked at trying to replicate the method used by sshd.
>>>> When sshd calls get_default_context, there is a transition defined to go
>>>> to the user_u:user_r:user_t domain, but there is not one available from
>>>> the daemon context I have developed.
>>>> Is there a simpler example than ssh that I could look at to understand
>>>> how to specify transitions?
>>>> The daemon uses the fork+execve method, so I don't think that I need the
>>>> dyntransition method, but it is not clear to me how to specify all the
>>>> required transitions for executing any file available to an unprivileged
>>>> user.
>>>
>>> Are you looking for how to write the code to perform the context change,
>>> or how to write the policy to permit it to happen?  Or both?
>>
>> I am looking at both.
>>
>>>
>>> If your question has to do with policy, then the refpolicy list or
>>> fedora selinux list may be better resources, as it will depend on the
>>> specific policy interfaces provided by refpolicy and/or your distribution.
>> I will give those a try as well.
>>
>>>
>>> The result of get_default_context() is of course driven by the policy,
>>> so your ability to use it effectively depends on having the right policy
>>> in place first.  Your daemon's domain will presumably need several of
>>> the interfaces defined in system/userdomain.if to permit the domain
>>> transition, along with interfaces from kernel/domain.if to permit
>>> switching user and role.  Possibly something like:
>>> userdom_spec_domtrans_unpriv_users(X_t)
>>> userdom_bin_spec_domtrans_unpriv_users(X_t)
>>> userdom_entry_spec_domtrans_unpriv_users(X_t)
>>> domain_subj_id_change_exemption(X_t)
>>> domain_role_change_exemption(X_t)
>>
>> I tried a number of these, but without success.  I always get invalid
>> context when I use the get_default_context_with_level() or
>> get_ordered_context_list_with_level() functions with the fromcon set to
>> my daemon context.
>> Should these macros add the transitions? If it were a matter of denials
>> I would be OK, but my confusion arises from how to add all the necessary
>> transitions.
>> I assume I am missing something else that prevents my domain from being
>> a valid "from" context.  The service successfully runs from run_init
>> (through the _exec_ transition).
> 
> Invalid context means that the user-role, role-type, or user-level
> combination are invalid according to policy.  Maybe you are passing in a
> level that is not authorized for the user?
> 
> libselinux has some utilities (under libselinux/utils) that can be used
> to exercise the get_default_context or get_ordered_context_list
> interfaces from the command-line.  In the source, these are getconlist
> and getdefaultcon; they appear to be packaged by Fedora in
> libselinux-utils as selinuxconlist and selinuxdefcon.

Note that you can either run them under gdb to find out exactly where
the error is occurring (and on what context string) or you can run them
under strace and look for the call that is yielding EINVAL, likely when
the context gets written to /sys/fs/selinux/context to check its validity.


--
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: Programmatic domain change to unprivileged role

[Dan Pou]

Thanks for the suggestion about strace, that is pointing to the problem.
I need to check the policy rules I have been adding to see how I got
here:

write(3, "user_u:sysadm_r:sysadm_t:s0\0", 28) = -1 EINVAL (Invalid
argument)

This is the second write.  When I test the same code with sshd_t to
<username> transition, I get one write, with a successful return of
default_context_with_level.

Thanks, this gives me something to go off of.
-Dan


On Wed, Aug 07, 2013 at 08:41:21AM -0400, Stephen Smalley wrote:
> On 08/07/2013 08:28 AM, Stephen Smalley wrote:
> > On 08/06/2013 04:37 PM, Dan Pou wrote:
> >> On Tue, Aug 06, 2013 at 04:15:12PM -0400, Stephen Smalley wrote:
> >>> On 08/05/2013 03:07 PM, Dan Pou wrote:
> >>>> I have an existing daemon that I am working to enable in an MLS setting,
> >>>> but I am running into difficulties with calls to get a context of an
> >>>> unprivileged user from the daemon context
> >>>> (system_u:system_r:<name-of-service>_t:s0-s15:c0.c1023).
> >>>> The deamon will run an executable with ID of an authenticated user, so I
> >>>> looked at trying to replicate the method used by sshd.
> >>>> When sshd calls get_default_context, there is a transition defined to go
> >>>> to the user_u:user_r:user_t domain, but there is not one available from
> >>>> the daemon context I have developed.
> >>>> Is there a simpler example than ssh that I could look at to understand
> >>>> how to specify transitions?
> >>>> The daemon uses the fork+execve method, so I don't think that I need the
> >>>> dyntransition method, but it is not clear to me how to specify all the
> >>>> required transitions for executing any file available to an unprivileged
> >>>> user.
> >>>
> >>> Are you looking for how to write the code to perform the context change,
> >>> or how to write the policy to permit it to happen?  Or both?
> >>
> >> I am looking at both.
> >>
> >>>
> >>> If your question has to do with policy, then the refpolicy list or
> >>> fedora selinux list may be better resources, as it will depend on the
> >>> specific policy interfaces provided by refpolicy and/or your distribution.
> >> I will give those a try as well.
> >>
> >>>
> >>> The result of get_default_context() is of course driven by the policy,
> >>> so your ability to use it effectively depends on having the right policy
> >>> in place first.  Your daemon's domain will presumably need several of
> >>> the interfaces defined in system/userdomain.if to permit the domain
> >>> transition, along with interfaces from kernel/domain.if to permit
> >>> switching user and role.  Possibly something like:
> >>> userdom_spec_domtrans_unpriv_users(X_t)
> >>> userdom_bin_spec_domtrans_unpriv_users(X_t)
> >>> userdom_entry_spec_domtrans_unpriv_users(X_t)
> >>> domain_subj_id_change_exemption(X_t)
> >>> domain_role_change_exemption(X_t)
> >>
> >> I tried a number of these, but without success.  I always get invalid
> >> context when I use the get_default_context_with_level() or
> >> get_ordered_context_list_with_level() functions with the fromcon set to
> >> my daemon context.
> >> Should these macros add the transitions? If it were a matter of denials
> >> I would be OK, but my confusion arises from how to add all the necessary
> >> transitions.
> >> I assume I am missing something else that prevents my domain from being
> >> a valid "from" context.  The service successfully runs from run_init
> >> (through the _exec_ transition).
> > 
> > Invalid context means that the user-role, role-type, or user-level
> > combination are invalid according to policy.  Maybe you are passing in a
> > level that is not authorized for the user?
> > 
> > libselinux has some utilities (under libselinux/utils) that can be used
> > to exercise the get_default_context or get_ordered_context_list
> > interfaces from the command-line.  In the source, these are getconlist
> > and getdefaultcon; they appear to be packaged by Fedora in
> > libselinux-utils as selinuxconlist and selinuxdefcon.
> 
> Note that you can either run them under gdb to find out exactly where
> the error is occurring (and on what context string) or you can run them
> under strace and look for the call that is yielding EINVAL, likely when
> the context gets written to /sys/fs/selinux/context to check its validity.

--
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: Programmatic domain change to unprivileged role

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/08/2013 03:58 PM, Dan Pou wrote:
> Thanks for the suggestion about strace, that is pointing to the problem. I
> need to check the policy rules I have been adding to see how I got here:
> 
> write(3, "user_u:sysadm_r:sysadm_t:s0\0", 28) = -1 EINVAL (Invalid 
> argument)
> 

Most likely user_u does not allowed sysadm_r

semanage user -l | grep user_u


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlIEvZoACgkQrlYvE4MpobOx3wCg0XS4z3Gw5U0lcYRiN/bE6X9y
KWYAn2QbXMP580qcCmftJBBOdQzJhivh
=6NHy
-----END PGP SIGNATURE-----

--
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: Programmatic domain change to unprivileged role

[Stephen Smalley]

On 08/08/2013 03:58 PM, Dan Pou wrote:
> Thanks for the suggestion about strace, that is pointing to the problem.
> I need to check the policy rules I have been adding to see how I got
> here:
> 
> write(3, "user_u:sysadm_r:sysadm_t:s0\0", 28) = -1 EINVAL (Invalid
> argument)
> 
> This is the second write.  When I test the same code with sshd_t to
> <username> transition, I get one write, with a successful return of
> default_context_with_level.
> 
> Thanks, this gives me something to go off of.

Could be that security_compute_user() (which writes to
/sys/fs/selinux/user) is getting an error or no results and thus the
code is trying to fall back to the failsafe context (as specified in
/etc/selinux/$SELINUXTYPE/contexts/failsafe_context), which isn't legal
for user_u.
The failsafe is to permit root / admin logins under such a situation.

I'd look to see what the result of writing to /sys/fs/selinux/user was
and what was written to it in the strace output.  You can also directly
call security_compute_user via the compute_user tool under
libselinux/utils if you obtain and build the sources yourself.  That
utility doesn't appear to get included in the libselinux-utils rpm though.




--
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: Programmatic domain change to unprivileged role

[Dan Pou]

On Fri, Aug 09, 2013 at 08:51:17AM -0400, Stephen Smalley wrote:
> On 08/08/2013 03:58 PM, Dan Pou wrote:
> > Thanks for the suggestion about strace, that is pointing to the problem.
> > I need to check the policy rules I have been adding to see how I got
> > here:
> > 
> > write(3, "user_u:sysadm_r:sysadm_t:s0\0", 28) = -1 EINVAL (Invalid
> > argument)
> > 
> > This is the second write.  When I test the same code with sshd_t to
> > <username> transition, I get one write, with a successful return of
> > default_context_with_level.
> > 
> > Thanks, this gives me something to go off of.
> 
> Could be that security_compute_user() (which writes to
> /sys/fs/selinux/user) is getting an error or no results and thus the
> code is trying to fall back to the failsafe context (as specified in
> /etc/selinux/$SELINUXTYPE/contexts/failsafe_context), which isn't legal
> for user_u.
> The failsafe is to permit root / admin logins under such a situation.
> 
> I'd look to see what the result of writing to /sys/fs/selinux/user was
> and what was written to it in the strace output.  You can also directly
> call security_compute_user via the compute_user tool under
> libselinux/utils if you obtain and build the sources yourself.  That
> utility doesn't appear to get included in the libselinux-utils rpm though.
> 
> 

I addeded the system_r:my_daemon_t:s0 user_r:user_t:s0 role transition
to /etc/selinux/mls/contexts/default_contexts.
This got me to actually writing user_u:user_r:user_t:s0 for setexeccon,
but I am still failing.  It looks like it is failing in the
selinux_trans_to_raw_context.  I was thinking this was an issue with
declaring the transition.
What steps do I need to setup a role_transition and/or type_transistion?

I tried adding the following to no avail:
type_transition my_daemon_t non_security_file_type:process user_t;
Do I need more type_transitions, or addition role_transition
declarations (aside from /etc/selinux/mls/contexts/default_context)?

Other info:
The daemon (without SELinux) just sets the euid/egid to match the user
requesting the job. So I inserted calls to
getseuserbyname
get_default_context_with_rolelevel or get_default_context_with_level
then setexeccon
the returned context before execve'ing.

Thanks
-Dan

--
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: Programmatic domain change to unprivileged role

[Dominick Grift]

On Tue, 2013-08-20 at 15:05 -0500, Dan Pou wrote:
< snip >
> 
> I addeded the system_r:my_daemon_t:s0 user_r:user_t:s0 role transition
> to /etc/selinux/mls/contexts/default_contexts.
> This got me to actually writing user_u:user_r:user_t:s0 for setexeccon,
> but I am still failing.  It looks like it is failing in the
> selinux_trans_to_raw_context.  I was thinking this was an issue with
> declaring the transition.
> What steps do I need to setup a role_transition and/or type_transistion?
> 
> I tried adding the following to no avail:
> type_transition my_daemon_t non_security_file_type:process user_t;
> Do I need more type_transitions, or addition role_transition
> declarations (aside from /etc/selinux/mls/contexts/default_context)?

Some things ( but i am not sure ):

The target role needs to be associated to the identity (probably already
done)
The target role needs to be associated to the target domain (probably
already done)
The source role needs to be allowed to manually change to the target
role (probably already done)

The source domain needs various permissions to change identity, role,
and set mls range (policy constraints: mlsprocsetsl
can_change_process_identity can_change_process_role )
The target security level must be within range of the selinux identity
associated level, range)

You probably need to specify the entrypoint to the target domain
You probably need to allow the actual transition permission from source
domain to target domain (allow my_daemon_t user_t:process transition)

As far as i know, the function calculates if what you specified is valid
first

I do not think you need a automatic role transition rule (it changes
manually instead i believe)

So you have to make sure those prerequisites are dealt with

I might be overlooking things and i might be totally wrong

> 
> Other info:
> The daemon (without SELinux) just sets the euid/egid to match the user
> requesting the job. So I inserted calls to
> getseuserbyname
> get_default_context_with_rolelevel or get_default_context_with_level
> then setexeccon
> the returned context before execve'ing.
> 
> Thanks
> -Dan
> 
> --
> 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.

Re: Programmatic domain change to unprivileged role

[Dan Pou]

On Wed, Aug 21, 2013 at 09:54:20AM +0200, Dominick Grift wrote:
> On Tue, 2013-08-20 at 15:05 -0500, Dan Pou wrote:
> < snip >
> > 
> > I addeded the system_r:my_daemon_t:s0 user_r:user_t:s0 role transition
> > to /etc/selinux/mls/contexts/default_contexts.
> > This got me to actually writing user_u:user_r:user_t:s0 for setexeccon,
> > but I am still failing.  It looks like it is failing in the
> > selinux_trans_to_raw_context.  I was thinking this was an issue with
> > declaring the transition.
> > What steps do I need to setup a role_transition and/or type_transistion?
> > 
> > I tried adding the following to no avail:
> > type_transition my_daemon_t non_security_file_type:process user_t;

I did find a mistake on my side (deployment to test machine issue).  I am
still in the process of testing explicit role and type transition rules.

> > Do I need more type_transitions, or addition role_transition
> > declarations (aside from /etc/selinux/mls/contexts/default_context)?
> 
> Some things ( but i am not sure ):
> 
> The target role needs to be associated to the identity (probably already
> done)
> The target role needs to be associated to the target domain (probably
> already done)
> The source role needs to be allowed to manually change to the target
> role (probably already done)
> 
> The source domain needs various permissions to change identity, role,
> and set mls range (policy constraints: mlsprocsetsl
> can_change_process_identity can_change_process_role )
> The target security level must be within range of the selinux identity
> associated level, range)
> 
> You probably need to specify the entrypoint to the target domain
> You probably need to allow the actual transition permission from source
> domain to target domain (allow my_daemon_t user_t:process transition)

Wouldn't these settings be associated with AVC denials?  I am running
Permissive and have no denials showing up.

> 
> As far as i know, the function calculates if what you specified is valid
> first
> 
> I do not think you need a automatic role transition rule (it changes
> manually instead i believe)

I thought you still needed to specify a transition with setexeccon. Is
this not true?

> 
> So you have to make sure those prerequisites are dealt with
> 
> I might be overlooking things and i might be totally wrong
> 

Thanks for getting back.
-Dan

--
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: Programmatic domain change to unprivileged role

[Stephen Smalley]

On 08/20/2013 04:05 PM, Dan Pou wrote:
> On Fri, Aug 09, 2013 at 08:51:17AM -0400, Stephen Smalley wrote:
>> On 08/08/2013 03:58 PM, Dan Pou wrote:
>>> Thanks for the suggestion about strace, that is pointing to the problem.
>>> I need to check the policy rules I have been adding to see how I got
>>> here:
>>>
>>> write(3, "user_u:sysadm_r:sysadm_t:s0\0", 28) = -1 EINVAL (Invalid
>>> argument)
>>>
>>> This is the second write.  When I test the same code with sshd_t to
>>> <username> transition, I get one write, with a successful return of
>>> default_context_with_level.
>>>
>>> Thanks, this gives me something to go off of.
>>
>> Could be that security_compute_user() (which writes to
>> /sys/fs/selinux/user) is getting an error or no results and thus the
>> code is trying to fall back to the failsafe context (as specified in
>> /etc/selinux/$SELINUXTYPE/contexts/failsafe_context), which isn't legal
>> for user_u.
>> The failsafe is to permit root / admin logins under such a situation.
>>
>> I'd look to see what the result of writing to /sys/fs/selinux/user was
>> and what was written to it in the strace output.  You can also directly
>> call security_compute_user via the compute_user tool under
>> libselinux/utils if you obtain and build the sources yourself.  That
>> utility doesn't appear to get included in the libselinux-utils rpm though.
>>
>>
> 
> I addeded the system_r:my_daemon_t:s0 user_r:user_t:s0 role transition
> to /etc/selinux/mls/contexts/default_contexts.
> This got me to actually writing user_u:user_r:user_t:s0 for setexeccon,
> but I am still failing.  It looks like it is failing in the
> selinux_trans_to_raw_context.  I was thinking this was an issue with
> declaring the transition.
> What steps do I need to setup a role_transition and/or type_transistion?
> 
> I tried adding the following to no avail:
> type_transition my_daemon_t non_security_file_type:process user_t;
> Do I need more type_transitions, or addition role_transition
> declarations (aside from /etc/selinux/mls/contexts/default_context)?
> 
> Other info:
> The daemon (without SELinux) just sets the euid/egid to match the user
> requesting the job. So I inserted calls to
> getseuserbyname
> get_default_context_with_rolelevel or get_default_context_with_level
> then setexeccon
> the returned context before execve'ing.

If you are getting to the point of setexeccon() with the correct
security context, then you are past the point of any type transition or
role transition rules.  The transition rules are just to define defaults
in the absence of an explicit setexeccon(); it is the allow rules that
govern what is permitted.  You do need both role allow and TE allow
rules in your policy, of course.  Did you add the interface calls that I
listed earlier for your daemon domain?  However, lack of permission
there should show up as an AVC denial; you might re-test with dontaudit
rules stripped to confirm (semodule -DB).

If the error truly lies during the trans_to_raw_context, then maybe you
have a problem in your label translation daemon?  Are you running
mcstransd or something else?  What happens if you simply stop the label
daemon (it isn't required for operation; it just provides translation of
MLS labels to and from more human-readable form and deals with complex
label encodings ala the old MITRE label encodings format).



--
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: Programmatic domain change to unprivileged role

[Stephen Smalley]

On 08/21/2013 10:22 AM, Stephen Smalley wrote:
> On 08/20/2013 04:05 PM, Dan Pou wrote:
>> On Fri, Aug 09, 2013 at 08:51:17AM -0400, Stephen Smalley wrote:
>>> On 08/08/2013 03:58 PM, Dan Pou wrote:
>>>> Thanks for the suggestion about strace, that is pointing to the problem.
>>>> I need to check the policy rules I have been adding to see how I got
>>>> here:
>>>>
>>>> write(3, "user_u:sysadm_r:sysadm_t:s0\0", 28) = -1 EINVAL (Invalid
>>>> argument)
>>>>
>>>> This is the second write.  When I test the same code with sshd_t to
>>>> <username> transition, I get one write, with a successful return of
>>>> default_context_with_level.
>>>>
>>>> Thanks, this gives me something to go off of.
>>>
>>> Could be that security_compute_user() (which writes to
>>> /sys/fs/selinux/user) is getting an error or no results and thus the
>>> code is trying to fall back to the failsafe context (as specified in
>>> /etc/selinux/$SELINUXTYPE/contexts/failsafe_context), which isn't legal
>>> for user_u.
>>> The failsafe is to permit root / admin logins under such a situation.
>>>
>>> I'd look to see what the result of writing to /sys/fs/selinux/user was
>>> and what was written to it in the strace output.  You can also directly
>>> call security_compute_user via the compute_user tool under
>>> libselinux/utils if you obtain and build the sources yourself.  That
>>> utility doesn't appear to get included in the libselinux-utils rpm though.
>>>
>>>
>>
>> I addeded the system_r:my_daemon_t:s0 user_r:user_t:s0 role transition
>> to /etc/selinux/mls/contexts/default_contexts.
>> This got me to actually writing user_u:user_r:user_t:s0 for setexeccon,
>> but I am still failing.  It looks like it is failing in the
>> selinux_trans_to_raw_context.  I was thinking this was an issue with
>> declaring the transition.
>> What steps do I need to setup a role_transition and/or type_transistion?
>>
>> I tried adding the following to no avail:
>> type_transition my_daemon_t non_security_file_type:process user_t;
>> Do I need more type_transitions, or addition role_transition
>> declarations (aside from /etc/selinux/mls/contexts/default_context)?
>>
>> Other info:
>> The daemon (without SELinux) just sets the euid/egid to match the user
>> requesting the job. So I inserted calls to
>> getseuserbyname
>> get_default_context_with_rolelevel or get_default_context_with_level
>> then setexeccon
>> the returned context before execve'ing.
> 
> If you are getting to the point of setexeccon() with the correct
> security context, then you are past the point of any type transition or
> role transition rules.  The transition rules are just to define defaults
> in the absence of an explicit setexeccon(); it is the allow rules that
> govern what is permitted.  You do need both role allow and TE allow
> rules in your policy, of course.  Did you add the interface calls that I
> listed earlier for your daemon domain?  However, lack of permission
> there should show up as an AVC denial; you might re-test with dontaudit
> rules stripped to confirm (semodule -DB).
> 
> If the error truly lies during the trans_to_raw_context, then maybe you
> have a problem in your label translation daemon?  Are you running
> mcstransd or something else?  What happens if you simply stop the label
> daemon (it isn't required for operation; it just provides translation of
> MLS labels to and from more human-readable form and deals with complex
> label encodings ala the old MITRE label encodings format).

Also, in addition to the interfaces I listed earlier, you likely need
mls_process_set_level(X_t)
to permit the daemon to set the current/low level.



--
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: Programmatic domain change to unprivileged role

[Dominick Grift]

On Wed, 2013-08-21 at 09:05 -0500, Dan Pou wrote:

> > Some things ( but i am not sure ):
> > 
> > The target role needs to be associated to the identity (probably already
> > done)
> > The target role needs to be associated to the target domain (probably
> > already done)
> > The source role needs to be allowed to manually change to the target
> > role (probably already done)
> > 
> > The source domain needs various permissions to change identity, role,
> > and set mls range (policy constraints: mlsprocsetsl
> > can_change_process_identity can_change_process_role )
> > The target security level must be within range of the selinux identity
> > associated level, range)
> > 
> > You probably need to specify the entrypoint to the target domain
> > You probably need to allow the actual transition permission from source
> > domain to target domain (allow my_daemon_t user_t:process transition)
> 
> Wouldn't these settings be associated with AVC denials?  I am running
> Permissive and have no denials showing up.
> 

I am not sure but here is what i think:

The function uses the policy to see if theres a valid path to the target
context by querying the policy used for calculation

So if the policy does not define a path the function will fail/abort,
thus it wont try it because it already determined that it wouldnt work
anyways. So you wont see ant avc denials because it didnt even try it

> > 
> > As far as i know, the function calculates if what you specified is valid
> > first
> > 
> > I do not think you need a automatic role transition rule (it changes
> > manually instead i believe)
> 
> I thought you still needed to specify a transition with setexeccon. Is
> this not true?

I am not sure, but again, i believe that no automatic role transition is
needed


--
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: Programmatic domain change to unprivileged role

[Dan Pou]

Thank you everyone for all the information.  I did manage to get
transitions working successfully (it seems part of the problem was
related to the policy install process I was using).  Most of the
remaining issues I face are related to RPM packaging a module, which I
can check the Fedora list for, if necessary.

Thanks again, for the help with setexeccon vs default transitions.
-Dan


On Wed, Aug 21, 2013 at 10:27:52AM -0400, Stephen Smalley wrote:
> On 08/21/2013 10:22 AM, Stephen Smalley wrote:
> > On 08/20/2013 04:05 PM, Dan Pou wrote:
> >> On Fri, Aug 09, 2013 at 08:51:17AM -0400, Stephen Smalley wrote:
> >>> On 08/08/2013 03:58 PM, Dan Pou wrote:
> >>>> Thanks for the suggestion about strace, that is pointing to the problem.
> >>>> I need to check the policy rules I have been adding to see how I got
> >>>> here:
> >>>>
> >>>> write(3, "user_u:sysadm_r:sysadm_t:s0\0", 28) = -1 EINVAL (Invalid
> >>>> argument)
> >>>>
> >>>> This is the second write.  When I test the same code with sshd_t to
> >>>> <username> transition, I get one write, with a successful return of
> >>>> default_context_with_level.
> >>>>
> >>>> Thanks, this gives me something to go off of.
> >>>
> >>> Could be that security_compute_user() (which writes to
> >>> /sys/fs/selinux/user) is getting an error or no results and thus the
> >>> code is trying to fall back to the failsafe context (as specified in
> >>> /etc/selinux/$SELINUXTYPE/contexts/failsafe_context), which isn't legal
> >>> for user_u.
> >>> The failsafe is to permit root / admin logins under such a situation.
> >>>
> >>> I'd look to see what the result of writing to /sys/fs/selinux/user was
> >>> and what was written to it in the strace output.  You can also directly
> >>> call security_compute_user via the compute_user tool under
> >>> libselinux/utils if you obtain and build the sources yourself.  That
> >>> utility doesn't appear to get included in the libselinux-utils rpm though.
> >>>
> >>>
> >>
> >> I addeded the system_r:my_daemon_t:s0 user_r:user_t:s0 role transition
> >> to /etc/selinux/mls/contexts/default_contexts.
> >> This got me to actually writing user_u:user_r:user_t:s0 for setexeccon,
> >> but I am still failing.  It looks like it is failing in the
> >> selinux_trans_to_raw_context.  I was thinking this was an issue with
> >> declaring the transition.
> >> What steps do I need to setup a role_transition and/or type_transistion?
> >>
> >> I tried adding the following to no avail:
> >> type_transition my_daemon_t non_security_file_type:process user_t;
> >> Do I need more type_transitions, or addition role_transition
> >> declarations (aside from /etc/selinux/mls/contexts/default_context)?
> >>
> >> Other info:
> >> The daemon (without SELinux) just sets the euid/egid to match the user
> >> requesting the job. So I inserted calls to
> >> getseuserbyname
> >> get_default_context_with_rolelevel or get_default_context_with_level
> >> then setexeccon
> >> the returned context before execve'ing.
> > 
> > If you are getting to the point of setexeccon() with the correct
> > security context, then you are past the point of any type transition or
> > role transition rules.  The transition rules are just to define defaults
> > in the absence of an explicit setexeccon(); it is the allow rules that
> > govern what is permitted.  You do need both role allow and TE allow
> > rules in your policy, of course.  Did you add the interface calls that I
> > listed earlier for your daemon domain?  However, lack of permission
> > there should show up as an AVC denial; you might re-test with dontaudit
> > rules stripped to confirm (semodule -DB).
> > 
> > If the error truly lies during the trans_to_raw_context, then maybe you
> > have a problem in your label translation daemon?  Are you running
> > mcstransd or something else?  What happens if you simply stop the label
> > daemon (it isn't required for operation; it just provides translation of
> > MLS labels to and from more human-readable form and deals with complex
> > label encodings ala the old MITRE label encodings format).
> 
> Also, in addition to the interfaces I listed earlier, you likely need
> mls_process_set_level(X_t)
> to permit the daemon to set the current/low level.
> 

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