Hi,
I recently raised a bug[1] that while using confined users / system administrators iotop would not work. Normally, iotop only runs as root, so reasonably, it shouldn't run as staff_t, but it should be able to run while in sysadm_t.
Initially I have created the template with:
sepolicy generate --application /usr/sbin/iotop
I have build and installed this basic template for now, and of course as predicted I'm still having some issues with denials.
Am I on the right track to setup iotop with a iotop_t policy so that it can access the kernel resources it needs when a user with sysadm_t calls it? Given the messages I am seeing now are as follows:
type=AVC msg=audit(1381226118.448:6322): avc: denied { create } for pid=19326 comm="iotop" scontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tcontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=netlink_socket
I assume that sysadm_t is not allowed to transition to iotop_t. What is the right way to write this into my te file? I note that in the selinux reference policy there are a number of calls to:
optional_policy(` uml_role(sysadm_r, sysadm_t) ')
What is the function of the <domain>_role() call, and is this what I should be using (I have iotop_role in my if)
Following that, what is the correct way to allow the sysadm_t to execute this, but not staff_t etc?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=10163
On Tue, 2013-10-08 at 20:30 +1030, William Brown wrote:
Hi,
I recently raised a bug[1] that while using confined users / system administrators iotop would not work. Normally, iotop only runs as root, so reasonably, it shouldn't run as staff_t, but it should be able to run while in sysadm_t.
Initially I have created the template with:
sepolicy generate --application /usr/sbin/iotop
I have build and installed this basic template for now, and of course as predicted I'm still having some issues with denials.
Am I on the right track to setup iotop with a iotop_t policy so that it can access the kernel resources it needs when a user with sysadm_t calls it? Given the messages I am seeing now are as follows:
type=AVC msg=audit(1381226118.448:6322): avc: denied { create } for pid=19326 comm="iotop" scontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tcontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=netlink_socket
I assume that sysadm_t is not allowed to transition to iotop_t. What is the right way to write this into my te file? I note that in the selinux reference policy there are a number of calls to:
optional_policy(` uml_role(sysadm_r, sysadm_t) ')
What is the function of the <domain>_role() call, and is this what I should be using (I have iotop_role in my if)
Following that, what is the correct way to allow the sysadm_t to execute this, but not staff_t etc?
The role templates are a bit of relic of the passed. They are templates that provide templated rules that allow the caller to run the program in the programs domain, and allow the callers role access to the programs domain.
Back in the day, we used to prefix home directories for separation using role prefixes. So instead of user_home_t for generic user home content you would have sysadm_home_t for generic home content of sysadm.
That concept was later dropped in favor of new security model called user based access control.
Anyways nowadays the role template are generally used when the to transition program domain creates content in the user home directory or if the program needs to be able to run generic shells/binaries in the calling user domain.
For iotop you could probably just create a iotop_run interface which takes care of the domain transition only and will allow the calling role access to the target domain. I do not believe iotop creates content in the user home directory, or that it runs shell, and other generic binaries on behalf of the calling process.
An example of how your iotop module might look like is the dmidecode module, and its call by sysadm:
optional_policy(` dmidecode_run(sysadm_t, sysadm_r) ')
[1] https://bugzilla.redhat.com/show_bug.cgi?id=10163
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Tue, 2013-10-08 at 14:13 +0200, Dominick Grift wrote:
On Tue, 2013-10-08 at 20:30 +1030, William Brown wrote:
Hi,
I recently raised a bug[1] that while using confined users / system administrators iotop would not work. Normally, iotop only runs as root, so reasonably, it shouldn't run as staff_t, but it should be able to run while in sysadm_t.
Initially I have created the template with:
sepolicy generate --application /usr/sbin/iotop
I have build and installed this basic template for now, and of course as predicted I'm still having some issues with denials.
Am I on the right track to setup iotop with a iotop_t policy so that it can access the kernel resources it needs when a user with sysadm_t calls it? Given the messages I am seeing now are as follows:
type=AVC msg=audit(1381226118.448:6322): avc: denied { create } for pid=19326 comm="iotop" scontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tcontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=netlink_socket
I assume that sysadm_t is not allowed to transition to iotop_t. What is the right way to write this into my te file? I note that in the selinux reference policy there are a number of calls to:
optional_policy(` uml_role(sysadm_r, sysadm_t) ')
What is the function of the <domain>_role() call, and is this what I should be using (I have iotop_role in my if)
Following that, what is the correct way to allow the sysadm_t to execute this, but not staff_t etc?
The role templates are a bit of relic of the passed. They are templates that provide templated rules that allow the caller to run the program in the programs domain, and allow the callers role access to the programs domain.
Back in the day, we used to prefix home directories for separation using role prefixes. So instead of user_home_t for generic user home content you would have sysadm_home_t for generic home content of sysadm.
That concept was later dropped in favor of new security model called user based access control.
Anyways nowadays the role template are generally used when the to transition program domain creates content in the user home directory or if the program needs to be able to run generic shells/binaries in the calling user domain.
For iotop you could probably just create a iotop_run interface which takes care of the domain transition only and will allow the calling role access to the target domain. I do not believe iotop creates content in the user home directory, or that it runs shell, and other generic binaries on behalf of the calling process.
An example of how your iotop module might look like is the dmidecode module, and its call by sysadm:
optional_policy(` dmidecode_run(sysadm_t, sysadm_r) ')
Well the explanation above is not quite accurate.
there are more factors ( such are long running process might be suitable for role interfaces ), plus i there is a difference between role interfaces and per role templates.
But iptop can probably be considered a short running process, so think a a run interface is probably the best option
[1] https://bugzilla.redhat.com/show_bug.cgi?id=10163
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Tue, 2013-10-08 at 14:28 +0200, Dominick Grift wrote:
On Tue, 2013-10-08 at 14:13 +0200, Dominick Grift wrote:
On Tue, 2013-10-08 at 20:30 +1030, William Brown wrote:
Hi,
I recently raised a bug[1] that while using confined users / system administrators iotop would not work. Normally, iotop only runs as root, so reasonably, it shouldn't run as staff_t, but it should be able to run while in sysadm_t.
Initially I have created the template with:
sepolicy generate --application /usr/sbin/iotop
I have build and installed this basic template for now, and of course as predicted I'm still having some issues with denials.
Am I on the right track to setup iotop with a iotop_t policy so that it can access the kernel resources it needs when a user with sysadm_t calls it? Given the messages I am seeing now are as follows:
type=AVC msg=audit(1381226118.448:6322): avc: denied { create } for pid=19326 comm="iotop" scontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tcontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=netlink_socket
I assume that sysadm_t is not allowed to transition to iotop_t. What is the right way to write this into my te file? I note that in the selinux reference policy there are a number of calls to:
optional_policy(` uml_role(sysadm_r, sysadm_t) ')
What is the function of the <domain>_role() call, and is this what I should be using (I have iotop_role in my if)
Following that, what is the correct way to allow the sysadm_t to execute this, but not staff_t etc?
The role templates are a bit of relic of the passed. They are templates that provide templated rules that allow the caller to run the program in the programs domain, and allow the callers role access to the programs domain.
Back in the day, we used to prefix home directories for separation using role prefixes. So instead of user_home_t for generic user home content you would have sysadm_home_t for generic home content of sysadm.
That concept was later dropped in favor of new security model called user based access control.
Anyways nowadays the role template are generally used when the to transition program domain creates content in the user home directory or if the program needs to be able to run generic shells/binaries in the calling user domain.
For iotop you could probably just create a iotop_run interface which takes care of the domain transition only and will allow the calling role access to the target domain. I do not believe iotop creates content in the user home directory, or that it runs shell, and other generic binaries on behalf of the calling process.
An example of how your iotop module might look like is the dmidecode module, and its call by sysadm:
optional_policy(` dmidecode_run(sysadm_t, sysadm_r) ')
Well the explanation above is not quite accurate.
there are more factors ( such are long running process might be suitable for role interfaces ), plus i there is a difference between role interfaces and per role templates.
But iptop can probably be considered a short running process, so think a a run interface is probably the best option
I made a 30 minute demonstration about creating policy for iotop (on rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs
[1] https://bugzilla.redhat.com/show_bug.cgi?id=10163
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
That concept was later dropped in favor of new security model called user based access control.
Got any links about user based access control so that I can learn more about it?
I made a 30 minute demonstration about creating policy for iotop (on rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs
Fantastic. Thanks for your combined emails. It has revealed a lot to me. I'll watch your video, and will create a similar policy for iotop on Fedora. If you don't mind, I'll post it here for review once I'm done.
On Wed, 2013-10-09 at 07:10 +1030, William Brown wrote:
That concept was later dropped in favor of new security model called user based access control.
Got any links about user based access control so that I can learn more about it?
Its not that well documented, and its rarely used as far as i know
here is one blog post about it that google returned:
http://blog.siphos.be/2011/05/selinux-user-based-access-control/
I made a 30 minute demonstration about creating policy for iotop (on rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs
Fantastic. Thanks for your combined emails. It has revealed a lot to me. I'll watch your video, and will create a similar policy for iotop on Fedora. If you don't mind, I'll post it here for review once I'm done.
sure, you can post it but if the policy looks like the one i created in my video then its ok
I made a 30 minute demonstration about creating policy for iotop (on rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs
Fantastic. Thanks for your combined emails. It has revealed a lot to me. I'll watch your video, and will create a similar policy for iotop on Fedora. If you don't mind, I'll post it here for review once I'm done.
sure, you can post it but if the policy looks like the one i created in my video then its ok
Well hopefully it does. I'm not aiming to copy your policy directly, as I want to learn the steps so I can write these for myself.
I have already run into one issue. I have created an iotop module and iotop_sysadm module, but once loaded I see a number of errors in ausearch like:
libsepol.sepol_context_to_sid: could not convert staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 to sid libsepol.context_from_record: invalid security context: "staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023" libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure
My research shows this is when you forget the "s0" on a file context, but this isn't the case here.
I've attached my policy that I have partially written at this point, and any advice would be appreciated on this.
On Wed, 2013-10-09 at 08:04 +1030, William Brown wrote:
I made a 30 minute demonstration about creating policy for iotop (on rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs
Fantastic. Thanks for your combined emails. It has revealed a lot to me. I'll watch your video, and will create a similar policy for iotop on Fedora. If you don't mind, I'll post it here for review once I'm done.
sure, you can post it but if the policy looks like the one i created in my video then its ok
Well hopefully it does. I'm not aiming to copy your policy directly, as I want to learn the steps so I can write these for myself.
I have already run into one issue. I have created an iotop module and iotop_sysadm module, but once loaded I see a number of errors in ausearch like:
libsepol.sepol_context_to_sid: could not convert staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 to sid libsepol.context_from_record: invalid security context: "staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023" libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure
My research shows this is when you forget the "s0" on a file context, but this isn't the case here.
I've attached my policy that I have partially written at this point, and any advice would be appreciated on this.
It might be related to the roleattribute stuff did you try it like i did in my example by commenting the roleattribute/attribute_role stuff out and using the old was of assoviating the sysadm_r role to iotop_t?
is sysadm_r associotated to staff_u? is the full mcs range associated to staff_u and to your linux uid/gid?
On Wed, 2013-10-09 at 08:04 +1030, William Brown wrote:
I made a 30 minute demonstration about creating policy for iotop (on rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs
Fantastic. Thanks for your combined emails. It has revealed a lot to me. I'll watch your video, and will create a similar policy for iotop on Fedora. If you don't mind, I'll post it here for review once I'm done.
sure, you can post it but if the policy looks like the one i created in my video then its ok
Well hopefully it does. I'm not aiming to copy your policy directly, as I want to learn the steps so I can write these for myself.
I have already run into one issue. I have created an iotop module and iotop_sysadm module, but once loaded I see a number of errors in ausearch like:
libsepol.sepol_context_to_sid: could not convert staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 to sid libsepol.context_from_record: invalid security context: "staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023" libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure
It says that the staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 content is invalid. So you should check whether the combination of these security identifiers is valid
you can use the seinfo , semanage and sesearch tools to determine that
to determine whether your uid/gid is associated to staff_u/s0-s0:c0.c1023:
semanage login -l |grep myadm myadm staff_u s0-s0:c0.c1023
to determine whether the staff_u sid is associated to the sysadm_r role and range of s0-s0:c0.c1023:
semanage user -l | grep staff_u staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
to determine whether staff_r can manually change to sysadm_r:
sesearch --role_allow | grep "allow staff_r " | grep sysadm_r allow staff_r sysadm_r;
to determine whether the sysadm_r role is associated to the iotop_t domain:
seinfo -xrsysadm_r | grep iotop iotop_t
to determine whether whether sysadm_t automatically domain transitions to iotop_t when he runs a file with type iotop_exec_t:
sesearch -ASCT -s sysadm_t -t iotop_exec_t | grep type_transition type_transition sysadm_t iotop_exec_t : process iotop_t;
if all the above prerequisites are met then things should probably work in the default fedora/rhel set up
My research shows this is when you forget the "s0" on a file context, but this isn't the case here.
I've attached my policy that I have partially written at this point, and any advice would be appreciated on this.
On Wed, 2013-10-09 at 09:41 +0200, Dominick Grift wrote:
On Wed, 2013-10-09 at 08:04 +1030, William Brown wrote:
I made a 30 minute demonstration about creating policy for iotop (on rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs
Fantastic. Thanks for your combined emails. It has revealed a lot to me. I'll watch your video, and will create a similar policy for iotop on Fedora. If you don't mind, I'll post it here for review once I'm done.
sure, you can post it but if the policy looks like the one i created in my video then its ok
Well hopefully it does. I'm not aiming to copy your policy directly, as I want to learn the steps so I can write these for myself.
I have already run into one issue. I have created an iotop module and iotop_sysadm module, but once loaded I see a number of errors in ausearch like:
libsepol.sepol_context_to_sid: could not convert staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 to sid libsepol.context_from_record: invalid security context: "staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023" libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure
It says that the staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 content is invalid. So you should check whether the combination of these security identifiers is valid
you can use the seinfo , semanage and sesearch tools to determine that
to determine whether your uid/gid is associated to staff_u/s0-s0:c0.c1023:
semanage login -l |grep myadm myadm staff_u s0-s0:c0.c1023
to determine whether the staff_u sid is associated to the sysadm_r role and range of s0-s0:c0.c1023:
semanage user -l | grep staff_u staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
to determine whether staff_r can manually change to sysadm_r:
sesearch --role_allow | grep "allow staff_r " | grep sysadm_r allow staff_r sysadm_r;
to determine whether the sysadm_r role is associated to the iotop_t domain:
seinfo -xrsysadm_r | grep iotop iotop_t
This is the only one that's missing. The rest are all correct as your examples show.
Solved, by adding:
role iotop_roles types iotop_t;
to my te file.
to determine whether whether sysadm_t automatically domain transitions to iotop_t when he runs a file with type iotop_exec_t:
sesearch -ASCT -s sysadm_t -t iotop_exec_t | grep type_transition type_transition sysadm_t iotop_exec_t : process iotop_t;
if all the above prerequisites are met then things should probably work in the default fedora/rhel set up
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
As per the net_admin capability, removing it iotop gives this friendly spiel: Netlink error: Operation not permitted (1)
The Linux kernel interfaces that iotop relies on now require root priviliges or the NET_ADMIN capability. This change occured because a security issue (CVE-2011-2494) was found that allows leakage of sensitive data across user boundaries. If you require the ability to run iotop as a non-root user, please configure sudo to allow you to run iotop as root.
Please do not file bugs on iotop about this.
I have attached my version of the policy.
It still receives a small number of denials, that audit2allow lists here:
#============= iotop_t ============== allow iotop_t passwd_file_t:file read; allow iotop_t random_device_t:chr_file read;
#!!!! This avc can be allowed using the boolean 'global_ssp' allow iotop_t urandom_device_t:chr_file read;
But these don't prevent iotop working.
I would appreciate if you could review this policy. Thanks again for your help.
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
On Wed, 2013-10-09 at 09:41 +0200, Dominick Grift wrote:
On Wed, 2013-10-09 at 08:04 +1030, William Brown wrote:
I made a 30 minute demonstration about creating policy for iotop (on rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs
Fantastic. Thanks for your combined emails. It has revealed a lot to me. I'll watch your video, and will create a similar policy for iotop on Fedora. If you don't mind, I'll post it here for review once I'm done.
sure, you can post it but if the policy looks like the one i created in my video then its ok
Well hopefully it does. I'm not aiming to copy your policy directly, as I want to learn the steps so I can write these for myself.
I have already run into one issue. I have created an iotop module and iotop_sysadm module, but once loaded I see a number of errors in ausearch like:
libsepol.sepol_context_to_sid: could not convert staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 to sid libsepol.context_from_record: invalid security context: "staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023" libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure
It says that the staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 content is invalid. So you should check whether the combination of these security identifiers is valid
you can use the seinfo , semanage and sesearch tools to determine that
to determine whether your uid/gid is associated to staff_u/s0-s0:c0.c1023:
semanage login -l |grep myadm myadm staff_u s0-s0:c0.c1023
to determine whether the staff_u sid is associated to the sysadm_r role and range of s0-s0:c0.c1023:
semanage user -l | grep staff_u staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
to determine whether staff_r can manually change to sysadm_r:
sesearch --role_allow | grep "allow staff_r " | grep sysadm_r allow staff_r sysadm_r;
to determine whether the sysadm_r role is associated to the iotop_t domain:
seinfo -xrsysadm_r | grep iotop iotop_t
This is the only one that's missing. The rest are all correct as your examples show.
Solved, by adding:
role iotop_roles types iotop_t;
to my te file.
alright, i guess i overlooked that one when reviewing your policy
to determine whether whether sysadm_t automatically domain transitions to iotop_t when he runs a file with type iotop_exec_t:
sesearch -ASCT -s sysadm_t -t iotop_exec_t | grep type_transition type_transition sysadm_t iotop_exec_t : process iotop_t;
if all the above prerequisites are met then things should probably work in the default fedora/rhel set up
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
You can see that by looking up the interfaces.
but console devices have type console_device_t, where user terminals are prefixed with "user" (back in the role separation days these would be prefixed per role (sysadm_devpts_t, staff_devpts_t, user_devpts_t etc)
As per the net_admin capability, removing it iotop gives this friendly spiel: Netlink error: Operation not permitted (1)
The Linux kernel interfaces that iotop relies on now require root priviliges or the NET_ADMIN capability. This change occured because a security issue (CVE-2011-2494) was found that allows leakage of sensitive data across user boundaries. If you require the ability to run iotop as a non-root user, please configure sudo to allow you to run iotop as root.
Please do not file bugs on iotop about this.
OK, makes sense
I have attached my version of the policy.
It still receives a small number of denials, that audit2allow lists here:
#============= iotop_t ============== allow iotop_t passwd_file_t:file read;
auth_read_passwd_file() (or something like that)
allow iotop_t random_device_t:chr_file read;
dev_read_rand()
#!!!! This avc can be allowed using the boolean 'global_ssp' allow iotop_t urandom_device_t:chr_file read;
But these don't prevent iotop working.
OK but allowing these isnt such a bad deal and it gets rid of the avc denials.
one should be very conservative with dontaudit keyword TE AV rules
I would appreciate if you could review this policy. Thanks again for your help.
policy review:
kernel_rw_unix_dgram_sockets(iotop_t)
This one makes no sense, please look up the interface and try to determine why it doesnt make sense for iotop
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
Other than that looks good (except that you dont need to define the iotop_role())
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
On Wed, 2013-10-09 at 09:41 +0200, Dominick Grift wrote:
On Wed, 2013-10-09 at 08:04 +1030, William Brown wrote:
I made a 30 minute demonstration about creating policy for iotop (on rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs
Fantastic. Thanks for your combined emails. It has revealed a lot to me. I'll watch your video, and will create a similar policy for iotop on Fedora. If you don't mind, I'll post it here for review once I'm done.
sure, you can post it but if the policy looks like the one i created in my video then its ok
Well hopefully it does. I'm not aiming to copy your policy directly, as I want to learn the steps so I can write these for myself.
I have already run into one issue. I have created an iotop module and iotop_sysadm module, but once loaded I see a number of errors in ausearch like:
libsepol.sepol_context_to_sid: could not convert staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 to sid libsepol.context_from_record: invalid security context: "staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023" libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure
It says that the staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 content is invalid. So you should check whether the combination of these security identifiers is valid
you can use the seinfo , semanage and sesearch tools to determine that
to determine whether your uid/gid is associated to staff_u/s0-s0:c0.c1023:
semanage login -l |grep myadm myadm staff_u s0-s0:c0.c1023
to determine whether the staff_u sid is associated to the sysadm_r role and range of s0-s0:c0.c1023:
semanage user -l | grep staff_u staff_u user s0 s0-s0:c0.c1023 staff_r sysadm_r system_r unconfined_r
to determine whether staff_r can manually change to sysadm_r:
sesearch --role_allow | grep "allow staff_r " | grep sysadm_r allow staff_r sysadm_r;
to determine whether the sysadm_r role is associated to the iotop_t domain:
seinfo -xrsysadm_r | grep iotop iotop_t
This is the only one that's missing. The rest are all correct as your examples show.
Solved, by adding:
role iotop_roles types iotop_t;
to my te file.
to determine whether whether sysadm_t automatically domain transitions to iotop_t when he runs a file with type iotop_exec_t:
sesearch -ASCT -s sysadm_t -t iotop_exec_t | grep type_transition type_transition sysadm_t iotop_exec_t : process iotop_t;
if all the above prerequisites are met then things should probably work in the default fedora/rhel set up
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
As per the net_admin capability, removing it iotop gives this friendly spiel: Netlink error: Operation not permitted (1)
The Linux kernel interfaces that iotop relies on now require root priviliges or the NET_ADMIN capability. This change occured because a security issue (CVE-2011-2494) was found that allows leakage of sensitive data across user boundaries. If you require the ability to run iotop as a non-root user, please configure sudo to allow you to run iotop as root.
Please do not file bugs on iotop about this.
I have attached my version of the policy.
It still receives a small number of denials, that audit2allow lists here:
#============= iotop_t ============== allow iotop_t passwd_file_t:file read; allow iotop_t random_device_t:chr_file read;
#!!!! This avc can be allowed using the boolean 'global_ssp' allow iotop_t urandom_device_t:chr_file read;
But these don't prevent iotop working.
I would appreciate if you could review this policy. Thanks again for your help.
Also give the interface file some love:
## Execute TEMPLATE in the iotop domin.
This is that sepolicy script not replacing TEMPLATE with iotop
## The role to be allowed the iotop domain.
"Role allowed access"
Keep descriptions uniform and consistent
These are API's, give them love, This is how others see your policy. (they will use your API's if they need to interact with or operate on iotop and iotop objects) Try to leave a good impression
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
corecmd_exec_bin(iotop_t)
miscfiles_read_localization(iotop_t)
files_read_etc_files(iotop_t)
domain_getsched_all_domains(iotop_t) domain_read_all_domains_state(iotop_t)
kernel_read_system_state(iotop_t) kernel_rw_unix_dgram_sockets(iotop_t)
userdom_use_user_terminals(iotop_t)
Also a minor nitpick about ordering of interface calls.
generally its this order:
kernel layer interface calls in aplhanumerical order ( except with calls to the kernel module on top of them)
system layer interface calls
constrib interface calls
see:
On Thu, 2013-10-10 at 09:59 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
corecmd_exec_bin(iotop_t)
miscfiles_read_localization(iotop_t)
files_read_etc_files(iotop_t)
domain_getsched_all_domains(iotop_t) domain_read_all_domains_state(iotop_t)
kernel_read_system_state(iotop_t) kernel_rw_unix_dgram_sockets(iotop_t)
userdom_use_user_terminals(iotop_t)
Also a minor nitpick about ordering of interface calls.
generally its this order:
kernel layer interface calls in aplhanumerical order ( except with calls to the kernel module on top of them)
system layer interface calls
constrib interface calls
see:
I'll read all your points, and fix up what you have suggested. Once done, If you don't mind I'll send the policy again for your to review.
On Thu, 2013-10-10 at 18:44 +1030, William Brown wrote:
On Thu, 2013-10-10 at 09:59 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
corecmd_exec_bin(iotop_t)
miscfiles_read_localization(iotop_t)
files_read_etc_files(iotop_t)
domain_getsched_all_domains(iotop_t) domain_read_all_domains_state(iotop_t)
kernel_read_system_state(iotop_t) kernel_rw_unix_dgram_sockets(iotop_t)
userdom_use_user_terminals(iotop_t)
Also a minor nitpick about ordering of interface calls.
generally its this order:
kernel layer interface calls in aplhanumerical order ( except with calls to the kernel module on top of them)
system layer interface calls
constrib interface calls
see:
I'll read all your points, and fix up what you have suggested. Once done, If you don't mind I'll send the policy again for your to review.
Thats fine
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
you might want to give access to both console_device_t as well as user terminals if it wants to use console_device_t in your test scenario
this app can also be run non interactively in scripts so it might in that case need to be able to rw console devices
generally though this app gets executed from user pseudo terminals by users ( for example from xterm, or gnome terminal or a ssh shell and so in that case you need to allow it to use user terminals)
have a look in /dev/ to see how the different terminals are labeled
On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
you might want to give access to both console_device_t as well as user terminals if it wants to use console_device_t in your test scenario
this app can also be run non interactively in scripts so it might in that case need to be able to rw console devices
generally though this app gets executed from user pseudo terminals by users ( for example from xterm, or gnome terminal or a ssh shell and so in that case you need to allow it to use user terminals)
have a look in /dev/ to see how the different terminals are labeled
I couldn't find anything in the documentation relating to console_device_t. I tried iotop from a tty, and that worked correctly (not sure if this was meant to be the case?).
What would be the difference to the application if it were run from a script (ie iotop -b). I couldn't generate any denials with my current policy trying this .... Some more detail about the different console types (or links) would be great.
Regarding the other points:
Added the extra rules as you suggested to remove the avc's that were generated.
I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that I didn't need it. This is likely my mistake as I saw the dgram denial, and in my research found this and added it. I guess this is a lesson in adding one or two lines at a time and testing.
I have improved the interface file, adding (hopefully) better explanations.
Fixed the ordering of the interface calls.
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
I remember you doing something different with the self rules, but I don't understand what you mean by permission sets. As far as I remember, you left them just as "self" rules? Is this the "create_socket_perms" that you use? If this is the case, is there a location where these are documented / source code to these for reference? I have added some of these, and the policy works, but I would still appreciate your advice.
On Thu, 2013-10-10 at 23:32 +1030, William Brown wrote:
On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
you might want to give access to both console_device_t as well as user terminals if it wants to use console_device_t in your test scenario
this app can also be run non interactively in scripts so it might in that case need to be able to rw console devices
generally though this app gets executed from user pseudo terminals by users ( for example from xterm, or gnome terminal or a ssh shell and so in that case you need to allow it to use user terminals)
have a look in /dev/ to see how the different terminals are labeled
I couldn't find anything in the documentation relating to console_device_t. I tried iotop from a tty, and that worked correctly (not sure if this was meant to be the case?).
user tty devices are labeled user_tty_device_t, and these are covered by userdom_use_user_terminals()
console_device_t is for /dev/console
What would be the difference to the application if it were run from a script (ie iotop -b). I couldn't generate any denials with my current policy trying this .... Some more detail about the different console types (or links) would be great.
Well not sure but if for example a system process runs iotop non-interactively then there is no user terminal to use i guess, so it *may, or may not* use unallocated terminals or console_device_t
if you cannot produce it then no need to add rules for it.
there's this simple guideline i suggest for policy writers: do not assume.
Regarding the other points:
Added the extra rules as you suggested to remove the avc's that were generated.
I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that I didn't need it. This is likely my mistake as I saw the dgram denial, and in my research found this and added it. I guess this is a lesson in adding one or two lines at a time and testing.
I have improved the interface file, adding (hopefully) better explanations.
Fixed the ordering of the interface calls.
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
I remember you doing something different with the self rules, but I don't understand what you mean by permission sets. As far as I remember, you left them just as "self" rules? Is this the "create_socket_perms" that you use? If this is the case, is there a location where these are documented / source code to these for reference? I have added some of these, and the policy works, but I would still appreciate your advice.
permissions sets are indeed for example the "create_socket_perms", they are sets of permissions that are grouped into a single readable string. They provide a single point of failure
for example:
to execute a executable file you need a set of permissions. these permission are grouped identified with a human readable string:
define(`exec_file_perms',`{ getattr open read execute ioctl execute_no_trans }')
Now if you use the exec_file_perms string, whenever you want to execute a file. then you have a single point of failure in case something changes in the future wrt the permission needed execute a file.
because you only have to edit the definition, and the change will propagate.
the permission sets can be found here:
/usr/share/selinux/devel/include/support/obj_perm_sets.spt
I couldn't find anything in the documentation relating to console_device_t. I tried iotop from a tty, and that worked correctly (not sure if this was meant to be the case?).
user tty devices are labeled user_tty_device_t, and these are covered by userdom_use_user_terminals()
console_device_t is for /dev/console
Okay. I saw the tty and pty device labelling. I am personally not fully aware of the function of /dev/console and how it works on a linux system, so I think I'll dodge this for now.
Well not sure but if for example a system process runs iotop non-interactively then there is no user terminal to use i guess, so it *may, or may not* use unallocated terminals or console_device_t
if you cannot produce it then no need to add rules for it.
there's this simple guideline i suggest for policy writers: do not assume.
I didn't add the rules. That is sound advice that I will follow.
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
I remember you doing something different with the self rules, but I don't understand what you mean by permission sets. As far as I remember, you left them just as "self" rules? Is this the "create_socket_perms" that you use? If this is the case, is there a location where these are documented / source code to these for reference? I have added some of these, and the policy works, but I would still appreciate your advice.
permissions sets are indeed for example the "create_socket_perms", they are sets of permissions that are grouped into a single readable string. They provide a single point of failure
for example:
to execute a executable file you need a set of permissions. these permission are grouped identified with a human readable string:
define(`exec_file_perms',`{ getattr open read execute ioctl execute_no_trans }')
Now if you use the exec_file_perms string, whenever you want to execute a file. then you have a single point of failure in case something changes in the future wrt the permission needed execute a file.
because you only have to edit the definition, and the change will propagate.
the permission sets can be found here:
/usr/share/selinux/devel/include/support/obj_perm_sets.spt
Thanks, I'll take a look. It's mainly so that when I say "Hmm what would give me socket permissions" I can grep somewhere to find what "might" be the answer. I do certainly agree that appears to be the right way to reference such permissions.
I look forwards to your remaining comments of this policy.
On Thu, 2013-10-10 at 23:32 +1030, William Brown wrote:
On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
you might want to give access to both console_device_t as well as user terminals if it wants to use console_device_t in your test scenario
this app can also be run non interactively in scripts so it might in that case need to be able to rw console devices
generally though this app gets executed from user pseudo terminals by users ( for example from xterm, or gnome terminal or a ssh shell and so in that case you need to allow it to use user terminals)
have a look in /dev/ to see how the different terminals are labeled
I couldn't find anything in the documentation relating to console_device_t. I tried iotop from a tty, and that worked correctly (not sure if this was meant to be the case?).
What would be the difference to the application if it were run from a script (ie iotop -b). I couldn't generate any denials with my current policy trying this .... Some more detail about the different console types (or links) would be great.
Regarding the other points:
Added the extra rules as you suggested to remove the avc's that were generated.
I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that I didn't need it. This is likely my mistake as I saw the dgram denial, and in my research found this and added it. I guess this is a lesson in adding one or two lines at a time and testing.
I have improved the interface file, adding (hopefully) better explanations.
Fixed the ordering of the interface calls.
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
I remember you doing something different with the self rules, but I don't understand what you mean by permission sets. As far as I remember, you left them just as "self" rules? Is this the "create_socket_perms" that you use? If this is the case, is there a location where these are documented / source code to these for reference? I have added some of these, and the policy works, but I would still appreciate your advice.
comments:
sssd_read_public_files(iotop_t) needs to be wrapped in optional_policy(`') since the sssd policy module, and functionality is optional. we dont want this module to depends on the sssd module
You can remove the iotop_role(): its pretty useless.
you will probably want to allow the iotop_t domain dac_override , since it will probably often be run from a unpriv user home directory rather than /root
i am unclear as to why "files_read_etc_files(iotop_t)" is needed. does it read /etc/nsswitch.conf?
allow iotop_t self:netlink_route_socket create_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; <-- duplicate allow iotop_t self:netlink_socket rw_socket_perms; <-- duplicate allow iotop_t self:unix_dgram_socket rw_socket_perms;
i would probably used this instead:
allow iotop_t self:netlink_route_socket r_netlink_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; allow iotop_t self:unix_dgram_socket create_socket_perms;
On Thu, 2013-10-10 at 15:47 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 23:32 +1030, William Brown wrote:
On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
you might want to give access to both console_device_t as well as user terminals if it wants to use console_device_t in your test scenario
this app can also be run non interactively in scripts so it might in that case need to be able to rw console devices
generally though this app gets executed from user pseudo terminals by users ( for example from xterm, or gnome terminal or a ssh shell and so in that case you need to allow it to use user terminals)
have a look in /dev/ to see how the different terminals are labeled
I couldn't find anything in the documentation relating to console_device_t. I tried iotop from a tty, and that worked correctly (not sure if this was meant to be the case?).
What would be the difference to the application if it were run from a script (ie iotop -b). I couldn't generate any denials with my current policy trying this .... Some more detail about the different console types (or links) would be great.
Regarding the other points:
Added the extra rules as you suggested to remove the avc's that were generated.
I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that I didn't need it. This is likely my mistake as I saw the dgram denial, and in my research found this and added it. I guess this is a lesson in adding one or two lines at a time and testing.
I have improved the interface file, adding (hopefully) better explanations.
Fixed the ordering of the interface calls.
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
I remember you doing something different with the self rules, but I don't understand what you mean by permission sets. As far as I remember, you left them just as "self" rules? Is this the "create_socket_perms" that you use? If this is the case, is there a location where these are documented / source code to these for reference? I have added some of these, and the policy works, but I would still appreciate your advice.
comments:
sssd_read_public_files(iotop_t) needs to be wrapped in optional_policy(`') since the sssd policy module, and functionality is optional. we dont want this module to depends on the sssd module
Done.
You can remove the iotop_role(): its pretty useless.
Do you mean this line?
role iotop_roles types iotop_t;
you will probably want to allow the iotop_t domain dac_override , since it will probably often be run from a unpriv user home directory rather than /root
i am unclear as to why "files_read_etc_files(iotop_t)" is needed. does it read /etc/nsswitch.conf?
I thought it did, but I have removed the line and it worked with no denial. I think the trap I fell into was that I tried the application in permissive mode without a complete set of rules, then I received other denials as a result, to which I added rules I didn't need.
allow iotop_t self:netlink_route_socket create_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; <-- duplicate allow iotop_t self:netlink_socket rw_socket_perms; <-- duplicate allow iotop_t self:unix_dgram_socket rw_socket_perms;
i would probably used this instead:
allow iotop_t self:netlink_route_socket r_netlink_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; allow iotop_t self:unix_dgram_socket create_socket_perms;
I have setup my policy to match this, but I think I'll need to read the differences in what those socket_perms options do before I understand it completely. I'll use the reference you previously gave.
o and i think you forgot to add dev_read_rand(iotop_t)
It needed urandom, which is added (And it doesn't generate a denial, so I won't add it)
Attached again.
On Fri, 2013-10-11 at 00:28 +1030, William Brown wrote:
On Thu, 2013-10-10 at 15:47 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 23:32 +1030, William Brown wrote:
On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
you might want to give access to both console_device_t as well as user terminals if it wants to use console_device_t in your test scenario
this app can also be run non interactively in scripts so it might in that case need to be able to rw console devices
generally though this app gets executed from user pseudo terminals by users ( for example from xterm, or gnome terminal or a ssh shell and so in that case you need to allow it to use user terminals)
have a look in /dev/ to see how the different terminals are labeled
I couldn't find anything in the documentation relating to console_device_t. I tried iotop from a tty, and that worked correctly (not sure if this was meant to be the case?).
What would be the difference to the application if it were run from a script (ie iotop -b). I couldn't generate any denials with my current policy trying this .... Some more detail about the different console types (or links) would be great.
Regarding the other points:
Added the extra rules as you suggested to remove the avc's that were generated.
I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that I didn't need it. This is likely my mistake as I saw the dgram denial, and in my research found this and added it. I guess this is a lesson in adding one or two lines at a time and testing.
I have improved the interface file, adding (hopefully) better explanations.
Fixed the ordering of the interface calls.
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
I remember you doing something different with the self rules, but I don't understand what you mean by permission sets. As far as I remember, you left them just as "self" rules? Is this the "create_socket_perms" that you use? If this is the case, is there a location where these are documented / source code to these for reference? I have added some of these, and the policy works, but I would still appreciate your advice.
comments:
sssd_read_public_files(iotop_t) needs to be wrapped in optional_policy(`') since the sssd policy module, and functionality is optional. we dont want this module to depends on the sssd module
Done.
You can remove the iotop_role(): its pretty useless.
Do you mean this line?
role iotop_roles types iotop_t;
no i mean this ( from the iotop.if file ):
######################################## ## <summary> ## Role allowed to access and manage processes in the iotop domain. ## </summary> ## <param name="role"> ## <summary> ## Role allowed access to iotop ## </summary> ## </param> ## <param name="domain"> ## <summary> ## User domain for the role ## </summary> ## </param> # interface(`iotop_role',` gen_require(` type iotop_t; attribute_role iotop_roles; ')
roleattribute $1 iotop_roles;
iotop_domtrans($2)
ps_process_pattern($2, iotop_t) allow $2 iotop_t:process { signull signal sigkill }; ')
you will probably want to allow the iotop_t domain dac_override , since it will probably often be run from a unpriv user home directory rather than /root
i am unclear as to why "files_read_etc_files(iotop_t)" is needed. does it read /etc/nsswitch.conf?
I thought it did, but I have removed the line and it worked with no denial. I think the trap I fell into was that I tried the application in permissive mode without a complete set of rules, then I received other denials as a result, to which I added rules I didn't need.
allow iotop_t self:netlink_route_socket create_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; <-- duplicate allow iotop_t self:netlink_socket rw_socket_perms; <-- duplicate allow iotop_t self:unix_dgram_socket rw_socket_perms;
i would probably used this instead:
allow iotop_t self:netlink_route_socket r_netlink_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; allow iotop_t self:unix_dgram_socket create_socket_perms;
I have setup my policy to match this, but I think I'll need to read the differences in what those socket_perms options do before I understand it completely. I'll use the reference you previously gave.
o and i think you forgot to add dev_read_rand(iotop_t)
It needed urandom, which is added (And it doesn't generate a denial, so I won't add it)
ok, earlier you showed me this, but yes f you cannot reproduce then ignore it for now:
allow iotop_t random_device_t:chr_file read;
Attached again.
You can remove the iotop_role(): its pretty useless.
Do you mean this line?
role iotop_roles types iotop_t;
no i mean this ( from the iotop.if file ):
######################################## ## <summary> ## Role allowed to access and manage processes in the iotop domain. ## </summary> ## <param name="role"> ## <summary> ## Role allowed access to iotop ## </summary> ## </param> ## <param name="domain"> ## <summary> ## User domain for the role ## </summary> ## </param> # interface(`iotop_role',` gen_require(` type iotop_t; attribute_role iotop_roles; ')
roleattribute $1 iotop_roles; iotop_domtrans($2) ps_process_pattern($2, iotop_t) allow $2 iotop_t:process { signull signal sigkill };
')
OHHHH I see. I have removed it now.
ok, earlier you showed me this, but yes f you cannot reproduce then ignore it for now:
allow iotop_t random_device_t:chr_file read;
Yep. Perhaps another one of my mistakes from my permissive / not permissive issue? Anyway, I tested that I certainly need the urandom rule by removing it to see if I get avc's : Which I do, so I have left it in the te.
On Fri, 2013-10-11 at 00:28 +1030, William Brown wrote:
On Thu, 2013-10-10 at 15:47 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 23:32 +1030, William Brown wrote:
On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
you might want to give access to both console_device_t as well as user terminals if it wants to use console_device_t in your test scenario
this app can also be run non interactively in scripts so it might in that case need to be able to rw console devices
generally though this app gets executed from user pseudo terminals by users ( for example from xterm, or gnome terminal or a ssh shell and so in that case you need to allow it to use user terminals)
have a look in /dev/ to see how the different terminals are labeled
I couldn't find anything in the documentation relating to console_device_t. I tried iotop from a tty, and that worked correctly (not sure if this was meant to be the case?).
What would be the difference to the application if it were run from a script (ie iotop -b). I couldn't generate any denials with my current policy trying this .... Some more detail about the different console types (or links) would be great.
Regarding the other points:
Added the extra rules as you suggested to remove the avc's that were generated.
I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that I didn't need it. This is likely my mistake as I saw the dgram denial, and in my research found this and added it. I guess this is a lesson in adding one or two lines at a time and testing.
I have improved the interface file, adding (hopefully) better explanations.
Fixed the ordering of the interface calls.
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
I remember you doing something different with the self rules, but I don't understand what you mean by permission sets. As far as I remember, you left them just as "self" rules? Is this the "create_socket_perms" that you use? If this is the case, is there a location where these are documented / source code to these for reference? I have added some of these, and the policy works, but I would still appreciate your advice.
comments:
sssd_read_public_files(iotop_t) needs to be wrapped in optional_policy(`') since the sssd policy module, and functionality is optional. we dont want this module to depends on the sssd module
Done.
You can remove the iotop_role(): its pretty useless.
Do you mean this line?
role iotop_roles types iotop_t;
you will probably want to allow the iotop_t domain dac_override , since it will probably often be run from a unpriv user home directory rather than /root
i am unclear as to why "files_read_etc_files(iotop_t)" is needed. does it read /etc/nsswitch.conf?
I thought it did, but I have removed the line and it worked with no denial. I think the trap I fell into was that I tried the application in permissive mode without a complete set of rules, then I received other denials as a result, to which I added rules I didn't need.
allow iotop_t self:netlink_route_socket create_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; <-- duplicate allow iotop_t self:netlink_socket rw_socket_perms; <-- duplicate allow iotop_t self:unix_dgram_socket rw_socket_perms;
i would probably used this instead:
allow iotop_t self:netlink_route_socket r_netlink_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; allow iotop_t self:unix_dgram_socket create_socket_perms;
I have setup my policy to match this, but I think I'll need to read the differences in what those socket_perms options do before I understand it completely. I'll use the reference you previously gave.
o and i think you forgot to add dev_read_rand(iotop_t)
It needed urandom, which is added (And it doesn't generate a denial, so I won't add it)
Attached again.
Ok now it looks ok. Although i still suspect it needs dac_override capability ( it needed it when i used it ) sooner or later. but we will see.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 09:58 AM, William Brown wrote:
On Thu, 2013-10-10 at 15:47 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 23:32 +1030, William Brown wrote:
On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
you might want to give access to both console_device_t as well as user terminals if it wants to use console_device_t in your test scenario
this app can also be run non interactively in scripts so it might in that case need to be able to rw console devices
generally though this app gets executed from user pseudo terminals by users ( for example from xterm, or gnome terminal or a ssh shell and so in that case you need to allow it to use user terminals)
have a look in /dev/ to see how the different terminals are labeled
I couldn't find anything in the documentation relating to console_device_t. I tried iotop from a tty, and that worked correctly (not sure if this was meant to be the case?).
What would be the difference to the application if it were run from a script (ie iotop -b). I couldn't generate any denials with my current policy trying this .... Some more detail about the different console types (or links) would be great.
Regarding the other points:
Added the extra rules as you suggested to remove the avc's that were generated.
I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that I didn't need it. This is likely my mistake as I saw the dgram denial, and in my research found this and added it. I guess this is a lesson in adding one or two lines at a time and testing.
I have improved the interface file, adding (hopefully) better explanations.
Fixed the ordering of the interface calls.
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
I remember you doing something different with the self rules, but I don't understand what you mean by permission sets. As far as I remember, you left them just as "self" rules? Is this the "create_socket_perms" that you use? If this is the case, is there a location where these are documented / source code to these for reference? I have added some of these, and the policy works, but I would still appreciate your advice.
comments:
sssd_read_public_files(iotop_t) needs to be wrapped in optional_policy(`') since the sssd policy module, and functionality is optional. we dont want this module to depends on the sssd module
Done.
You can remove the iotop_role(): its pretty useless.
Do you mean this line?
role iotop_roles types iotop_t;
you will probably want to allow the iotop_t domain dac_override , since it will probably often be run from a unpriv user home directory rather than /root
i am unclear as to why "files_read_etc_files(iotop_t)" is needed. does it read /etc/nsswitch.conf?
I thought it did, but I have removed the line and it worked with no denial. I think the trap I fell into was that I tried the application in permissive mode without a complete set of rules, then I received other denials as a result, to which I added rules I didn't need.
allow iotop_t self:netlink_route_socket create_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; <-- duplicate allow iotop_t self:netlink_socket rw_socket_perms; <-- duplicate allow iotop_t self:unix_dgram_socket rw_socket_perms;
i would probably used this instead:
allow iotop_t self:netlink_route_socket r_netlink_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; allow iotop_t self:unix_dgram_socket create_socket_perms;
I have setup my policy to match this, but I think I'll need to read the differences in what those socket_perms options do before I understand it completely. I'll use the reference you previously gave.
o and i think you forgot to add dev_read_rand(iotop_t)
It needed urandom, which is added (And it doesn't generate a denial, so I won't add it)
Attached again.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Me thinks you need auth_use_nsswitch() Looks like your code is calling getpw() Which is causing some of these access. auth_use_nsswitch will make you handle all forms of authorization.
On Thu, 2013-10-10 at 10:28 -0400, Daniel J Walsh wrote:
On 10/10/2013 09:58 AM, William Brown wrote:
On Thu, 2013-10-10 at 15:47 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 23:32 +1030, William Brown wrote:
On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
you might want to give access to both console_device_t as well as user terminals if it wants to use console_device_t in your test scenario
this app can also be run non interactively in scripts so it might in that case need to be able to rw console devices
generally though this app gets executed from user pseudo terminals by users ( for example from xterm, or gnome terminal or a ssh shell and so in that case you need to allow it to use user terminals)
have a look in /dev/ to see how the different terminals are labeled
I couldn't find anything in the documentation relating to console_device_t. I tried iotop from a tty, and that worked correctly (not sure if this was meant to be the case?).
What would be the difference to the application if it were run from a script (ie iotop -b). I couldn't generate any denials with my current policy trying this .... Some more detail about the different console types (or links) would be great.
Regarding the other points:
Added the extra rules as you suggested to remove the avc's that were generated.
I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that I didn't need it. This is likely my mistake as I saw the dgram denial, and in my research found this and added it. I guess this is a lesson in adding one or two lines at a time and testing.
I have improved the interface file, adding (hopefully) better explanations.
Fixed the ordering of the interface calls.
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
I remember you doing something different with the self rules, but I don't understand what you mean by permission sets. As far as I remember, you left them just as "self" rules? Is this the "create_socket_perms" that you use? If this is the case, is there a location where these are documented / source code to these for reference? I have added some of these, and the policy works, but I would still appreciate your advice.
comments:
sssd_read_public_files(iotop_t) needs to be wrapped in optional_policy(`') since the sssd policy module, and functionality is optional. we dont want this module to depends on the sssd module
Done.
You can remove the iotop_role(): its pretty useless.
Do you mean this line?
role iotop_roles types iotop_t;
you will probably want to allow the iotop_t domain dac_override , since it will probably often be run from a unpriv user home directory rather than /root
i am unclear as to why "files_read_etc_files(iotop_t)" is needed. does it read /etc/nsswitch.conf?
I thought it did, but I have removed the line and it worked with no denial. I think the trap I fell into was that I tried the application in permissive mode without a complete set of rules, then I received other denials as a result, to which I added rules I didn't need.
allow iotop_t self:netlink_route_socket create_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; <-- duplicate allow iotop_t self:netlink_socket rw_socket_perms; <-- duplicate allow iotop_t self:unix_dgram_socket rw_socket_perms;
i would probably used this instead:
allow iotop_t self:netlink_route_socket r_netlink_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; allow iotop_t self:unix_dgram_socket create_socket_perms;
I have setup my policy to match this, but I think I'll need to read the differences in what those socket_perms options do before I understand it completely. I'll use the reference you previously gave.
o and i think you forgot to add dev_read_rand(iotop_t)
It needed urandom, which is added (And it doesn't generate a denial, so I won't add it)
Attached again.
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Me thinks you need auth_use_nsswitch() Looks like your code is calling getpw() Which is causing some of these access. auth_use_nsswitch will make you handle all forms of authorization.
yes, but
It doesnt need any authentication though, and also many other hallmarks of nsswitch are not there for example reading network config or do dns resolving, or creating tcp/udp sockets
not sure why it needs to create netlink route sockets ( i am assuming that in some scenario it might need to read the routing table, but against my own advise i made assumptions
this actually a really simple app, the only thing that i wonder about are the details about the net_admin and netlink_route_socket. I thought it might have been for iscsi scenarios but thats just assumption
Me thinks you need auth_use_nsswitch() Looks like your code is calling getpw() Which is causing some of these access. auth_use_nsswitch will make you handle all forms of authorization.
yes, but
It doesnt need any authentication though, and also many other hallmarks of nsswitch are not there for example reading network config or do dns resolving, or creating tcp/udp sockets
I believe it's for resolving the UID/GID to usernames/group names in the display. Either way, I have taken your advice, and replaced the passwd / sssd parts with this and it works correctly.
not sure why it needs to create netlink route sockets ( i am assuming that in some scenario it might need to read the routing table, but against my own advise i made assumptions
this actually a really simple app, the only thing that i wonder about are the details about the net_admin and netlink_route_socket. I thought it might have been for iscsi scenarios but thats just assumption
Again, this may have been one of my mistakes. I have removed that line and it still worked. To eliminate this, I went through and check that each line of the policy now when removed causes a denial, which it does. Here is the "minimised" policy.
On Thu, 2013-10-10 at 23:32 +1030, William Brown wrote:
On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote:
On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote:
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
you might want to give access to both console_device_t as well as user terminals if it wants to use console_device_t in your test scenario
this app can also be run non interactively in scripts so it might in that case need to be able to rw console devices
generally though this app gets executed from user pseudo terminals by users ( for example from xterm, or gnome terminal or a ssh shell and so in that case you need to allow it to use user terminals)
have a look in /dev/ to see how the different terminals are labeled
I couldn't find anything in the documentation relating to console_device_t. I tried iotop from a tty, and that worked correctly (not sure if this was meant to be the case?).
What would be the difference to the application if it were run from a script (ie iotop -b). I couldn't generate any denials with my current policy trying this .... Some more detail about the different console types (or links) would be great.
Regarding the other points:
Added the extra rules as you suggested to remove the avc's that were generated.
I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that I didn't need it. This is likely my mistake as I saw the dgram denial, and in my research found this and added it. I guess this is a lesson in adding one or two lines at a time and testing.
I have improved the interface file, adding (hopefully) better explanations.
Fixed the ordering of the interface calls.
You should use permission sets for the "self" rules to provide a single point of failure ( see my video )
I remember you doing something different with the self rules, but I don't understand what you mean by permission sets. As far as I remember, you left them just as "self" rules? Is this the "create_socket_perms" that you use? If this is the case, is there a location where these are documented / source code to these for reference? I have added some of these, and the policy works, but I would still appreciate your advice.
o and i think you forgot to add dev_read_rand(iotop_t)
selinux@lists.fedoraproject.org