|
On 3/22/2010 3:22 PM, Daniel J Walsh wrote: On 03/22/2010 03:14 PM, Andy Warner wrote:I believe there are other unmet requirements as well. Also, this will be an issue for the users of Trusted RUBIX. I would rather not request that they hand edit portions of the non-RUBIX policy. So, if it works properly, I would rather just use userdom_restricted_user_template (or should it be userdom_base_user_template?).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.Looks like a bug in the interface, You can probably hand edit it, to remove the requirement for xdrawable_type. Here are the AVC's I get which seem related to the newrole usage: type=AVC msg=audit(1269286396.529:155): avc: denied { write } for pid=5636 comm="newrole" name="system_bus_socket" dev=dm-0 ino=153 scontext=rxdev_u:staff_r:newrole_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_dbusd_var_run_t:s0 tclass=sock_file type=AVC msg=audit(1269286396.529:155): avc: denied { connectto } for pid=5636 comm="newrole" path="/var/run/dbus/system_bus_socket" scontext=rxdev_u:staff_r:newrole_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=unix_stream_socket type=USER_AVC msg=audit(1269286396.540:156): user pid=1003 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=org.freedesktop.DBus member=Hello dest=org.freedesktop.DBus spid=5636 scontext=rxdev_u:staff_r:newrole_t:s0-s0:c0.c1023 tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' type=USER_AVC msg=audit(1269286396.563:157): user pid=1003 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_call interface=net.reactivated.Fprint.Manager member=GetDefaultDevice dest=net.reactivated.Fprint spid=5636 tpid=5640 scontext=rxdev_u:staff_r:newrole_t:s0-s0:c0.c1023 tcontext=system_u:system_r:fprintd_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' type=USER_AVC msg=audit(1269286396.567:158): user pid=1003 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=error error_name=net.reactivated.Fprint.Error.NoSuchDevice dest=:1.131 spid=5640 tpid=5636 scontext=system_u:system_r:fprintd_t:s0-s0:c0.c1023 tcontext=rxdev_u:staff_r:newrole_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?' Trusted RUBIX implements SELinux within our DBMS objects and administrative programs. Similar to SEPostgreSQL# more securetty_typesDo you want rubix_dbadm_t to be a full login user or just the domain to run with when you are root? We want it to be a full login user, if possible. Bare minimum is to be able to open a shell as the rubix_dbadm_t, typically transitioning from staff_r. Actually, the role has more associated with it than just rubix_dbadm_t. This role is configured to run administrative programs on behalf of our DBMS. It is also configured to run DBMS sessions with special privilege. I am not sure of the reference to root. But, root is not a factor in this. In becoming/using our rubix_dbadm_r role (or any of our DBMS roles, the user should not become nor need to transition through the linux root user. 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).It is more than just restart services. This is a fundamental role within the Trusted RUBIX RBAC. For instance, we have DBMS Security Administrator, Audit Administrator, Operator, and User roles. All with various abilities to run Trusted RUBIX administrative programs and all with differing privilege with regards to a DBMS session. Thanks for your help, Andy |
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
