What's the proper way to upgrade the selinux policy?
yum and rpm leave me with .rpmnew files every single time. I assume I'm supposed to manually overwrite the old ones. Is that so?
warning: /etc/selinux/strict/contexts/files/file_contexts created as / etc/selinux/strict/contexts/files/file_contexts.rpmnew selinux-policy-strict 39 % done warning: /etc/selinux/strict/policy/ policy.17 created as /etc/selinux/strict/policy/policy.17.rpmnew selinux-policy-strict 100 % done 30/144 warning: /etc/selinux/targeted/contexts/files/file_contexts created as / etc/selinux/targeted/contexts/files/file_contexts.rpmnew selinux-policy-targeted 100 % done 31/144
Do I need to run make relabel?
On Thu, 2004-06-24 at 16:21, Ivan Gyurdiev wrote:
What's the proper way to upgrade the selinux policy?
yum and rpm leave me with .rpmnew files every single time.
This suggests that you installed the policy source package as well, or locally modified your policy directly. If you install or update the policy source package (selinux-policy-strict-sources), then it should rebuild the policy files from source and load the new ones automatically as part of the %post. Updating the policy package (selinux-policy-strict) will then leave you with .rpmnew files because it sees that the files have been locally rebuilt.
I assume I'm supposed to manually overwrite the old ones. Is that so?
Or update policy sources to get them regenerated.
Do I need to run make relabel?
It is generally safest to do so, but often unnecessary (only if there is a relevant change to file_contexts that affects you). Relabeling is not presently automatically performed upon a policy update.
On Thu, 2004-06-24 at 16:45 -0400, Stephen Smalley wrote:
On Thu, 2004-06-24 at 16:21, Ivan Gyurdiev wrote:
What's the proper way to upgrade the selinux policy?
yum and rpm leave me with .rpmnew files every single time.
This suggests that you installed the policy source package as well, or locally modified your policy directly. If you install or update the policy source package (selinux-policy-strict-sources), then it should rebuild the policy files from source and load the new ones automatically as part of the %post. Updating the policy package (selinux-policy-strict) will then leave you with .rpmnew files because it sees that the files have been locally rebuilt.
Yes, I have the sources package instaled - I need it to make relabel don't I? Since I upgrade through yum, and rawhide updates the sources package with the other one, I always update them together. However, the resulting files are not the same - file_contexts and file_contexts. rpmnew are different, and the binary policy differs too.
Do I need to run make relabel?
It is generally safest to do so, but often unnecessary (only if there is a relevant change to file_contexts that affects you). Relabeling is not presently automatically performed upon a policy update.
Are there plans to change that?
Ivan Gyurdiev wrote:
On Thu, 2004-06-24 at 16:45 -0400, Stephen Smalley wrote:
On Thu, 2004-06-24 at 16:21, Ivan Gyurdiev wrote:
What's the proper way to upgrade the selinux policy?
yum and rpm leave me with .rpmnew files every single time.
This suggests that you installed the policy source package as well, or locally modified your policy directly. If you install or update the policy source package (selinux-policy-strict-sources), then it should rebuild the policy files from source and load the new ones automatically as part of the %post. Updating the policy package (selinux-policy-strict) will then leave you with .rpmnew files because it sees that the files have been locally rebuilt.
Yes, I have the sources package instaled - I need it to make relabel don't I? Since I upgrade through yum, and rawhide updates the sources package with the other one, I always update them together. However, the resulting files are not the same - file_contexts and file_contexts. rpmnew are different, and the binary policy differs too.
Do I need to run make relabel?
It is generally safest to do so, but often unnecessary (only if there is a relevant change to file_contexts that affects you). Relabeling is not presently automatically performed upon a policy update.
Are there plans to change that?
No because this could be a very long process. We are hoping to not change policy very often and less often change File Contexts. Especially with Targeted policy. I have modified fixfiles to be able to use RPM files as input and we are looking into a cron script to walk the file system on a regular basis to inform users of problems in the file context. This script could either repair the problems automatically (Not recommended), or easily allow the administrator to fix them the next morning.
Setfiles and restorecon have a new qualifier (-o filename) which will record the file paths of any files that the tools find with the incorrect security context. So if you run setfiles -n -v -o /tmp/badfilecontexts, you would have a report and a file with all the paths of files with bad file contexts. If everything looks ok, you could run restorecon -f /tmp/badfilecontexts and clean them up quickly.
Dan
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
What's the proper way to upgrade the selinux policy?
yum and rpm leave me with .rpmnew files every single time.
This suggests that you installed the policy source package as well, or locally modified your policy directly. If you install or update the policy source package (selinux-policy-strict-sources), then it should rebuild the policy files from source and load the new ones automatically as part of the %post. Updating the policy package (selinux-policy-strict) will then leave you with .rpmnew files because it sees that the files have been locally rebuilt.
Let me nail this down for my own benefit; maybe I am dense. If you install the policy source package you should refrain from also installing the policy package?
So is it one or the other, but not both?
On Fri, 2004-06-25 at 06:38, Thomas Molina wrote:
Let me nail this down for my own benefit; maybe I am dense. If you install the policy source package you should refrain from also installing the policy package?
So is it one or the other, but not both?
At present, policy-sources requires policy. Dan, is there a reason for that requires? Otherwise, I would say yes. It doesn't hurt to have policy installed as well, but it seems pointless, as updates of policy won't touch the locally rebuilt files created by the policy sources install/update.
Stephen Smalley wrote:
On Fri, 2004-06-25 at 06:38, Thomas Molina wrote:
Let me nail this down for my own benefit; maybe I am dense. If you install the policy source package you should refrain from also installing the policy package?
So is it one or the other, but not both?
At present, policy-sources requires policy. Dan, is there a reason for that requires? Otherwise, I would say yes. It doesn't hurt to have policy installed as well, but it seems pointless, as updates of policy won't touch the locally rebuilt files created by the policy sources install/update.
policy-sources does not include the contexts files. So you always need policy installed. Policy-sources only replaces policy.## and file_contexts file.
On Sat, 2004-06-26 at 06:35, Daniel J Walsh wrote:
policy-sources does not include the contexts files. So you always need policy installed. Policy-sources only replaces policy.## and file_contexts file.
Wouldn't it be straightforward to change the policy-sources %post to do a 'make install load' instead of just 'make load', so that the appconfig files are also installed by it? In which case, you wouldn't need policy at all anymore?
Thomas Molina wrote:
What's the proper way to upgrade the selinux policy?
yum and rpm leave me with .rpmnew files every single time.
This suggests that you installed the policy source package as well, or locally modified your policy directly. If you install or update the policy source package (selinux-policy-strict-sources), then it should rebuild the policy files from source and load the new ones automatically as part of the %post. Updating the policy package (selinux-policy-strict) will then leave you with .rpmnew files because it sees that the files have been locally rebuilt.
Let me nail this down for my own benefit; maybe I am dense. If you install the policy source package you should refrain from also installing the policy package?
So is it one or the other, but not both?
No policy-sources contains files that can be used to rebuild the policy (policy.18) file. It also contains sources to rebuild file_contexts file. Other files in policy (default_contexts, initrc_context ...) are not part of policy-sources. So policy-sources gives you the ability to modify some of the files in the policy package.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Let me nail this down for my own benefit; maybe I am dense. If you install the policy source package you should refrain from also installing the policy package?
So is it one or the other, but not both?
No policy-sources contains files that can be used to rebuild the policy (policy.18) file. It also contains sources to rebuild file_contexts file. Other files in policy (default_contexts, initrc_context ...) are not part of policy-sources. So policy-sources gives you the ability to modify some of the files in the policy package.
I originally installed both policy-sources and policy in a Fedora testing cycle. I can mess with stuff and have an occasionally messy system during testing cycles. For production systems that is unacceptable. Once the configuration has been nailed down regarding the installed applications and the set of data they operate on, no further changes/rebuilds of policy should be necessary.
My view is that on a user system only policy should be necessary. Being able to "fixfiles relabel" would be nice. Changing a file's context would be nice, too. My impression is that some/many of the diagnostic programs I would like to have are split between policy and policy-sources.
Can we have a situation (maybe it is already this way and I just don't understand) where I (as a system adminstrator) can log in, change a file's context and/or relabel the whole system with only policy installed? If the file context is incorrect because of a problem with the policy I should be able to edit and rebuild the policy on an administrator's system (which would have the policy-sources) and download/install to the user's system, optionally relabeling the system in the process.
On Sun, 2004-06-27 at 09:40, tmolina@cablespeed.com wrote:
My view is that on a user system only policy should be necessary. Being able to "fixfiles relabel" would be nice. Changing a file's context would be nice, too. My impression is that some/many of the diagnostic programs I would like to have are split between policy and policy-sources.
fixfiles, setfiles, and restorecon are part of policycoreutils, not any selinux-policy-* package. chcon (ala chown/chmod) is part of coreutils. The installed file_contexts configuration is part of selinux-policy-* but is also rebuilt by selinux-policy-*-sources. So you don't need policy sources for relabeling.
On Fri, 25 Jun 2004 06:17:34 -0400, Dan Walsh wrote:
Ivan Gyurdiev wrote:
On Thu, 2004-06-24 at 16:45 -0400, Stephen Smalley wrote:
On Thu, 2004-06-24 at 16:21, Ivan Gyurdiev wrote:
What's the proper way to upgrade the selinux policy?
yum and rpm leave me with .rpmnew files every single time.
This suggests that you installed the policy source package as well, or locally modified your policy directly. If you install or update the policy source package (selinux-policy-strict-sources), then it should rebuild the policy files from source and load the new ones automatically as part of the %post. Updating the policy package (selinux-policy-strict) will then leave you with .rpmnew files because it sees that the files have been locally rebuilt.
Yes, I have the sources package instaled - I need it to make relabel don't I? Since I upgrade through yum, and rawhide updates the sources package with the other one, I always update them together. However, the resulting files are not the same - file_contexts and file_contexts. rpmnew are different, and the binary policy differs too.
Do I need to run make relabel?
It is generally safest to do so, but often unnecessary (only if there is a relevant change to file_contexts that affects you). Relabeling is not presently automatically performed upon a policy update.
Are there plans to change that?
No because this could be a very long process. We are hoping to not change policy very often and less often change File Contexts. Especially with Targeted policy. I have modified fixfiles to be able to use RPM files as input and we are looking into a cron script to walk the file system on a regular basis to inform users of problems in the file context. This script could either repair the problems automatically (Not recommended), or easily allow the administrator to fix them the next morning.
Setfiles and restorecon have a new qualifier (-o filename) which will record the file paths of any files that the tools find with the incorrect security context. So if you run setfiles -n -v -o /tmp/badfilecontexts, you would have a report and a file with all the paths of files with bad file contexts. If everything looks ok, you could run restorecon -f /tmp/badfilecontexts and clean them up quickly.
Dan
Sounds pretty good in the long term.
However, looking my output from fixfiles, it seems as though there are gross changes in policy that are occasionally occuring during this development phase (object_r -> system_r).
It would be nice to get some sort of indication that a fixfiles run would be helpful when these gross changes occur.
---- There was a note awhile ago saying that the log from fixfiles would remain in the /tmp area, even though 'Y' was chosen to zap the /tmp files prior to relabel. Does this file survive the necessary following reboot? (I did not see it when I looked just now).
---- There was some talk of changing PAM so that it would better handle the 'su' operation. Has this been done? I ask this because I cannot get into any of my root priviledged Gnome applications anymore. This had been a problem, then it was fixed, now it is a problem (for me) again.
It seemed as though the proposed PAM change would also enable a shutdown direct from Gnome - even though Gnome had originally been started up as a user application (it would of course ask for a root password).
----- I am currently (as of an hour ago) current on 'yum update' and I did a complete 'fixfiles relabel' at init 1 state before my last boot.
BobG
Bob Gustafson wrote:
On Fri, 25 Jun 2004 06:17:34 -0400, Dan Walsh wrote:
Ivan Gyurdiev wrote:
On Thu, 2004-06-24 at 16:45 -0400, Stephen Smalley wrote:
On Thu, 2004-06-24 at 16:21, Ivan Gyurdiev wrote:
What's the proper way to upgrade the selinux policy?
yum and rpm leave me with .rpmnew files every single time.
This suggests that you installed the policy source package as well, or locally modified your policy directly. If you install or update the policy source package (selinux-policy-strict-sources), then it should rebuild the policy files from source and load the new ones automatically as part of the %post. Updating the policy package (selinux-policy-strict) will then leave you with .rpmnew files because it sees that the files have been locally rebuilt.
Yes, I have the sources package instaled - I need it to make relabel don't I? Since I upgrade through yum, and rawhide updates the sources package with the other one, I always update them together. However, the resulting files are not the same - file_contexts and file_contexts. rpmnew are different, and the binary policy differs too.
Do I need to run make relabel?
It is generally safest to do so, but often unnecessary (only if there is a relevant change to file_contexts that affects you). Relabeling is not presently automatically performed upon a policy update.
Are there plans to change that?
No because this could be a very long process. We are hoping to not change policy very often and less often change File Contexts. Especially with Targeted policy. I have modified fixfiles to be able to use RPM files as input and we are looking into a cron script to walk the file system on a regular basis to inform users of problems in the file context. This script could either repair the problems automatically (Not recommended), or easily allow the administrator to fix them the next morning.
Setfiles and restorecon have a new qualifier (-o filename) which will record the file paths of any files that the tools find with the incorrect security context. So if you run setfiles -n -v -o /tmp/badfilecontexts, you would have a report and a file with all the paths of files with bad file contexts. If everything looks ok, you could run restorecon -f /tmp/badfilecontexts and clean them up quickly.
Dan
Sounds pretty good in the long term.
However, looking my output from fixfiles, it seems as though there are gross changes in policy that are occasionally occuring during this development phase (object_r -> system_r).
It would be nice to get some sort of indication that a fixfiles run would be helpful when these gross changes occur.
There was a note awhile ago saying that the log from fixfiles would remain in the /tmp area, even though 'Y' was chosen to zap the /tmp files prior to relabel. Does this file survive the necessary following reboot? (I did not see it when I looked just now).
Log files are stored in /var/tmp to avoid the conflict. They should survive the reboot.
There was some talk of changing PAM so that it would better handle the 'su' operation. Has this been done? I ask this because I cannot get into any of my root priviledged Gnome applications anymore. This had been a problem, then it was fixed, now it is a problem (for me) again.
We moved around the pam_xauth and pam_selinux open calls in /etc/pam.d/su (coreutils)
It seemed as though the proposed PAM change would also enable a shutdown direct from Gnome - even though Gnome had originally been started up as a user application (it would of course ask for a root password).
I am currently (as of an hour ago) current on 'yum update' and I did a complete 'fixfiles relabel' at init 1 state before my last boot.
BobG
fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Fri, 2004-06-25 at 11:28, Bob Gustafson wrote:
However, looking my output from fixfiles, it seems as though there are gross changes in policy that are occasionally occuring during this development phase (object_r -> system_r).
Files shouldn't be labeled with system_r, and I see no instances of system_r in either the strict or targeted file_contexts file. Details?
On Fri, 25 Jun 2004 12:17:16 -0400, Stephen Smalley wrote:
On Fri, 2004-06-25 at 11:28, Bob Gustafson wrote:
However, looking my output from fixfiles, it seems as though there are gross changes in policy that are occasionally occuring during this development phase (object_r -> system_r).
Files shouldn't be labeled with system_r, and I see no instances of system_r in either the strict or targeted file_contexts file. Details?
-- Stephen Smalley sds@epoch.ncsc.mil National Security Agency
I was looking around for the log of my fixfiles run at the time I wrote the message and did not find them in /tmp. Later found them in /var/tmp
Faulty memory created the (object_r -> system_r) shown above.
Some of the actual lines (317) are shown below:
Many of the relabelings were from root: to system_u (not _r)
/usr/sbin/setfiles: relabeling /usr/share/texmf/web2c/pdflatex.log from root:object_r:rpm_script_tmp_t to system_u:object_r:usr_t /usr/sbin/setfiles: relabeling /usr/share/texmf/web2c/pdfjadetex.fmt from root:object_r:rpm_script_tmp_t to system_u:object_r:usr_t /usr/sbin/setfiles: relabeling /usr/share/texmf/web2c/pdfxmltex.log from root:object_r:rpm_script_tmp_t to system_u:object_r:usr_t /usr/sbin/setfiles: relabeling /usr/share/texmf/web2c/amstex.fmt from root:object_r:rpm_script_tmp_t to system_u:object_r:usr_t /usr/sbin/setfiles: relabeling /usr/share/texmf/web2c/bamstex.log from root:object_r:rpm_script_tmp_t to system_u:object_r:usr_t /usr/sbin/setfiles: relabeling /usr/share/texmf/web2c/cont-en.efmt from root:object_r:rpm_script_tmp_t to system_u:object_r:usr_t /usr/sbin/setfiles: relabeling /usr/share/texmf/web2c/elatex.log from root:object_r:rpm_script_tmp_t to system_u:object_r:usr_t /usr/sbin/setfiles: relabeling /usr/share/texmf/web2c/lambda.oft from root:object_r:rpm_script_tmp_t to system_u:object_r:usr_t
On Fri, 2004-06-25 at 15:07, Bob Gustafson wrote:
Many of the relabelings were from root: to system_u (not _r)
That is ok. setfiles just sets the user identities on all files to system_u initially, but subsequent file creation at runtime will leave them with the user identity of the creating process.
On Fri, 25 Jun 2004 10:28:57 CDT, Bob Gustafson bobgus@rcn.com said:
However, looking my output from fixfiles, it seems as though there are gross changes in policy that are occasionally occuring during this development phase (object_r -> system_r).
It would be nice to get some sort of indication that a fixfiles run would be helpful when these gross changes occur.
In the generalized case, how would it know? (I mean, other than the already mentioned 'fixfiles -n -v -o' and look at the logfile and restorecon)?
(Personally, I think a nightly cron job that does something like:
fixfiles -n -v -o /var/tmp/whatever; mail -s "Incorrect contexts" root < /var/tmp/whatever
is The Right Behavior. I owe whoever thought of it a beer :)
Right now, *my* single biggest mangler of contexts is all the local and 3rd-party stuff that gets into system directories via 'make install' rather than via RPM (so far this morning, I've already had one package that I did a 'cvs update' and then 'make/make install', and since it supports plugins, the following clean-up relabeled about 30 *.so files to shlib_t....
See above-mentioned Right Behavior, and guess who doesn't always remember to run fixfiles after a 'make install' and needs to be nagged. :)
Valdis.Kletnieks@vt.edu wrote:
On Fri, 25 Jun 2004 10:28:57 CDT, Bob Gustafson bobgus@rcn.com said:
However, looking my output from fixfiles, it seems as though there are gross changes in policy that are occasionally occuring during this development phase (object_r -> system_r).
It would be nice to get some sort of indication that a fixfiles run would be helpful when these gross changes occur.
In the generalized case, how would it know? (I mean, other than the already mentioned 'fixfiles -n -v -o' and look at the logfile and restorecon)?
(Personally, I think a nightly cron job that does something like:
fixfiles -n -v -o /var/tmp/whatever; mail -s "Incorrect contexts" root < /var/tmp/whatever mail -s "Incorrect contexts" root < /var/tmp/whatever
That is the idea although you might want
fixfiles -n -v -o /var/tmp/whateverfixfiles -n -v -o /var/tmp/whatever || mail -s "Incorrect contexts" root < /var/tmp/whatever
So you only get mail when it finds something. Of course this means fixfiles exits with a status. I will look into this.
is The Right Behavior. I owe whoever thought of it a beer :)
Right now, *my* single biggest mangler of contexts is all the local and 3rd-party stuff that gets into system directories via 'make install' rather than via RPM (so far this morning, I've already had one package that I did a 'cvs update' and then 'make/make install', and since it supports plugins, the following clean-up relabeled about 30 *.so files to shlib_t....
See above-mentioned Right Behavior, and guess who doesn't always remember to run fixfiles after a 'make install' and needs to be nagged. :)
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Sat, 26 Jun 2004 02:44, Valdis.Kletnieks@vt.edu wrote:
Right now, *my* single biggest mangler of contexts is all the local and 3rd-party stuff that gets into system directories via 'make install' rather than via RPM (so far this morning, I've already had one package that I did a 'cvs update' and then 'make/make install', and since it supports plugins, the following clean-up relabeled about 30 *.so files to shlib_t....
Why not just build RPMs of all your third-party stuff?
On Sat, 26 Jun 2004 16:43:32 +1000, Russell Coker said:
On Sat, 26 Jun 2004 02:44, Valdis.Kletnieks@vt.edu wrote:
Right now, *my* single biggest mangler of contexts is all the local and 3rd-party stuff that gets into system directories via 'make install' rather than via RPM (so far this morning, I've already had one package that I did a 'cvs update' and then 'make/make install', and since it supports plugins, the following clean-up relabeled about 30 *.so files to shlib_t....
Why not just build RPMs of all your third-party stuff?
Laziness, mostly. There's a few CVS trees that I follow that are fast-moving targets. It's easier to just have a 2-line shell script that does a 'make install' and a 'setfiles ../file-contexts /usr/local' than to create a .spec file and keep it up to date and get rpmbuild and cvs to play nice for a CVS tree that you're syncing to more than twice a week... ;)
selinux@lists.fedoraproject.org
-
Bob Gustafson -
Daniel J Walsh -
Ivan Gyurdiev -
Russell Coker -
Stephen Smalley -
Thomas Molina -
Thomas Molina -
Valdis.Kletnieks＠vt.edu