Re: Debian / SE-Linux
On Thu, May 13, 2004 at 10:56:35AM +0000, Luke Kenneth Casson Leighton 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.
What are Gentoo and RedHat (which you cite as supporting SElinux by default)
doing in this regard?
> and the documentation on selinux policy editing is... extremely
> harsh, and could do with a few more people understanding it.
[...]
> 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...
> - 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.
> 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).
> food for thought?
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 remove
them or whatever needs to happen instead of just leaving outdated policy
files around, which might do more harm than good. I'm pretty sure that most
maintainers would be happy to include a few data files in their package if
it didn't cause problems anywhere else. That's at least one problem
solved...
- Matt
Reply to: