[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian / SE-Linux

On Fri, May 14, 2004 at 03:43:06PM +1000, Russell Coker wrote:
> 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.  

[Other similar tales snipped]

Well, if it can be compiled in without affecting others, especially if it is
maintained upstream, I can't see any real reason for a DD to not enable it.

> 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.

Sounds like a plan to me.

[Comparison between SElinux policy and Unix security concepts]

> 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.

It sounds like SElinux policy is useful for more than just saying "thou
shalt not do that".

> 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.

I obviously misunderstood the purpose of SElinux policy descriptions.  I was
under the impression that they basically described the permissions a
particular program needed, which would just require the package to define
what permissions it needed.  From a quick scout around, I think I've got a
bit more of an idea of what SElinux policy is, and I can see how, in some
contexts, it would be useful to have coordination amongst packages --
especially since disjoint policies could result in some very, very nasty

- Matt

Reply to: