8:18 a.m.
On Thu, 2009-10-15 at 09:29 +0200, yersinia wrote:
On Wed, Oct 14, 2009 at 5:09 PM, Matthew Ife
<deleriux(a)airattack-central.com> wrote:
> So, I did a brief unscientific survey regarding SELinux with my
> colleagues. The idea here is to work out what people see wrong or right
> with SELinux and when documentation is done what should our focus or
> priorities be in regards to it?
> To give you a bit of background respondents are all above average
> technically Linux experienced whom work for a hosting company offering
> amongst other things Linux based solutions of some sort either
> pre-packed or bespoke. All the people I asked have a procedural approach
> to security (not the type of thing tagged onto the end of a project line
> of thinking) and in general are open to security advise.
>
> Attached is the PDF document with the questions I asked - you'll have to
> forgive my decorating abilities!
>
> The questions I asked could be wrong, the people I'm asking might not be
> the "average" sample we could do with and admittedly the sample is way
> too small.
>
> So firstly on with the questions I asked and why I asked them:
>
>> If you installed Fedora regarding SELinux would you
>> a) Disable it on install
>> b) permissive on install
>> c) enforcing on install.
> The point with this question is to really just gauge what these peoples
> feelings are with it "out of the box". Do they run it or do they not and
> how does that compare with their ideas for the questions I asked below.
>
>> Why would you choose that option?
> So the idea behind this question was to find out what they liked or
> disliked about selinux which was enough of a motivator for them to turn
> it on or turn it off or disable it completely.
>
>> Specifically what is SELinux meant to do?
> Really what I wanted to find out here is what the people would consider
> SELinux as being able to achieve for them as well as a brief
> understanding of how much they know about SELinux.
>
>> Out of five, (five being very sufficient, 0 being completely
> insufficient) where would you put standard UNIX permissions (rwx,
> setuids and acls) for security on a machine? First for desktops second
> for servers.
> This question was meant to gauge the persons understanding of DAC and
> how they pit against the current major security threats. I.E "Do you
> find DAC is sufficient enough for securing your server".
>
>
> >From the data this is my analysis but my opinions are pretty biased as I
> already know all these people anyway. I'd love peoples feedback.
>
>
> None of the respondents had any insight into the pros/cons of DAC or
> MAC.
> All the respondents saw SELinux as a fine grained access control
> mechanism.
> The more respondents understood about SELinux the more they were likely
> to enable it.
> Currently servers would benefit from SELinux more than Desktops would.
>
>
> So from the very limited feedback I've got I would say:
>
> Peoples understanding of why MAC in some fashion is necessary is limited
> or none existent. There should probably be some good argumentative cases
> for why DAC is not able to adequately contain a security breach or
> threat and what SELinux MAC is ready to do about it. Perhaps a wiki page
> that explains what DAC and MAC is - giving examples, what the current
> security trends and threats are against your systems and what both can /
> cannot do to mitigate them.
>
For the first question this is the classic paper that explain why a
MAC is necessary for an OS -
http://jya.com/paperF1.htm
For the second point this is the "selinux mitigation new" from tresys
http://www.tresys.com/innovation.php
n any case should be made clear that a MAC-level policy applied to a
Web application does not protect applications itself in general, but
the web server / application server/web application in some particular
case - depends by threats (e.g. BOF versus XSS for example, defacing
versus sql injection ) - but in first place the operating system that
hosts them. For the issues dealt by OWASP it is necessary, ALSO, to
have a web application firewall like mod_security. IMHO, the most
prudent approach is to use mod_security and SELinux, both.
For what regard the DOS attack MAC may or may not help, it depends.
For example, if there is an application problem for which a certain
sequence of commands can lead to application termination, and should
not happen, the MAC can do little or nothing.
Best Regards
> People envision SELinux as a access control system. Documentation on
> type enforcement (perhaps with examples analogous to DAC) would be
> beneficial.
>
> In addition personally I would say most sysadmins are totally missing
> fundamental security understandings (what is a subject, what is an
> object, what is DAC what is MAC etc) and this means they are unable to
> appreciate what SELinux is trying to accomplish. Also I believe
> sysadmins do not consider containment of a security breach and spend
> much of their effort attempting to prevent it in the first place.
>
> Well, thats probably more than I can prune on the whole thing i've got.
> I might be perhaps looking way too much into the information I have and
> would recommend people make up their own minds based off of the
> information I supplied.
>
> The goal here is to find out what peoples vision of SELinux is (either
> right or wrong) and what can be done to help correct it.
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
I should point out my intention here is not to completely rewrite whats
already been written, but sysadmins don't want to click a list of
references to much larger documents to fetch the information that they
want. We should cherry pick the best bits and reformat the content to
deliver it to people in a more digestible way.
Regardless of peoples feelings - as a sysadmin myself - I don't want to
spend my time sifting and scanning through whitepapers, essays and
presentations when I'm really trying to see how I can resolve an
immediate problem.
Whitepapers, essays and presentations are great when you don't have a
deadline to meet. The majority of people who will consider SELinux are
going to do so when they have a problem to solve.
What I'd like to see more of is practical examples with links inside the
examples to a glossaries of terminologies so people can read a document
and get links to information that they don't have a clear understanding
of, in this way we are giving them proof of concept examples showing
SELinux in action with opportunities to understand more fundamental
security concepts to fortify their theoretical knowledge. The glossaries
could contain references to other more heavier theoretical information
including many of the documents people are suggesting.
I think part of the problem is when people say "there's no
documentation" what they mean is easy to digest and simple to implement
documentation - I think there really is lots of very useful and good
documentation. Its just sparsely distributed and most professionals
working on a project with deadlines simply don't want to be bogged down
spending more time searching for the data than having it provided to
them from a centralized source.