Hi, I have been experimenting with confined users in centos54 to create my own staff and admin roles. I have only been meddling with policies for services before so creating user domains is new territory for me. For the test I used userdom_unpriv_user_template() and userdom_admin_user_template() interfaces to create the an unprivileged login role and an admin role. The first test policy module looked like the one below but without the call auth_run_chk_passwd() interface.
In permissive mode I could login and verify with id -Z that I had the correct login role and type. I could use newrole to switch to the admin role and again verify that I received the correct role and type. I did not get any AVC denials when doing this.
Now when I switched to enforcing mode I could login to the login role as before but when I ran newrole to switch to the admin role, newrole said 'incorrect password' and failed' but still no AVC denials. I traced newrole with strace and I could see that it failed trying to open /etc/shadow
When comparing centos54 interface for newrole in selinuxutil.if with corresponding interface in fedora12 (where I got a similar test working) I saw that the newrole interface in fedora12 called interfaces in authlogin.if so I added similar calls in my module and then I got it working in enforcing mode too ! Although I think the newrole interface in centos54 is kind of useless when it does not handle the authentication permissions internally :-(
Now before I proceed with this project I would like to clear up my understanding of user domains so if anyone of you can answer these questions it would be much appreciated. The ultimate target environment for my project is a RedHat5 based server farm.
- First of all is this the right way to do this kind of thing or am I completely on the wrong track? Is the user domain support mature enough in redhat5 to be used in a production environment? If not I guess I have to wait for redhat6.
- Does anyone know how the feature transfer from Fedora to RedHat work? How much of the selinux functionality existing in Fedora12 can we expect to appear in RedHat 6 when it arrives?
- A assume that the reason my first test failed in enforcing mode without any AVC denials was because of some hidden don't audit rules in the interfaces I called. Is there some way to turn off don't audit rules globally to trace these problems ? (I tried semodule -DB although it is not listed as a valid option on centos54 semodule man page, but the only effect it had was that it got the setroubleshootd constantly crashing)
Thanks, /leif
Policy used in test below:
policy_module(myadm, 1.0.0)
require { type unconfined_t; type newrole_t; type user_home_t; type devpts_t; type system_chkpwd_t; }
# Create mystaff_r and mystaff_t userdom_unpriv_user_template(mystaff) allow mystaff_t user_home_t: file read; allow mystaff_t devpts_t:chr_file { read write ioctl };
# Allow login daemon (sshd) to transition to mystaff_t allow unconfined_t mystaff_t:process transition;
# Add "mystaff_r:mystaff_t" to /etc/selinux/targeted/ contexts/default_type
seutil_run_newrole(mystaff_t, mystaff_r, devpts_t)
# There is a typo in the auth_run_chk_passwd() interface so we can't use it. # Lets do the work inline instead # Implement auth_run_chk_passwd(newrole_t, mystaff_r, devpts_t) inline: auth_domtrans_chk_passwd(newrole_t) role mystaff_r types system_chkpwd_t; allow system_chkpwd_t devpts_t:chr_file rw_file_perms; auth_run_upd_passwd(newrole_t, mystaff_r, devpts_t)
# Create myadm_r and myadm_t userdom_admin_user_template(myadm)
# Add "myadm_r:myadm_t" to /etc/selinux/targeted/contexts/default_type
domain_transition_pattern(newrole_t, shell_exec_t, myadm_t) userdom_role_change_template(mystaff, myadm)
# Create mystaff_u gen_user(mystaff_u, mystaff, mystaff_r myadm_r, s0, s0 - mls_systemhigh, mcs_allcats)
On Thu, 2010-01-28 at 15:53 +0100, Leif Thuresson wrote:
Hi, I have been experimenting with confined users in centos54 to create my own staff and admin roles. I have only been meddling with policies for services before so creating user domains is new territory for me. For the test I used userdom_unpriv_user_template() and userdom_admin_user_template() interfaces to create the an unprivileged login role and an admin role. The first test policy module looked like the one below but without the call auth_run_chk_passwd() interface.
In permissive mode I could login and verify with id -Z that I had the correct login role and type. I could use newrole to switch to the admin role and again verify that I received the correct role and type. I did not get any AVC denials when doing this.
Now when I switched to enforcing mode I could login to the login role as before but when I ran newrole to switch to the admin role, newrole said 'incorrect password' and failed' but still no AVC denials. I traced newrole with strace and I could see that it failed trying to open /etc/shadow
When comparing centos54 interface for newrole in selinuxutil.if with corresponding interface in fedora12 (where I got a similar test working) I saw that the newrole interface in fedora12 called interfaces in authlogin.if so I added similar calls in my module and then I got it working in enforcing mode too ! Although I think the newrole interface in centos54 is kind of useless when it does not handle the authentication permissions internally :-(
Now before I proceed with this project I would like to clear up my understanding of user domains so if anyone of you can answer these questions it would be much appreciated. The ultimate target environment for my project is a RedHat5 based server farm.
- First of all is this the right way to do this kind of thing or am I
completely on the wrong track? Is the user domain support mature enough in redhat5 to be used in a production environment? If not I guess I have to wait for redhat6.
- Does anyone know how the feature transfer from Fedora to RedHat
work? How much of the selinux functionality existing in Fedora12 can we expect to appear in RedHat 6 when it arrives?
- A assume that the reason my first test failed in enforcing mode
without any AVC denials was because of some hidden don't audit rules in the interfaces I called. Is there some way to turn off don't audit rules globally to trace these problems ? (I tried semodule -DB although it is not listed as a valid option on centos54 semodule man page, but the only effect it had was that it got the setroubleshootd constantly crashing)
Thanks, /leif
Don't take this as an authoritative answer, as I don't speak for Red Hat. However: 1) I was under the impression that user domains in RHEL5 only work if you switch to the -strict policy first, as RHEL5 preceded the merging of targeted and strict policies. If you can in fact set up confined user roles under -targeted in RHEL5, that would be a good thing, but I didn't think it worked. 2) I'd expect RHEL6 SELinux support to be more-or-less identical to Fedora 12, possibly with some Fedora 13 bits included. 3) setroubleshootd will typically shut down when it sees an audit message for itself to avoid an endless cycle, and semodule -DB can certainly cause that to happen. But you should still get audit data in /var/log/audit/audit.log and/or /var/log/messages that you can use. setroubleshootd is just a consumer of it. I didn't know though that RHEL5 supported semodule -DB; I thought you had to semodule -b /usr/share/selinux/targeted/enableaudit.pp instead and then semodule -b /usr/share/selinux/targeted/base.pp to revert (the old way before semodule -DB existed).
On Thu, Jan 28, 2010 at 5:21 PM, Stephen Smalley sds@tycho.nsa.gov wrote:
On Thu, 2010-01-28 at 15:53 +0100, Leif Thuresson wrote:
Hi, I have been experimenting with confined users in centos54 to create my own staff and admin roles. I have only been meddling with policies for services before so creating user domains is new territory for me. For the test I used userdom_unpriv_user_template() and userdom_admin_user_template() interfaces to create the an unprivileged login role and an admin role. The first test policy module looked like the one below but without the call auth_run_chk_passwd() interface.
In permissive mode I could login and verify with id -Z that I had the correct login role and type. I could use newrole to switch to the admin role and again verify that I received the correct role and type. I did not get any AVC denials when doing this.
Now when I switched to enforcing mode I could login to the login role as before but when I ran newrole to switch to the admin role, newrole said 'incorrect password' and failed' but still no AVC denials. I traced newrole with strace and I could see that it failed trying to open /etc/shadow
When comparing centos54 interface for newrole in selinuxutil.if with corresponding interface in fedora12 (where I got a similar test working) I saw that the newrole interface in fedora12 called interfaces in authlogin.if so I added similar calls in my module and then I got it working in enforcing mode too ! Although I think the newrole interface in centos54 is kind of useless when it does not handle the authentication permissions internally :-(
Now before I proceed with this project I would like to clear up my understanding of user domains so if anyone of you can answer these questions it would be much appreciated. The ultimate target environment for my project is a RedHat5 based server farm.
- First of all is this the right way to do this kind of thing or am I
completely on the wrong track? Is the user domain support mature enough in redhat5 to be used in a production environment? If not I guess I have to wait for redhat6.
- Does anyone know how the feature transfer from Fedora to RedHat
work? How much of the selinux functionality existing in Fedora12 can we expect to appear in RedHat 6 when it arrives?
- A assume that the reason my first test failed in enforcing mode
without any AVC denials was because of some hidden don't audit rules in the interfaces I called. Is there some way to turn off don't audit rules globally to trace these problems ? (I tried semodule -DB although it is not listed as a valid option on centos54 semodule man page, but the only effect it had was that it got the setroubleshootd constantly crashing)
Thanks, /leif
Don't take this as an authoritative answer, as I don't speak for Red Hat. However:
- I was under the impression that user domains in RHEL5 only work if
you switch to the -strict policy first, as RHEL5 preceded the merging of targeted and strict policies. If you can in fact set up confined user roles under -targeted in RHEL5, that would be a good thing, but I didn't think it worked.
Well I can settle for only a users secondary role being confined but I not sure if that work either. This is what I wanted to test.
- I'd expect RHEL6 SELinux support to be more-or-less identical to
Fedora 12, possibly with some Fedora 13 bits included. 3) setroubleshootd will typically shut down when it sees an audit message for itself to avoid an endless cycle, and semodule -DB can certainly cause that to happen. But you should still get audit data in /var/log/audit/audit.log and/or /var/log/messages that you can use. setroubleshootd is just a consumer of it. I didn't know though that RHEL5 supported semodule -DB; I thought you had to semodule -b /usr/share/selinux/targeted/enableaudit.pp instead and then semodule -b /usr/share/selinux/targeted/base.pp to revert (the old way before semodule -DB existed).
It is not mentioned in the man page, but it accepted the options without
complaints and something apparently happened. Thanks for the explanation of the setroubleshootd behavior. I'll look a bit closer at the log messages and see if I can find the missing AVCs
-- Stephen Smalley National Security Agency
On 01/28/2010 09:53 AM, Leif Thuresson wrote:
Hi, I have been experimenting with confined users in centos54 to create my own staff and admin roles. I have only been meddling with policies for services before so creating user domains is new territory for me. For the test I used userdom_unpriv_user_template() and userdom_admin_user_template() interfaces to create the an unprivileged login role and an admin role. The first test policy module looked like the one below but without the call auth_run_chk_passwd() interface.
In permissive mode I could login and verify with id -Z that I had the correct login role and type. I could use newrole to switch to the admin role and again verify that I received the correct role and type. I did not get any AVC denials when doing this.
Now when I switched to enforcing mode I could login to the login role as before but when I ran newrole to switch to the admin role, newrole said 'incorrect password' and failed' but still no AVC denials. I traced newrole with strace and I could see that it failed trying to open /etc/shadow
newrole is not allowed to read /etc/shadow (dontaudited), It expects the use the pam_unix module in Fedora/RHEL which execs a helper app to read the shadow file.
When comparing centos54 interface for newrole in selinuxutil.if with corresponding interface in fedora12 (where I got a similar test working) I saw that the newrole interface in fedora12 called interfaces in authlogin.if so I added similar calls in my module and then I got it working in enforcing mode too ! Although I think the newrole interface in centos54 is kind of useless when it does not handle the authentication permissions internally :-(
Now before I proceed with this project I would like to clear up my understanding of user domains so if anyone of you can answer these questions it would be much appreciated. The ultimate target environment for my project is a RedHat5 based server farm.
If you want to use confined users in RHEL5 you need to install the strict policy. Targeted policy does not support confined users in RHEL5. It does support them in RHEL6.
- First of all is this the right way to do this kind of thing or am I
completely on the wrong track? Is the user domain support mature enough in redhat5 to be used in a production environment?
Depends on what you are trying to do. If this is a server machine it will probably work ok, if you want to have confined desktops, you will probably run into problems.
If not I guess I have to wait for redhat6.
redhat6 should work well better with confined users.
- Does anyone know how the feature transfer from Fedora to RedHat work? How much of the selinux functionality existing in Fedora12 can we expect
to appear in RedHat 6 when it arrives?
All of it.
- A assume that the reason my first test failed in enforcing mode without
any AVC denials was because of some hidden don't audit rules in the interfaces I called. Is there some way to turn off don't audit rules globally to trace these problems ? (I tried semodule -DB although it is not listed as a valid option on centos54 semodule man page, but the only effect it had was that it got the setroubleshootd constantly crashing)
semodule -DB does not exist in RHEL5.
Thanks, /leif
Policy used in test below:
policy_module(myadm, 1.0.0)
require { type unconfined_t; type newrole_t; type user_home_t; type devpts_t; type system_chkpwd_t; }
# Create mystaff_r and mystaff_t userdom_unpriv_user_template(mystaff) allow mystaff_t user_home_t: file read; allow mystaff_t devpts_t:chr_file { read write ioctl };
# Allow login daemon (sshd) to transition to mystaff_t allow unconfined_t mystaff_t:process transition;
# Add "mystaff_r:mystaff_t" to /etc/selinux/targeted/ contexts/default_type
seutil_run_newrole(mystaff_t, mystaff_r, devpts_t)
# There is a typo in the auth_run_chk_passwd() interface so we can't use it. # Lets do the work inline instead # Implement auth_run_chk_passwd(newrole_t, mystaff_r, devpts_t) inline: auth_domtrans_chk_passwd(newrole_t) role mystaff_r types system_chkpwd_t; allow system_chkpwd_t devpts_t:chr_file rw_file_perms; auth_run_upd_passwd(newrole_t, mystaff_r, devpts_t)
# Create myadm_r and myadm_t userdom_admin_user_template(myadm)
# Add "myadm_r:myadm_t" to /etc/selinux/targeted/contexts/default_type
domain_transition_pattern(newrole_t, shell_exec_t, myadm_t) userdom_role_change_template(mystaff, myadm)
# Create mystaff_u gen_user(mystaff_u, mystaff, mystaff_r myadm_r, s0, s0 - mls_systemhigh, mcs_allcats)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 01/28/2010 11:32 AM, Daniel J Walsh wrote:
On 01/28/2010 09:53 AM, Leif Thuresson wrote:
Hi, I have been experimenting with confined users in centos54 to create my own staff and admin roles. I have only been meddling with policies for services before so creating user domains is new territory for me. For the test I used userdom_unpriv_user_template() and userdom_admin_user_template() interfaces to create the an unprivileged login role and an admin role. The first test policy module looked like the one below but without the call auth_run_chk_passwd() interface.
In permissive mode I could login and verify with id -Z that I had the correct login role and type. I could use newrole to switch to the admin role and again verify that I received the correct role and type. I did not get any AVC denials when doing this.
Now when I switched to enforcing mode I could login to the login role as before but when I ran newrole to switch to the admin role, newrole said 'incorrect password' and failed' but still no AVC denials. I traced newrole with strace and I could see that it failed trying to open /etc/shadow
newrole is not allowed to read /etc/shadow (dontaudited), It expects the use the pam_unix module in Fedora/RHEL which execs a helper app to read the shadow file.
When comparing centos54 interface for newrole in selinuxutil.if with corresponding interface in fedora12 (where I got a similar test working) I saw that the newrole interface in fedora12 called interfaces in authlogin.if so I added similar calls in my module and then I got it working in enforcing mode too ! Although I think the newrole interface in centos54 is kind of useless when it does not handle the authentication permissions internally :-(
Now before I proceed with this project I would like to clear up my understanding of user domains so if anyone of you can answer these questions it would be much appreciated. The ultimate target environment for my project is a RedHat5 based server farm.
If you want to use confined users in RHEL5 you need to install the strict policy. Targeted policy does not support confined users in RHEL5. It does support them in RHEL6.
- First of all is this the right way to do this kind of thing or am I
completely on the wrong track? Is the user domain support mature enough in redhat5 to be used in a production environment?
Depends on what you are trying to do. If this is a server machine it will probably work ok, if you want to have confined desktops, you will probably run into problems.
If not I guess I have to wait for redhat6.
redhat6 should work well better with confined users.
- Does anyone know how the feature transfer from Fedora to RedHat work? How much of the selinux functionality existing in Fedora12 can we expect
to appear in RedHat 6 when it arrives?
All of it.
- A assume that the reason my first test failed in enforcing mode without
any AVC denials was because of some hidden don't audit rules in the interfaces I called. Is there some way to turn off don't audit rules globally to trace these problems ? (I tried semodule -DB although it is not listed as a valid option on centos54 semodule man page, but the only effect it had was that it got the setroubleshootd constantly crashing)
semodule -DB does not exist in RHEL5.
Thanks, /leif
Policy used in test below:
policy_module(myadm, 1.0.0)
require { type unconfined_t; type newrole_t; type user_home_t; type devpts_t; type system_chkpwd_t; }
# Create mystaff_r and mystaff_t userdom_unpriv_user_template(mystaff) allow mystaff_t user_home_t: file read; allow mystaff_t devpts_t:chr_file { read write ioctl };
# Allow login daemon (sshd) to transition to mystaff_t allow unconfined_t mystaff_t:process transition;
# Add "mystaff_r:mystaff_t" to /etc/selinux/targeted/ contexts/default_type
seutil_run_newrole(mystaff_t, mystaff_r, devpts_t)
# There is a typo in the auth_run_chk_passwd() interface so we can't use it. # Lets do the work inline instead # Implement auth_run_chk_passwd(newrole_t, mystaff_r, devpts_t) inline: auth_domtrans_chk_passwd(newrole_t) role mystaff_r types system_chkpwd_t; allow system_chkpwd_t devpts_t:chr_file rw_file_perms; auth_run_upd_passwd(newrole_t, mystaff_r, devpts_t)
# Create myadm_r and myadm_t userdom_admin_user_template(myadm)
# Add "myadm_r:myadm_t" to /etc/selinux/targeted/contexts/default_type
domain_transition_pattern(newrole_t, shell_exec_t, myadm_t) userdom_role_change_template(mystaff, myadm)
# Create mystaff_u gen_user(mystaff_u, mystaff, mystaff_r myadm_r, s0, s0 - mls_systemhigh, mcs_allcats)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Actually I am mistaken, we did back port semodule -DB to RHEL5
On Thu, Jan 28, 2010 at 5:32 PM, Daniel J Walsh dwalsh@redhat.com wrote:
On 01/28/2010 09:53 AM, Leif Thuresson wrote:
Hi, I have been experimenting with confined users in centos54 to create my
own
staff and admin roles. I have only been meddling with policies for services before so creating
user
domains is new territory for me. For the test I used userdom_unpriv_user_template() and userdom_admin_user_template() interfaces to create the an unprivileged login role and an admin role. The first test policy module looked like the one below but without the
call
auth_run_chk_passwd() interface.
In permissive mode I could login and verify with id -Z that I had the correct login role and type. I could use newrole to switch to the admin role and again verify that I received the correct role and type. I did not get any AVC denials when doing this.
Now when I switched to enforcing mode I could login to the login role as before but when I ran newrole to switch to the admin role, newrole said 'incorrect password' and failed' but still no AVC denials. I traced newrole with strace and I could see that it failed trying to
open
/etc/shadow
newrole is not allowed to read /etc/shadow (dontaudited), It expects the use the pam_unix module in Fedora/RHEL which execs a helper app to read the shadow file.
Hmm... strange that this did not work in my test environment, What is the name of the helper app?
When comparing centos54 interface for newrole in selinuxutil.if with corresponding interface in fedora12 (where I got a similar test working) I saw that the newrole interface in fedora12 called interfaces in authlogin.if so I added similar calls in
my
module and then I got it working in enforcing mode too ! Although I think the newrole interface in centos54 is kind of useless
when
it does not handle the authentication permissions internally :-(
Now before I proceed with this project I would like to clear up my understanding of user domains so if anyone of you can answer these questions it would be
much
appreciated. The ultimate target environment for my project is a RedHat5 based server farm.
If you want to use confined users in RHEL5 you need to install the strict policy. Targeted policy does not support confined users in RHEL5. It does support them in RHEL6.
- First of all is this the right way to do this kind of thing or am I
completely on the wrong track? Is the user domain support mature enough in redhat5 to be used in a production environment?
Depends on what you are trying to do. If this is a server machine it will probably work ok, if you want to have confined desktops, you will probably run into problems.
What I want to do is to create admin roles with permissions to administer only a sub-system or service without the full power of root. I do realize that the natural way to do this would be to start with the strict policy, but it is my understanding that the strict policy is not fully supported by RedHat and that disqualifies it from being used in my target environment. My intension was to see if I could do something to gain a little bit of the confined user security improvements even with the targeted policy while waiting for the release of RedHat 6. The sub-system administrators can have a login role that is unconfined, but when executing admin commands via sudo or similar they will transfer into an admin role within a confined domain while the command is executing under uid=0 So I must have my own unconfined login domain for sub-administrators so that I can separate them from default unconfined domain. Does this make sense? I realize that RedHat support for this environment might be questionable, but ideally I would only have to support my own additional policy modules myself instead of taking on the support for the full strict policy.
If not I guess I have to wait for redhat6.
redhat6 should work well better with confined users.
- Does anyone know how the feature transfer from Fedora to RedHat work? How much of the selinux functionality existing in Fedora12 can we
expect
to appear in RedHat 6 when it arrives?
All of it.
Great! my problems will be solved then :-)
- A assume that the reason my first test failed in enforcing mode without
any AVC denials was because of some hidden don't audit rules in the interfaces I called. Is there some way to turn off don't audit rules globally to trace these problems ? (I tried semodule -DB although it is not listed as a valid option on centos54 semodule man page, but the only effect it had was that it got the setroubleshootd constantly crashing)
semodule -DB does not exist in RHEL5.
Thanks, /leif
Policy used in test below:
policy_module(myadm, 1.0.0)
require { type unconfined_t; type newrole_t; type user_home_t; type devpts_t; type system_chkpwd_t; }
# Create mystaff_r and mystaff_t userdom_unpriv_user_template(mystaff) allow mystaff_t user_home_t: file read; allow mystaff_t devpts_t:chr_file { read write ioctl };
# Allow login daemon (sshd) to transition to mystaff_t allow unconfined_t mystaff_t:process transition;
# Add "mystaff_r:mystaff_t" to /etc/selinux/targeted/ contexts/default_type
seutil_run_newrole(mystaff_t, mystaff_r, devpts_t)
# There is a typo in the auth_run_chk_passwd() interface so we can't use
it.
# Lets do the work inline instead # Implement auth_run_chk_passwd(newrole_t, mystaff_r, devpts_t) inline: auth_domtrans_chk_passwd(newrole_t) role mystaff_r types system_chkpwd_t; allow system_chkpwd_t devpts_t:chr_file rw_file_perms; auth_run_upd_passwd(newrole_t, mystaff_r, devpts_t)
# Create myadm_r and myadm_t userdom_admin_user_template(myadm)
# Add "myadm_r:myadm_t" to /etc/selinux/targeted/contexts/default_type
domain_transition_pattern(newrole_t, shell_exec_t, myadm_t) userdom_role_change_template(mystaff, myadm)
# Create mystaff_u gen_user(mystaff_u, mystaff, mystaff_r myadm_r, s0, s0 - mls_systemhigh, mcs_allcats)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 01/28/2010 03:20 PM, Leif Thuresson wrote:
On Thu, Jan 28, 2010 at 5:32 PM, Daniel J Walsh dwalsh@redhat.com wrote:
On 01/28/2010 09:53 AM, Leif Thuresson wrote:
Hi, I have been experimenting with confined users in centos54 to create my
own
staff and admin roles. I have only been meddling with policies for services before so creating
user
domains is new territory for me. For the test I used userdom_unpriv_user_template() and userdom_admin_user_template() interfaces to create the an unprivileged login role and an admin role. The first test policy module looked like the one below but without the
call
auth_run_chk_passwd() interface.
In permissive mode I could login and verify with id -Z that I had the correct login role and type. I could use newrole to switch to the admin role and again verify that I received the correct role and type. I did not get any AVC denials when doing this.
Now when I switched to enforcing mode I could login to the login role as before but when I ran newrole to switch to the admin role, newrole said 'incorrect password' and failed' but still no AVC denials. I traced newrole with strace and I could see that it failed trying to
open
/etc/shadow
newrole is not allowed to read /etc/shadow (dontaudited), It expects the use the pam_unix module in Fedora/RHEL which execs a helper app to read the shadow file.
Hmm... strange that this did not work in my test environment, What is the name of the helper app?
When comparing centos54 interface for newrole in selinuxutil.if with corresponding interface in fedora12 (where I got a similar test working) I saw that the newrole interface in fedora12 called interfaces in authlogin.if so I added similar calls in
my
module and then I got it working in enforcing mode too ! Although I think the newrole interface in centos54 is kind of useless
when
it does not handle the authentication permissions internally :-(
Now before I proceed with this project I would like to clear up my understanding of user domains so if anyone of you can answer these questions it would be
much
appreciated. The ultimate target environment for my project is a RedHat5 based server farm.
If you want to use confined users in RHEL5 you need to install the strict policy. Targeted policy does not support confined users in RHEL5. It does support them in RHEL6.
- First of all is this the right way to do this kind of thing or am I
completely on the wrong track? Is the user domain support mature enough in redhat5 to be used in a production environment?
Depends on what you are trying to do. If this is a server machine it will probably work ok, if you want to have confined desktops, you will probably run into problems.
What I want to do is to create admin roles with permissions to administer only a sub-system or service without the full power of root. I do realize that the natural way to do this would be to start with the strict policy, but it is my understanding that the strict policy is not fully supported by RedHat and that disqualifies it from being used in my target environment. My intension was to see if I could do something to gain a little bit of the confined user security improvements even with the targeted policy while waiting for the release of RedHat 6. The sub-system administrators can have a login role that is unconfined, but when executing admin commands via sudo or similar they will transfer into an admin role within a confined domain while the command is executing under uid=0 So I must have my own unconfined login domain for sub-administrators so that I can separate them from default unconfined domain. Does this make sense? I realize that RedHat support for this environment might be questionable, but ideally I would only have to support my own additional policy modules myself instead of taking on the support for the full strict policy.
If not I guess I have to wait for redhat6.
redhat6 should work well better with confined users.
- Does anyone know how the feature transfer from Fedora to RedHat work? How much of the selinux functionality existing in Fedora12 can we
expect
to appear in RedHat 6 when it arrives?
All of it.
Great! my problems will be solved then :-)
- A assume that the reason my first test failed in enforcing mode without
any AVC denials was because of some hidden don't audit rules in the interfaces I called. Is there some way to turn off don't audit rules globally to trace these problems ? (I tried semodule -DB although it is not listed as a valid option on centos54 semodule man page, but the only effect it had was that it got the setroubleshootd constantly crashing)
semodule -DB does not exist in RHEL5.
Thanks, /leif
Policy used in test below:
policy_module(myadm, 1.0.0)
require { type unconfined_t; type newrole_t; type user_home_t; type devpts_t; type system_chkpwd_t; }
# Create mystaff_r and mystaff_t userdom_unpriv_user_template(mystaff) allow mystaff_t user_home_t: file read; allow mystaff_t devpts_t:chr_file { read write ioctl };
# Allow login daemon (sshd) to transition to mystaff_t allow unconfined_t mystaff_t:process transition;
# Add "mystaff_r:mystaff_t" to /etc/selinux/targeted/ contexts/default_type
seutil_run_newrole(mystaff_t, mystaff_r, devpts_t)
# There is a typo in the auth_run_chk_passwd() interface so we can't use
it.
# Lets do the work inline instead # Implement auth_run_chk_passwd(newrole_t, mystaff_r, devpts_t) inline: auth_domtrans_chk_passwd(newrole_t) role mystaff_r types system_chkpwd_t; allow system_chkpwd_t devpts_t:chr_file rw_file_perms; auth_run_upd_passwd(newrole_t, mystaff_r, devpts_t)
# Create myadm_r and myadm_t userdom_admin_user_template(myadm)
# Add "myadm_r:myadm_t" to /etc/selinux/targeted/contexts/default_type
domain_transition_pattern(newrole_t, shell_exec_t, myadm_t) userdom_role_change_template(mystaff, myadm)
# Create mystaff_u gen_user(mystaff_u, mystaff, mystaff_r myadm_r, s0, s0 - mls_systemhigh, mcs_allcats)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
You could write a domain for commands that sudo executes and build a transition from unconfined_t -> confined_admin_exec_t -> confined_admin_t
Which should work in RHEL5 and 6.
If you want one unconfined user to execute these and another not, then you could have a problem, and might want to create a new unconfined user.
Or just do not execute the script.
For example.
You could label a shell as being confined_shell_exec_t /bin/confinedsh Then any "confined admin" would have to run confinedsh from sudo, while the unconfined admin would run /bin/bash.
As long as the unconfined admin does not run /bin/confinedsh he would stay unconfined.
On Thu, Jan 28, 2010 at 10:16 PM, Daniel J Walsh dwalsh@redhat.com wrote:
On 01/28/2010 03:20 PM, Leif Thuresson wrote:
On Thu, Jan 28, 2010 at 5:32 PM, Daniel J Walsh dwalsh@redhat.com
wrote:
On 01/28/2010 09:53 AM, Leif Thuresson wrote:
Hi, I have been experimenting with confined users in centos54 to create my
own
staff and admin roles. I have only been meddling with policies for services before so creating
user
domains is new territory for me. For the test I used userdom_unpriv_user_template() and userdom_admin_user_template() interfaces to create the an unprivileged login role and an admin role. The first test policy module looked like the one below but without the
call
auth_run_chk_passwd() interface.
In permissive mode I could login and verify with id -Z that I had the correct login role and type. I could use newrole to switch to the admin role and again verify that I received the correct role and type. I did not get any AVC denials when doing this.
Now when I switched to enforcing mode I could login to the login role
as
before but when I ran newrole to switch to the admin role, newrole said 'incorrect password' and failed' but still no AVC denials. I traced newrole with strace and I could see that it failed trying to
open
/etc/shadow
newrole is not allowed to read /etc/shadow (dontaudited), It expects the use the pam_unix module in Fedora/RHEL which execs a helper app to read
the
shadow file.
Hmm... strange that this did not work in my test environment, What is the name of the helper app?
When comparing centos54 interface for newrole in selinuxutil.if with corresponding interface in fedora12 (where I got a similar test working) I saw that
the
newrole interface in fedora12 called interfaces in authlogin.if so I added similar calls in
my
module and then I got it working in enforcing mode too ! Although I think the newrole interface in centos54 is kind of useless
when
it does not handle the authentication permissions internally :-(
Now before I proceed with this project I would like to clear up my understanding of user domains so if anyone of you can answer these questions it would be
much
appreciated. The ultimate target environment for my project is a RedHat5 based
server
farm.
If you want to use confined users in RHEL5 you need to install the
strict
policy. Targeted policy does not support confined users in RHEL5. It
does
support them in RHEL6.
- First of all is this the right way to do this kind of thing or am I
completely on the wrong track? Is the user domain support mature enough in redhat5 to be used in a production environment?
Depends on what you are trying to do. If this is a server machine it
will
probably work ok, if you want to have confined desktops, you will
probably
run into problems.
What I want to do is to create admin roles with permissions to administer only a sub-system or service without the full power of root. I do realize that the natural way to do this would be to start with the strict policy, but it is my understanding that the strict policy is not fully supported by RedHat and that disqualifies it from being used in my target environment. My intension was to see if I could do something to gain a little bit of
the
confined user security improvements even with the targeted policy while waiting for the release of RedHat 6. The sub-system administrators can have a login role that is unconfined,
but
when executing admin commands via sudo or similar they will transfer into
an
admin role within a confined domain while the command is executing under uid=0 So I must have my own unconfined login domain for sub-administrators so
that
I can separate them from default unconfined domain. Does this make sense? I realize that RedHat support for this environment might be questionable, but ideally I would only have to support my own additional policy modules myself instead of taking on the support for the full strict policy.
If not I guess I have to wait for redhat6.
redhat6 should work well better with confined users.
- Does anyone know how the feature transfer from Fedora to RedHat work? How much of the selinux functionality existing in Fedora12 can we
expect
to appear in RedHat 6 when it arrives?
All of it.
Great! my problems will be solved then :-)
- A assume that the reason my first test failed in enforcing mode
without
any AVC denials was because of some hidden don't audit rules in the interfaces I called. Is there some way to turn off don't audit rules globally to trace
these
problems ? (I tried semodule -DB although it is not listed as a valid option on centos54 semodule man page, but the only effect it had was that it got the setroubleshootd constantly crashing)
semodule -DB does not exist in RHEL5.
Thanks, /leif
Policy used in test below:
policy_module(myadm, 1.0.0)
require { type unconfined_t; type newrole_t; type user_home_t; type devpts_t; type system_chkpwd_t; }
# Create mystaff_r and mystaff_t userdom_unpriv_user_template(mystaff) allow mystaff_t user_home_t: file read; allow mystaff_t devpts_t:chr_file { read write ioctl };
# Allow login daemon (sshd) to transition to mystaff_t allow unconfined_t mystaff_t:process transition;
# Add "mystaff_r:mystaff_t" to /etc/selinux/targeted/ contexts/default_type
seutil_run_newrole(mystaff_t, mystaff_r, devpts_t)
# There is a typo in the auth_run_chk_passwd() interface so we can't
use
it.
# Lets do the work inline instead # Implement auth_run_chk_passwd(newrole_t, mystaff_r, devpts_t) inline: auth_domtrans_chk_passwd(newrole_t) role mystaff_r types system_chkpwd_t; allow system_chkpwd_t devpts_t:chr_file rw_file_perms; auth_run_upd_passwd(newrole_t, mystaff_r, devpts_t)
# Create myadm_r and myadm_t userdom_admin_user_template(myadm)
# Add "myadm_r:myadm_t" to /etc/selinux/targeted/contexts/default_type
domain_transition_pattern(newrole_t, shell_exec_t, myadm_t) userdom_role_change_template(mystaff, myadm)
# Create mystaff_u gen_user(mystaff_u, mystaff, mystaff_r myadm_r, s0, s0 -
mls_systemhigh,
mcs_allcats)
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
You could write a domain for commands that sudo executes and build a transition from unconfined_t -> confined_admin_exec_t -> confined_admin_t
Which should work in RHEL5 and 6.
If you want one unconfined user to execute these and another not, then you could have a problem, and might want to create a new unconfined user.
Or just do not execute the script.
For example.
You could label a shell as being confined_shell_exec_t /bin/confinedsh Then any "confined admin" would have to run confinedsh from sudo, while the unconfined admin would run /bin/bash.
As long as the unconfined admin does not run /bin/confinedsh he would stay unconfined.
Yes my intention was to create new SELinux users for the sub-administrators so I should be able to control domain transitions with different roles for different users. The idea is that while being in the unconfined domain DAC permissions will restrict the user and while running in the confined admin domain (with uid=0) SELinux will restrict access. Well I get the impression that you don't think the project is totally hopeless after all so that encourages me to continue along these lines a bit further :-) Thanks for your input. /Leif
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Leif Thuresson -
Stephen Smalley