<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
On 3/22/2010 5:18 PM, Daniel J Walsh wrote:
<blockquote cite="mid:4BA7DEA5.2060708@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 03/22/2010 03:51 PM, Andy Warner wrote:
<blockquote cite="mid:4BA7CA34.5010406@rubix.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
<br>
On 3/22/2010 3:22 PM, Daniel J Walsh wrote:
<blockquote cite="mid:4BA7C371.7090206@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
On 03/22/2010 03:14 PM, Andy Warner wrote:
<blockquote cite="mid:4BA7C181.1090703@rubix.com" type="cite">
<meta http-equiv="content-type"
content="text/html; charset=ISO-8859-1">
<font face="Arial">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 </font><font face="Arial">userdom_unpriv_user_template</font><font
face="Arial"> interface, as off the last targeted policy update. The
second are denials I now receive after changing our policy to use a
different interface.<br>
<br>
First issue:<br>
<br>
Our policy had been declaring a custom role (rubix_dbadm_r in this
case) using the following:<br>
</font><font face="Arial">userdom_unpriv_user_template</font><font
face="Arial">(</font><font face="Arial">rubix_dbadm</font><font
face="Arial">)<br>
corecmd_exec_shell(</font><font face="Arial">rubix_dbadm</font><font
face="Arial">_t)</font><br>
<br>
Originally, this worked for its intended purposes with no selinux
denials. As of installing policy update:<br>
Name : selinux-policy-targeted<br>
Arch : noarch<br>
Version : 3.6.32<br>
Release : 103.fc12<br>
<br>
When we build our policy we received the following errors:<br>
rubix-dev.te:175: Warning: xserver_user_client() has been deprecated,
please use xserver_user_x_domain_template instead.<br>
Installing rubix-dev-targeted policy<br>
libsepol.print_missing_requirements: rubix-dev's global requirements
were not met: type/attribute xdrawable_type (No such file or directory).<br>
libsemanage.semanage_link_sandbox: Link packages failed (No such file
or directory).<br>
semodule: Failed!<br>
<br>
</blockquote>
Looks like a bug in the interface, You can probably hand edit it, to
remove the requirement for xdrawable_type.<br>
</blockquote>
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 <font face="Arial">userdom_restricted_user_template
(or
should
it be </font><font face="Arial">userdom_base_user_template?).</font>
<blockquote cite="mid:4BA7C371.7090206@redhat.com" type="cite"><br>
<blockquote cite="mid:4BA7C181.1090703@rubix.com" type="cite">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.<br>
<br>
Noting the X connection between the depreciated function and the link
error, I traced the reference to the depreciated 'xserver_user_client'
interface to '<font face="Arial">userdom_unpriv_user_template'. I did
not call </font>'xserver_user_client' directly. I replaced the call to
'<font face="Arial">userdom_unpriv_user_template' </font>with a call
to '<font face="Arial">userdom_restricted_user_template' and my then
policy installed properly. </font><br>
<br>
But using the '<font face="Arial">userdom_restricted_user_template ' </font>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.<br>
<br>
Should the '<font face="Arial">userdom_unpriv_user_template' interface
either be fixed or removed from the userdom *.if file?</font><br>
<font face="Arial"><br>
Second issue:<br>
<br>
The rubix_dbadm_r role is now created with:<br>
userdom_restricted_user_template(</font><font face="Arial">rubix_dbadm</font><font
face="Arial">)<br>
corecmd_exec_shell(</font><font face="Arial">rubix_dbadm</font><font
face="Arial">_t)<br>
<br>
When I perform a newrole, I receive denials as follows (note, I am in
permissive mode so the newrole succeeds):<br>
<br>
$ id -Z<br>
rxdev_u:staff_r:staff_t:s0-s0:c0.c1023<br>
$ ls -Z `tty`<br>
crw--w----. warner tty rxdev_u:object_r:user_devpts_t:s0 /dev/pts/4<br>
$ newrole -r rubix_dbadm_r<br>
Password: <br>
$ <br>
<br>
Note: I am a bit surprised that the tty type is </font><font
face="Arial">user_devpts_t and not </font><font face="Arial">staff_devpts_t</font>,
though
I
am
very
unfamiliar
with this.<br>
<font face="Arial"><br>
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<br>
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<br>
<br>
</font></blockquote>
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.<br>
</blockquote>
Here are the AVC's I get which seem related to the newrole usage:<br>
<br>
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<br>
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<br>
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=?'<br>
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=?'<br>
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=?'<br>
<br>
<br>
<blockquote cite="mid:4BA7C371.7090206@redhat.com" type="cite">
<blockquote cite="mid:4BA7C181.1090703@rubix.com" type="cite"><font
face="Arial"># more securetty_types<br>
sysadm_tty_device_t<br>
user_tty_device_t<br>
staff_tty_device_t<br>
user_devpts_t<br>
devpts_t<br>
#<br>
<br>
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?<br>
<br>
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.<br>
<br>
Thanks,<br>
<br>
Andy <br>
<br>
</font>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
--
selinux mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:selinux@lists.fedoraproject.org">selinux@lists.fedoraproject.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://admin.fedoraproject.org/mailman/listinfo/selinux">https://admin.fedoraproject.org/mailman/listinfo/selinux</a></pre>
</blockquote>
Do you want <font face="Arial">rubix_dbadm_t to be a full login user
or just the domain to run with when you are root?<br>
</font></blockquote>
Trusted RUBIX implements SELinux within our DBMS objects and
administrative programs. Similar to SEPostgreSQL <br>
<br>
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. <br>
<br>
</blockquote>
I am suggesting you open a bugzilla on this but hand edited to be able
to continue your work. Patches to fix the interface problem would be
helpful. If your goal is to get this to work on RHEL6 you might want
to start working with the F13 policy.<br>
</blockquote>
<br>
Sorry for being dense, are you suggesting I open a bugzilla regarding
the behavior of newrole or the <font face="Arial">userdom_unpriv_user_template
interface, or both? I assumed that since no one else complained about
the interface, it must not be used much as I caught an error just
updating the targeted policy.<br>
<br>
Just curious, is there something regarding what I am doing now that
jumps out that would have a problem with F13? WE, and our customers,
are very interested in the RHEL6 when it comes out. We have been
basically using the same basic policy since F9. This is the largest
issue we have had as of yet. I'd love to help with patching the
interface issue, but I a afraid I would have a very large learning
curve getting into the policy.<br>
</font><font face="Arial"></font>
<blockquote cite="mid:4BA7DEA5.2060708@redhat.com" type="cite">
<blockquote cite="mid:4BA7CA34.5010406@rubix.com" type="cite">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. <br>
<blockquote cite="mid:4BA7C371.7090206@redhat.com" type="cite"><font
face="Arial">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).<br>
</font></blockquote>
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.<br>
<br>
</blockquote>
Ok sounds good. I think the <font face="Arial">userdom_restricted_user_template
is
what you want for your other roles. Since this is the least
privileged user.<br>
</font>
<blockquote cite="mid:4BA7CA34.5010406@rubix.com" type="cite">Thanks
for your help,<br>
<br>
Andy<br>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
--
selinux mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:selinux@lists.fedoraproject.org">selinux@lists.fedoraproject.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://admin.fedoraproject.org/mailman/listinfo/selinux">https://admin.fedoraproject.org/mailman/listinfo/selinux</a></pre>
</blockquote>
<br>
</blockquote>
</body>
</html>