userdom_unpriv_user_template use errors and creating new roles
Daniel J Walsh
dwalsh at redhat.com
Mon Mar 22 21:13:38 UTC 2010
On 03/22/2010 03:51 PM, Andy Warner wrote:
>
>
> On 3/22/2010 3:22 PM, Daniel J Walsh wrote:
>> 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 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?).
>>
>>> 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.
> 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=?'
>
>
>>> # 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?
> Trusted RUBIX implements SELinux within our DBMS objects and
> administrative programs. Similar to SEPostgreSQL
>
> 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
That is a bug, newrole is trying to communicate with the finger print
reader through pam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/selinux/attachments/20100322/81eec3dd/attachment.html
More information about the selinux
mailing list