On Tue, 2005-02-22 at 13:46 -0500, Stephen Smalley wrote: >On Tue, 2005-02-22 at 13:40 -0500, Colin Walters wrote: >> One thing I wonder is if there's any other issues tied to legacy >> binaries that would possibly make sense to control via this interface. >> checkreqprot is a fairly specific name; You had suggested legacycompat >> earlier? > >As is, the patch won't affect any execute-related checking that is >requested by the application, and that includes anything requested by >ld.so. Hence, for example, running gpg on a FC3 system still triggers >an execmod check against the gpg binary but no longer triggers various >other execute-related checks that were being caused by the read-implies- >exec logic in the kernel. But we have already worked around the gpg (and other) issues by enabling the unconfined_t execmod/execmem booleans by default, no? >As is, the patch allows you to set /selinux/checkreqprot (if you have >appropriate permission), so /sbin/init or an init script could easily >initialize it to some default. But I was wondering whether the original >compiled-in value should be a kernel config option, similar to the >bootparam default, so that a vendor can set the initial value as desired >depending on their preference, without requiring any customization by >init or an init script at all. From your patch, it looks like the default is to have it disabled. I do feel that for Fedora we will want it enabled by default, so providing a kernel build option for it is useful; the fewer magic things are in the init scripts, the better.
This archive was generated by hypermail 2.1.3 : Tue Feb 22 2005 - 11:11:14 PST