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@xxxxxxxxxxxxxxxxxxxxxxx
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).
|
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
