Re: [PATCH 1/1] [bug556972-srivasta]: Explicitly allow /selinux and /sys as FHS exceptions
On Sun, Nov 22 2009, Steve Langasek wrote:
> On Fri, Nov 20, 2009 at 12:33:50PM -0600, Manoj Srivastava wrote:
>> Hi folks,
>
>> The report #556972 was filed about a FHS violation in mounting
>> selinuxfs on /selinux, which is accurate. Additionally, /sys does not
>> appear in the FHS either, and is thus in a similar situation.
>
>> Now, I can move the mount point in libselinux1, perhals to
>> /lib/sellinux, but that would make us incompatible with other
>> installations, and cause a large number of needless conflict with
>> currently installed SELinux. Here is the backgound:
>
> Wouldn't it make more sense to expose this as a subdirectory of /sys
> rather than /lib, since this appears to be a kernel interface?
> Why didn't SELinux upstream engage with the FHS, to standardize on
> something consistent with the FHS's overall design and guard against
> such migration concerns in the first place?
I have no comment on why the FHS is so dead or on the (lack of)
motivation of upstream to do things one way or the other.
>
>> 2) sysvinit (and upstart, if the patch is accepted) load the security
>> policy for machines where SELinux is enabled, and need to mount
>> selinuxfs to get details of the state of selinux in the
>> kernel. Since /proc is not around when this happens, this is the one
>> place where the distribution default od the selinuxfs mount point is
>> hard coded.
>
> So the one place which hard-codes the mount point is init; but only
> sysvinit has this patch, and we have an upcoming transition away from
> sysvinit to upstart.
There is a patch available in Debian BTS for upstart as
well. And this lack of security features in upstart might be a cause
for concern about migrating away from sysvinit; has this actually been
addressed in a discussion about the proposed transition? Were the
SELinux folks asked?
> And my understanding is that upstart upstream disagrees with the
> principle of hard-coding a particular LSM into init when an initramfs
> works just as well - and within the initramfs, things can mount
> selinuxfs anywhere they choose, if they unmount again later.
Upstream apparently only support instalaltions with official
kernels and mandate a initramfs, whichis something the Debian project
has not yet required. Has upstart upstream investigated and addressed
security concerns of the non-bypassability of a security policy if an
initramfs is the only thing loading the security policy ?
> That doesn't sound to me like a major obstacle for a transition in any case,
> then?
I personally think it is. Tacking on these requirements of an
initramfs is something that has not been adequately discussed.
>> 3) The default for fedora, gentoo, and Debian has been /selinux
>
> Where does Red Hat place theirs?
/selinux.
manoj
--
Spirtle, n.: The fine stream from a grapefruit that always lands right
in your eye. Sniglets, "Rich Hall & Friends"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: