Mike Hearn wrote:
On Thu, 28 Apr 2005 11:54:30 -0400, Daniel J Walsh wrote:The goal is to not change the fundamental securitylevel on policy/kernel updates. If it does there
Anyways I think we need more discussion on handling third party and user customization of policy outside of the current make tree stuff.
Sorry for posting so late ... one thing I'd also like to see is some formal rules for policy compatibility. For instance, if FC4 ships and says "Shared libraries with text relocations are no longer allowed by default" then this breaks things. If FC5 ships and now you need special tagging to connect to the X server, well ....
is a bug in policy. Now we will be adding additional booleans in order to allow users to increase
the securitylevel. So if a kernel gets added to a shipping OS (FC3/RHEL4) that supports an additional
access check, we need to allow this by default. Same goes with adding additional policy rules. For
example, I am trying to update the FC3/RHEL4 targeted policy with the improvements made in rawhide.
Any new booleans need to default to true.
(I don't know if this has actually happened or not yet but it seems to keep coming up)
It may be decided that it's an acceptable price to pay for the additional security, or it may not. I don't think that discussion should happen now. But I think ISVs would feel a lot more secure if this sort of decision appeared not to be arbitrary and if there was some way to plan and work with the OS base policy writers.
A basic system could be to have widely adopted (cross-distro) and documented security levels, ie:
Level 1: Basic targetted - optin, only affects daemons, no restrictions on anything else
Level 2: Targetted + additional restrictions, execshield enabled (ie this is not just an SELinux thing), apps which require special
privs must have custom policy
This is what booleans are for.
Level 3: Strict
or something similar to that. This means users can adjust their security level to adapt to what programs they run, and ISVs can say "Minimum Requirements: Level 2 or lower security level".
thanks -mike
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
--
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
