userdom_unpriv_user_template use errors and creating new roles

[Daniel J Walsh]

On 03/22/2010 03:14 PM, Andy Warner wrote:
> Using FC12, fully updated. I have two basic, but possibly related 
> questions. The first is regarding a change to the targeted policy that 
> resulted in an install error for our Trusted RUBIX policy when using 
> the userdom_unpriv_user_template interface, as off the last targeted 
> policy update. The second are denials I now receive after changing our 
> policy to use a different interface.
>
> First issue:
>
> Our policy had been declaring a custom role (rubix_dbadm_r in this 
> case) using the following:
> userdom_unpriv_user_template(rubix_dbadm)
> corecmd_exec_shell(rubix_dbadm_t)
>
> Originally, this worked for its intended purposes with no selinux 
> denials. As of installing policy update:
> Name       : selinux-policy-targeted
> Arch       : noarch
> Version    : 3.6.32
> Release    : 103.fc12
>
> When we build our policy we received the following errors:
> rubix-dev.te:175: Warning: xserver_user_client() has been deprecated, 
> please use xserver_user_x_domain_template instead.
> Installing rubix-dev-targeted policy
> libsepol.print_missing_requirements: rubix-dev's global requirements 
> were not met: type/attribute xdrawable_type (No such file or directory).
> libsemanage.semanage_link_sandbox: Link packages failed (No such file 
> or directory).
> semodule:  Failed!
>
Looks like a bug in the interface,  You can probably hand edit it, to 
remove the requirement for xdrawable_type.

> I had been receiving the depreciated warning a while (ignoring at my 
> own peril), the link error was new to this targeted policy version. I 
> also received errors while installing selinux-policy-targeted rpm 
> itself, stating a different requirement not being met in the then 
> installed rubix-dev policy. I do not recall the exact error message, 
> but remember it was an X related type that was missing.
>
> Noting the X connection between the depreciated function and the link 
> error, I traced the reference to the depreciated 'xserver_user_client' 
> interface to 'userdom_unpriv_user_template'. I did not call 
> 'xserver_user_client' directly. I replaced the call to 
> 'userdom_unpriv_user_template' with a call to 
> 'userdom_restricted_user_template' and my then policy installed properly.
>
> But using the 'userdom_restricted_user_template ' interface, now I 
> notice some selinux denials during a call to newrole, which is my 
> second question below. I am not sure that the change to the new 
> interface is the cause of the denials, I am just now noticing them.
>
> Should the 'userdom_unpriv_user_template' interface either be fixed or 
> removed from the userdom *.if file?
>
> Second issue:
>
> The rubix_dbadm_r role is now created with:
> userdom_restricted_user_template(rubix_dbadm)
> corecmd_exec_shell(rubix_dbadm_t)
>
> When I perform a newrole, I receive denials as follows (note, I am in 
> permissive mode so the newrole succeeds):
>
> $ id -Z
> rxdev_u:staff_r:staff_t:s0-s0:c0.c1023
> $ ls -Z `tty`
> crw--w----. warner tty rxdev_u:object_r:user_devpts_t:s0 /dev/pts/4
> $ newrole -r rubix_dbadm_r
> Password:
> $
>
> Note: I am a bit surprised that the tty type is user_devpts_t and not 
> staff_devpts_t, though I am very unfamiliar with this.
>
> Mar 22 11:04:03 localhost setroubleshoot: SELinux is preventing 
> /usr/bin/newrole "write" access on /var/run/dbus/system_bus_socket. 
> For complete SELinux messages. run sealert -l 
> 95fc56ee-8711-460c-874b-6ddb91cc9add
> Mar 22 11:04:03 localhost setroubleshoot: SELinux is preventing 
> /usr/bin/newrole "write" access on /var/run/dbus/system_bus_socket. 
> For complete SELinux messages. run sealert -l 
> 95fc56ee-8711-460c-874b-6ddb91cc9add
>
These look like a bug in policy.  Something in the pam stack is trying 
to communicate with dbus and newrole is not allowed this access. What do 
the AVC messages look like.
> # more securetty_types
> sysadm_tty_device_t
> user_tty_device_t
> staff_tty_device_t
> user_devpts_t
> devpts_t
> #
>
> Are these denials related to how I create the rubix_dbadm_r role? Is 
> there a proper way to create a role suitable for  auser to transition 
> into and as a potential default logon user role?
>
> I fully admit my choice of creating a role was through observation of 
> other policy code and trail and error. It would be nice to have a 
> definitive word on it.
>
> Thanks,
>
> Andy
>
>
> --
> selinux mailing list
> selinux at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux
Do you want rubix_dbadm_t to be a full login user or just the domain to 
run with when you are root?
If you want to allow full use of a desktop but only allow certain privs 
as root, I would use staff_t and then transition through sudo to 
rubix_dbadm_t.   Setup an SELinux user that logs in as staff_t and has 
the staff_r, rubix_dbadm_r and system_r (If he needs to restart services).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/selinux/attachments/20100322/69dbfb4f/attachment-0001.html