On Fri, 2004-06-04 at 10:53, Daniel J Walsh wrote:
Todays selinux-polcy-* RPMS attempt to handle the /etc/selinux/config and /etc/sysconfig/selinux files in the post install.
Please check them out.
On a system that had not yet installed either selinux-policy-strict or selinux-policy-targeted (just policy and policy-sources and no /etc/selinu/config), I ran: yum update SysVinit libselinux yum install selinux-policy-targeted selinux-policy-targeted-sources
It installed the targeted policy as expected, but /etc/selinux/config has SELINUXTYPE=strict in it.
Stephen Smalley wrote:
On Fri, 2004-06-04 at 10:53, Daniel J Walsh wrote:
Todays selinux-polcy-* RPMS attempt to handle the /etc/selinux/config and /etc/sysconfig/selinux files in the post install.
Please check them out.
On a system that had not yet installed either selinux-policy-strict or selinux-policy-targeted (just policy and policy-sources and no /etc/selinu/config), I ran: yum update SysVinit libselinux yum install selinux-policy-targeted selinux-policy-targeted-sources
It installed the targeted policy as expected, but /etc/selinux/config has SELINUXTYPE=strict in it.
Yes this is because you were running with strict policy before, so I expected you to run with strict policy afterwards. Yum update would have pulled both strict and targeted.
So Initial install gets targeted, upgrade from FC2 with policy gets strict. The one hole in the strategy is upgrading a policy -> targeted without installing strict.
Dan
On Fri, 2004-06-04 at 13:24, Daniel J Walsh wrote:
Yes this is because you were running with strict policy before, so I expected you to run with strict policy afterwards. Yum update would have pulled both strict and targeted.
So Initial install gets targeted, upgrade from FC2 with policy gets strict. The one hole in the strategy is upgrading a policy -> targeted without installing strict.
I'd suggest that each package (selinux-policy-strict, selinux-policy-targeted) set the SELINUXTYPE to its own type (strict or targeted) if it is not already set (or more simply, if /etc/selinux/config does not exist at all). Wouldn't a yum update pull in strict first, so this would still ensure preservation of strict policy in that case?
Stephen Smalley wrote:
On Fri, 2004-06-04 at 13:24, Daniel J Walsh wrote:
Yes this is because you were running with strict policy before, so I expected you to run with strict policy afterwards. Yum update would have pulled both strict and targeted.
So Initial install gets targeted, upgrade from FC2 with policy gets strict. The one hole in the strategy is upgrading a policy -> targeted without installing strict.
I'd suggest that each package (selinux-policy-strict, selinux-policy-targeted) set the SELINUXTYPE to its own type (strict or targeted) if it is not already set (or more simply, if /etc/selinux/config does not exist at all). Wouldn't a yum update pull in strict first, so this would still ensure preservation of strict policy in that case?
To me it looks like Yum picks non-related RPM files randomly or least not via the alphabet.
Dan
On Fri, 2004-06-04 at 13:49, Daniel J Walsh wrote:
To me it looks like Yum picks non-related RPM files randomly or least not via the alphabet.
I was thinking that there was a relationship between strict and targeted (e.g. obsoletes), but I suppose that is only between them and the old policy packages.
On Fri, 2004-06-04 at 10:53, Daniel J Walsh wrote:
Todays selinux-polcy-* RPMS attempt to handle the /etc/selinux/config and /etc/sysconfig/selinux files in the post install.
Please check them out.
Shouldn't it default to SELINUX=permissive in the absence of any /etc/sysconfig/selinux file?
Do we need a dependency on the newer libselinux, policycoreutils, and SysVinit that are aware of the new policy locations?
Stephen Smalley wrote:
On Fri, 2004-06-04 at 10:53, Daniel J Walsh wrote:
Todays selinux-polcy-* RPMS attempt to handle the /etc/selinux/config and /etc/sysconfig/selinux files in the post install.
Please check them out.
Shouldn't it default to SELINUX=permissive in the absence of any /etc/sysconfig/selinux file?
No, Well the only way this should happen is on a fresh install or a disabled SELinux box. I don't like permissive because we end up with to many false AVC Messages. A fresh install should put down proper context and with targeted policy, enforcing should work out of the box. Also I have a concern about people forgetting to change permissive to enforcing, and having a false sence of security.
Do we need a dependency on the newer libselinux, policycoreutils, and SysVinit that are aware of the new policy locations?
Probably. Any application that uses default contexts needs to use the new library.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Stephen Smalley