On my FC4 system, I created a file /etc/selinux/targeted/contexts/files/file_contexts.local that contained the following lines:
/srv/backup(/.*)? system_u:object_r:ftpd_anon_rw_t /srv/softlib(/.*)? system_u:object_r:ftpd_anon_rw_t
This was to ensure that that files created in these areas got the right context, and that it would survive a relabel. Having since learned about customizable types, I probably didn't need to do that in this case, but the principle applies anyway.
My understanding is that in FC5, the equivalent thing to do for this would be to use semanage to add additional fcontext objects. Is that right (I think the semanage manpage could do with an example or two btw, hint, hint)?
My first question is: if I use semanage, is there a convenient way to check, on a running system, which objects are there as part of the base policy and which have been added later, like a file context equivalent of "semodule -l"?
My second question is: I have lots of log messages like this:
Mar 26 04:24:39 badby kernel: inode_doinit_with_dentry: context_to_sid(system_u:object_r:ftpd_anon_rw_t) returned 22 for dev=sdb6 ino=96769
Google suggests that this is a hangover from FC4 that shouldn't be there, and I suspect is has to do with the presence of my /etc/selinux/targeted/contexts/files/file_contexts.local file. I'm thinking of changing this to:
/srv/backup(/.*)? system_u:object_r:public_content_rw_t:s0 /srv/softlib(/.*)? system_u:object_r:public_content_rw_t:s0
or even deleting it entirely and doing the equivalent with semanage. When I do one of these things, when will it take effect? Will I need to reboot, or rebuild policy somehow?
Paul.
On Wed, 2006-03-29 at 13:39 +0100, Paul Howarth wrote:
On my FC4 system, I created a file /etc/selinux/targeted/contexts/files/file_contexts.local that contained the following lines:
/srv/backup(/.*)? system_u:object_r:ftpd_anon_rw_t /srv/softlib(/.*)? system_u:object_r:ftpd_anon_rw_t
This was to ensure that that files created in these areas got the right context, and that it would survive a relabel. Having since learned about customizable types, I probably didn't need to do that in this case, but the principle applies anyway.
My understanding is that in FC5, the equivalent thing to do for this would be to use semanage to add additional fcontext objects. Is that right (I think the semanage manpage could do with an example or two btw, hint, hint)?
Funny you should ask. See http://marc.theaimsgroup.com/?l=selinux&m=114358806507499&w=2
My first question is: if I use semanage, is there a convenient way to check, on a running system, which objects are there as part of the base policy and which have been added later, like a file context equivalent of "semodule -l"?
Hmm...doesn't look like semanage presently has an option that invokes just the xxx_list_local() interface of libsemanage versus the xxx_list() interface. Seems like a good idea.
My second question is: I have lots of log messages like this:
Mar 26 04:24:39 badby kernel: inode_doinit_with_dentry: context_to_sid(system_u:object_r:ftpd_anon_rw_t) returned 22 for dev=sdb6 ino=96769
Suggests that the type is no longer defined, which seems a bit surprising. Usually we add a type alias to keep it valid across updates.
/srv/backup(/.*)? system_u:object_r:public_content_rw_t:s0 /srv/softlib(/.*)? system_u:object_r:public_content_rw_t:s0
or even deleting it entirely and doing the equivalent with semanage. When I do one of these things, when will it take effect? Will I need to reboot, or rebuild policy somehow?
file_contexts.local will still be read by libselinux (matchpathcon), so it can still be used, but using semanage is likely the better way forward. Once you've run the semanage command, it should rebuild and push out an updated file_contexts file with your additions included, and then any subsequent runs of restorecon/setfiles/... will make use of those definitions.
Stephen Smalley wrote:
On Wed, 2006-03-29 at 13:39 +0100, Paul Howarth wrote:
On my FC4 system, I created a file /etc/selinux/targeted/contexts/files/file_contexts.local that contained the following lines:
/srv/backup(/.*)? system_u:object_r:ftpd_anon_rw_t /srv/softlib(/.*)? system_u:object_r:ftpd_anon_rw_t
This was to ensure that that files created in these areas got the right context, and that it would survive a relabel. Having since learned about customizable types, I probably didn't need to do that in this case, but the principle applies anyway.
My understanding is that in FC5, the equivalent thing to do for this would be to use semanage to add additional fcontext objects. Is that right (I think the semanage manpage could do with an example or two btw, hint, hint)?
Funny you should ask. See http://marc.theaimsgroup.com/?l=selinux&m=114358806507499&w=2
Ah, good :-)
My first question is: if I use semanage, is there a convenient way to check, on a running system, which objects are there as part of the base policy and which have been added later, like a file context equivalent of "semodule -l"?
Hmm...doesn't look like semanage presently has an option that invokes just the xxx_list_local() interface of libsemanage versus the xxx_list() interface. Seems like a good idea.
My second question is: I have lots of log messages like this:
Mar 26 04:24:39 badby kernel: inode_doinit_with_dentry: context_to_sid(system_u:object_r:ftpd_anon_rw_t) returned 22 for dev=sdb6 ino=96769
Suggests that the type is no longer defined, which seems a bit surprising. Usually we add a type alias to keep it valid across updates.
/srv/backup(/.*)? system_u:object_r:public_content_rw_t:s0 /srv/softlib(/.*)? system_u:object_r:public_content_rw_t:s0
or even deleting it entirely and doing the equivalent with semanage. When I do one of these things, when will it take effect? Will I need to reboot, or rebuild policy somehow?
file_contexts.local will still be read by libselinux (matchpathcon), so it can still be used, but using semanage is likely the better way forward. Once you've run the semanage command, it should rebuild and push out an updated file_contexts file with your additions included, and then any subsequent runs of restorecon/setfiles/... will make use of those definitions.
Right, I moved the existing /etc/selinux/targeted/contexts/files/file_contexts.local out of the way and did:
# semanage fcontext -a -t public_content_rw_t '/srv/backup(/.*)?' # semanage fcontext -a -t public_content_rw_t '/srv/softlib(/.*)?'
This then created a new /etc/selinux/targeted/contexts/files/file_contexts.local, which contained:
# This file is auto-generated by libsemanage # Please use the semanage command to make changes
/srv/backup(/.*)? system_u:object_r:public_content_rw_t:s0 /srv/softlib(/.*)? system_u:object_r:public_content_rw_t:s0
So it seems that I can identify local changes by looking in the file (pretty much as before really, except that the file is created using semanage rather than vi).
One last thing: is it possible to add multiple objects in a single semanage call? I ask because each one takes a while to run (to do the rebuild), and I can imagine that in an RPM package where there might be lots of calls to semanage being made in a %post scriptlet, it would be better to add all the objects at once and only do a single rebuild.
Paul.
So it seems that I can identify local changes by looking in the file (pretty much as before really, except that the file is created using semanage rather than vi).
Right... the idea behind semanage is that it should support multiple backends. Right now it supports flat file, policy object representation (via libsepol), and selinuxfs for booleans (via libselinux). In the future we want to support more backends, such as LDAP, and a policy management server being developed by Tresys. This server should allow more fine-grained access controls over policy modifications than we currently have with the flat file. Also, it should move towards distributed management over a network.
So, while the representation is the same right now, it may not stay that way in the future. We'll likely make the store readable only by semanage utilities in enforcing mode.
One last thing: is it possible to add multiple objects in a single semanage call?
I don't think the python frontend supports it, but the backend library certainly does - it's transactional, and only the commit takes a long time. It seems like this would be useful to people - Dan?
I ask because each one takes a while to run (to do the rebuild), and I can imagine that in an RPM package where there might be lots of calls to semanage being made in a %post scriptlet, it would be better to add all the objects at once and only do a single rebuild.
Not sure of the status of rpm integration w/ modules, Dan would be the person to ask... Rpm would have to make use of the transactional mechanism, not only because of speed, but because inter-module dependencies get resolved that way [ speaking of which, do policy module dependencies match rpm dependencies? ].
I ask because each one takes a while to run (to do the rebuild),
By the way, in the case of contexts, the rebuild is completely avoidable. With some code reorganization, it's easy to optimize this out. Maybe I'll take a look after more important issues are dealt with...
--> /* FIXME: get rid of these, once we support loading the existing policy, * instead of rebuilding it */ modified |= seusers_modified; modified |= fcontexts_modified; modified |= users_extra_modified;
On Wed, 2006-03-29 at 09:47 -0500, Ivan Gyurdiev wrote:
One last thing: is it possible to add multiple objects in a single semanage call?
I don't think the python frontend supports it, but the backend library certainly does - it's transactional, and only the commit takes a long time. It seems like this would be useful to people - Dan?
Not sure what the user interface would look like. semodule already supports multiple operations on a single command line, e.g. semodule -b base.pp -i a.pp -i b.pp but semanage syntax is a bit more complicated.
Are we talking about just adding multiple objects of the same type in a single command, e.g. collapsing semanage port -a -t http_port_t -p tcp 81 semanage port -a -t http_cache_port_t -p tcp 8081 to something like: semanage port -a -t http_port_t -p tcp 81 -a -t http_cache_port_t -p tcp 8080
Or dealing with arbitrary combinations, e.g. collapsing semanage port -a -t http_port_t -p tcp 81 semanage fcontext -a -t httpd_sys_content_t '/web(/.*)?' to some single command line?
Stephen Smalley wrote:
On Wed, 2006-03-29 at 09:47 -0500, Ivan Gyurdiev wrote:
One last thing: is it possible to add multiple objects in a single semanage call?
I don't think the python frontend supports it, but the backend library certainly does - it's transactional, and only the commit takes a long time. It seems like this would be useful to people - Dan?
Not sure what the user interface would look like. semodule already supports multiple operations on a single command line, e.g. semodule -b base.pp -i a.pp -i b.pp but semanage syntax is a bit more complicated.
Are we talking about just adding multiple objects of the same type in a single command, e.g. collapsing semanage port -a -t http_port_t -p tcp 81 semanage port -a -t http_cache_port_t -p tcp 8081 to something like: semanage port -a -t http_port_t -p tcp 81 -a -t http_cache_port_t -p tcp 8080
Or dealing with arbitrary combinations, e.g. collapsing semanage port -a -t http_port_t -p tcp 81 semanage fcontext -a -t httpd_sys_content_t '/web(/.*)?' to some single command line?
That would result in a very complex command-line parser and be difficult for users as well as developers. It could get even worse, such as wanting to combine add and modify operations.
An alternative approach might be to provide an option to skip the policy rebuild. That way you could do a string of semanage commands and use the "skip rebuild" option on all but the last of them.
Paul.
selinux@lists.fedoraproject.org
-
Ivan Gyurdiev -
Paul Howarth -
Stephen Smalley