Re: Debian / SE-Linux
On Thu, 13 May 2004 22:18, Matthew Palmer <mpalmer@debian.org> wrote:
> > for example, an entire set of base utilities - pam, bsdutils,
> > login and coreutils to name a few - are having to be patched,
> > compiled, and made available SEPARATELY by one or two
> > individuals... and then of course their .debs become very
> > rapidly out-of-date.
>
> If SElinux support can be integrated into standard programs which can also
> support non-SElinux systems, then I'm all for mainlining these changes.
This is easy to do. When I took over fcron I put the SE Linux changes in, and
none of the users who don't use SE Linux even noticed the difference.
Recently procps was modified upstream to have SE Linux support and that is
the default option for Debian (in fact Debian goes slightly further than
upstream and adds an extra command-line parameter to ps for convenience),
again people who use it don't notice it.
Logrotate now has SE Linux code in it's tree, it just needs to be compiled
with SE Linux support as is done for the Red Hat build - the upstream build.
For logrotate there will be a slight benefit for non-SE users in having a SE
Linux build, this is what the upstream developers use and is the option that
has been tested the most.
sysvinit is the only package which is even slightly problematic (IMHO), as
compiling it with SE Linux support requires that libselinux1 be in section
base. This is not an insurmountable problem, but we do want to reduce the
size of base if possible.
> What are Gentoo and RedHat (which you cite as supporting SElinux by
> default) doing in this regard?
For Gentoo everything is compiled at install time. I imagine that if you have
SE Linux enabled then things are compiled differently, but I have not
checked. I have CC'd the leader of the Hardened Gentoo project and I'm sure
that he'll be able to give a good description of what they are doing.
For Red Hat all RPMs are getting the SE Linux code compiled in. There is no
option for installing packages that lack SE Linux support or a kernel without
SE Linux compiled in.
> > 3) this is the biggie: serious consideration be given to updating
> > debian policy to ensure that each debian maintainer be responsible
> > for the corresponding domain/program/PACKAGENAME.te,
> > file_contexts/program/PACKAGENAME.fc, net_contexts (if the program
> > requires network access) and any other policy files.
>
> These two things are mutually exclusive. I'd be quite happy to maintain
> policy files for any of my packages that required them, except that
> checking them against every change in the package, when the editing them is
> very hard to do, is not something that every maintainer is likely to be
> real keen on. I guess it could be primarily taken on by a group of people,
> similar to the translation teams, which maintain policy files for relevant
> packages and periodically update them as required. I don't know whether it
> will work quite as well, as what needs to be translated is typically fairly
> well defined, while I can imagine that defining SElinux policy could be a
> lot more open-ended...
True. Writing SE Linux policy is not something that can be done as a
packaging after-thought, it requires a good knowledge of how the entire
system works and it often reveals bugs in the application (which should be
fixed not worked-around by bad SE Linux policy). I can write policy for most
daemons on my own, having a few people to help out would be good. Trying to
coerce many other developers into writing policy if SE Linux doesn't interest
them would not be productive.
> > - on the basis that any package maintainer is expected to understand
> > traditional unix security, surely they should also be expected to
> > understand selinux policy as well.
>
> Unix security is conceptually simple; even then, security on Unix systems
> gets screwed up on a regular basis by people who don't understand the
> implications of some decision. If SElinux policy is significantly more
> complex, I can't imagine that every package maintainer is going to be able
> to understand it all to the level required to ensure system security in all
> cases.
Yes. However it's not quite that bad. SE Linux policy is easier to analyse,
I have on several occasions spotted security flaws in applications by the
policy that's needed to run them. The applications in question were run by
many people for quite some time without the bugs apparently being noticed by
anyone (or at least not anyone who wanted them fixed). But they were easy to
notice in SE Linux policy.
> > the advantage will be that (for example in the case of wdm) they will
> > go "hmmm, that's bad. _surely_ wdm doesn't need write access to
> > /etc??? oh bugger, yes it does because it demands write access to
> > /etc/X11/wdm, ah that's bad, better fix it" and will find and report
> > some of the security problems.
>
> Recoding things like that isn't necessarily a Debian maintainer issue;
> rewriting significant portions of a program (even to the point of totally
> restructuring it, if necessary) will possibly be beyond the desires of a
> maintainer, especially when it's to support something that they don't
> personally care about. (If you think you're going to get universal support
> for SElinux amongst Debian Developers, you're mad. We can't agree on
> *anything* unanimously).
If a good patch is supplied which does not hurt the default case (non-SE Linux
users) then they should accept it.
> I certainly believe that we can do better in supporting advanced security
> models; however the practical problems of integrating it fully aren't
> small. If I had to make a suggestion, I'd say work with Russell producing
> patches and policy, and advocating SElinux wherever you can. I think it's
> definitely worth trying to get policy files into individual packages rather
> than in a single centralised package; at least there, maintainers can
One advantage of having the policy files in a centralised package is that they
are dependant on each other in some ways. Sometimes changing one file
requires changing another to match, if the files are in different packages
then it's necessary to upload two packages at the same time. I think it's
easier to have all files that are maintained by one person (or group) in one
package.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
Reply to: