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!
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
# 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
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@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).
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@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
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@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.
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@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 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.
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.
Ok sounds good. I think the userdom_restricted_user_template is what you want for your other roles. Since this is the least privileged user.
Thanks for your help,
Andy
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 3/22/2010 5:18 PM, Daniel J Walsh wrote:
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@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 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.
Sorry for being dense, are you suggesting I open a bugzilla regarding the behavior of newrole or the 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.
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.
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.
Ok sounds good. I think the userdom_restricted_user_template is what you want for your other roles. Since this is the least privileged user.
Thanks for your help,
Andy
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On 03/22/2010 06:11 PM, Andy Warner wrote:
On 3/22/2010 5:18 PM, Daniel J Walsh wrote:
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@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 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.
Sorry for being dense, are you suggesting I open a bugzilla regarding the behavior of newrole or the 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.
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.
Yes open two different bugzillas.
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.
Ok sounds good. I think the userdom_restricted_user_template is what you want for your other roles. Since this is the least privileged user.
Thanks for your help,
Andy
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org
-
Andy Warner -
Daniel J Walsh