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@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
> --
> selinux mailing list
> selinux@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
Actually I am mistaken, we did back port semodule -DB to RHEL5
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
