Mike Hearn wrote:
On Mon, 2005-05-09 at 11:32 -0400, Daniel J Walsh wrote:No. If you update policy or kernel or any other componant of SELinux, things should
The goal is to not change the fundamental securitylevel on
policy/kernel updates [ ... ] Any new booleans need to default to
true.
Hmm, so if I understand correctly then it's actually very possible that updates/new distro versions will be shipped that deny things that were previously allowed by default, as long as there is a boolean to switch them off?
That sounds like by default every time you upgrade, programs might break. There must be a better way to deal with this.
This is what booleans are for.
Booleans are just an implementation mechanism, what is needed is some
simple (end-user understandable) means for ISVs to communicate what
permissions their software needs - possibly for old versions of their
software that don't work with new policy.
work as they did before. Anything that breaks is a bug.
We attempt to set a reasonable relaxness around the policy. So most booleans are set to allow users full access.Usability-wise it's not OK to put:
"This software requires that the SELinux 'foo', 'bar', 'xyz' booleans be
set to false".
Advanced users may want to turn up the security. So if a user wants to be able to turn off apache's ability to run
cgi scripts. They can set httpd_enable_cgi=0. The default will be allow cgi scripts.
This is asking too much of the user, especially as there should ideally be some easy way to apply more relaxed policy to an individual program if it can't cope with the system defaults. Booleans for individual programs is just too complicated.
Agreed, that is why we ship with a relaxed policy where reasonable.
I suggested a level system because (I think) it's reasonable to expect end users to deal with statements like "This program cannot run with security level 3 or higher". Whereas it's not reasonable to expect people to be able to adjust things at a finer level of detail than that.
thanks -mike
--
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-selinux-list
