SELinux talk

SELinux talk

[Andrew Holway]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

Hello,

I'm giving a talk on SELinux at a little conference here in Berlin in a
couple of days. I was going to do the following items.

IEEE 1003.1e/2c - A withdrawn draft standard.
Linux ACLS - Hacked together from IEEE 1003.1e/2c
SELinux -> An opensource solution for the US military.
DAC 1997 -> 2015 - The elephant in the room.

I was wondering if anyone could provide me with specific bulletpoint
examples of the problems inherent with the current ACL system and how
SELinux can mitigate these problems.

Can anyone tell me about the relationship between IEEE 1003.1e/2c and
SELinux?

Any other interesting nuggets to keep a technical but non security focussed
audience interested?

Ta

Andrew



-- 
Otter Networks UG
http://otternetworks.de
fon: +49 30 54 88 5197
Gotenstraße 17
10829 Berlin

[-- Attachment #2: Type: text/html, Size: 1221 bytes --]

Re: SELinux talk

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 3083 bytes --]

On Tue, May 12, 2015 at 04:42:41PM +0200, Andrew Holway wrote:
> Hello,
> 
> I'm giving a talk on SELinux at a little conference here in Berlin in a
> couple of days. I was going to do the following items.
> 
> IEEE 1003.1e/2c - A withdrawn draft standard.
> Linux ACLS - Hacked together from IEEE 1003.1e/2c
> SELinux -> An opensource solution for the US military.
> DAC 1997 -> 2015 - The elephant in the room.
> 
> I was wondering if anyone could provide me with specific bulletpoint
> examples of the problems inherent with the current ACL system and how
> SELinux can mitigate these problems.

Here is one i somehow find compelling:

Centralized governed (MAC) versus De-centralized goverened (DAC) security

Back in the days of 1997 the privilege of computer environments was pretty much limited to academic use.

I think there was an filosophy of trust. Were all academics we know what we do and we're all good (we dont make mistakes)

(Some still believe in that)

To others, things changed since then.

Computer environments are no longer limited to academics and everyone and their mother are now wielding a computer with a 100 mbit+ uplink to the rest of the connected world.

Also we're now pretty much all connected. That means that we can in theory now all affect eachothers´ experience.

For example some could in theory send your site into a black hole by packeting it to death.
(some user with access to your system may decide to use your assets to ruin the fun for someone else on the network by udp flooding or whatever) 

Also these days the stakes are much higher in general (some businesses depend for their lively hood on computer environment)

Those three changes are basically a pretty compelling reason to calibrate the security model to the new requirements and threats.

SELinux and MAC in general, allows the owner of a computer system or environment to take control back into his own hands by overriding traditional DAC

SELinux enables one to not necessarily trust individual processes and/or users on a system. It allows owners to enforce what
indidivual processes and users can do thereby enforcing integrity

Some other advantages of SELinux over other MAC systems are that SELinux is customizable, flexible and allows for finer-grained access control.

> 
> Can anyone tell me about the relationship between IEEE 1003.1e/2c and
> SELinux?
> 
> Any other interesting nuggets to keep a technical but non security focussed
> audience interested?
> 
> Ta
> 
> Andrew
> 
> 
> 
> -- 
> Otter Networks UG
> http://otternetworks.de
> fon: +49 30 54 88 5197
> Gotenstraße 17
> 10829 Berlin

> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.


-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: SELinux talk

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2824 bytes --]

On Tue, May 12, 2015 at 05:12:01PM +0200, Dominick Grift wrote:
> Here is one i somehow find compelling:
> 
> Centralized governed (MAC) versus De-centralized goverened (DAC) security
> 
> Back in the days of 1997 the privilege of computer environments was pretty much limited to academic use.
> 
> I think there was an filosophy of trust. Were all academics we know what we do and we're all good (we dont make mistakes)
> 
> (Some still believe in that)
> 
> To others, things changed since then.
> 
> Computer environments are no longer limited to academics and everyone and their mother are now wielding a computer with a 100 mbit+ uplink to the rest of the connected world.
> 
> Also we're now pretty much all connected. That means that we can in theory now all affect eachothers´ experience.
> 
> For example some could in theory send your site into a black hole by packeting it to death.
> (some user with access to your system may decide to use your assets to ruin the fun for someone else on the network by udp flooding or whatever) 
> 
> Also these days the stakes are much higher in general (some businesses depend for their lively hood on computer environment)
> 
> Those three changes are basically a pretty compelling reason to calibrate the security model to the new requirements and threats.
> 
> SELinux and MAC in general, allows the owner of a computer system or environment to take control back into his own hands by overriding traditional DAC
> 
> SELinux enables one to not necessarily trust individual processes and/or users on a system. It allows owners to enforce what
> indidivual processes and users can do thereby enforcing integrity
> 
> Some other advantages of SELinux over other MAC systems are that SELinux is customizable, flexible and allows for finer-grained access control.
> 

After this i will stop my ramble :)

Basically i would argue that DAC == trust, versus MAC == trust but verify

Also the above explanation focusses a bit too much on malicious intent.

But consider for example: now a lot of people write code that runs on others systems. (consider php and your average php dev, or people like myself LOL)

So these people aren't necessarily malicious but instead maybe not as competent. You may end up with a buggy program that affects the functionality of the remainder of the system or even the network.

By enforcing what the process can do exactly one can ensure a higher level of integrity.

The SELinux type enforcement security model is used to enforce integrity
The SElinux identity based access control security model is used by SELinux to complement traditional DAC

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: SELinux talk

[Patrick K., ITF]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

Andrew,


Please visit:
http://www.tresys.com/innovation/library.php

Best Regards,

-- 
  Patrick K.

On 5/12/2015 10:42 AM, Andrew Holway wrote:
> Hello,
>
> I'm giving a talk on SELinux at a little conference here in Berlin in 
> a couple of days. I was going to do the following items.
>
> IEEE 1003.1e/2c - A withdrawn draft standard.
> Linux ACLS - Hacked together from IEEE 1003.1e/2c
> SELinux -> An opensource solution for the US military.
> DAC 1997 -> 2015 - The elephant in the room.
>
> I was wondering if anyone could provide me with specific bulletpoint 
> examples of the problems inherent with the current ACL system and how 
> SELinux can mitigate these problems.
>
> Can anyone tell me about the relationship between IEEE 1003.1e/2c and 
> SELinux?
>
> Any other interesting nuggets to keep a technical but non security 
> focussed audience interested?
>
> Ta
>
> Andrew
>
>
>
> -- 
> Otter Networks UG
> http://otternetworks.de
> fon: +49 30 54 88 5197
> Gotenstraße 17
> 10829 Berlin
>
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.


[-- Attachment #2: Type: text/html, Size: 3101 bytes --]

Re: SELinux talk

[Stephen Smalley]

On 05/12/2015 10:42 AM, Andrew Holway wrote:
> Hello,
> 
> I'm giving a talk on SELinux at a little conference here in Berlin in a
> couple of days. I was going to do the following items.
> 
> IEEE 1003.1e/2c - A withdrawn draft standard.
> Linux ACLS - Hacked together from IEEE 1003.1e/2c
> SELinux -> An opensource solution for the US military.
> DAC 1997 -> 2015 - The elephant in the room.
> 
> I was wondering if anyone could provide me with specific bulletpoint
> examples of the problems inherent with the current ACL system and how
> SELinux can mitigate these problems.

This has been repeatedly described in our published papers and
presentations as well as many external SELinux resources.  In short form:

DAC:
- Decisions based only on user identity/ownership.
- No protection against malicious or flawed applications (every
application you run has access to everything to which you have access,
and is free to propagate that access to others).
- Subject to the whims, carelessness, or maliciousness of every user.
- Typically only two major categories of users:  superuser or completely
unprivileged, leading to overprivilege for many processes or weak
permissions to work around.

MAC, and in particular SELinux:
- Decisions based on all security-relevant attributes, taking into
account not only user identity but also active role, the trustworthiness
and function of the program that is executing (encoded in the domain),
the clearance of the user, etc.
- Ability to confine malicious and flawed applications, including even
ones that run as root.
- Policy defined by administrator/organization, enforced over all users
and their programs.
- Support for fine-grained least privilege, ability to tailor to match
the specific trustworthiness and function of each component.


> Can anyone tell me about the relationship between IEEE 1003.1e/2c and
> SELinux? 

Largely none.  That withdrawn draft standard embodied the traditional
view of Mandatory Access Control and Privileges embodied in the legacy
trusted operating systems of the past, which is quite different from the
flexible Mandatory Access Control architecture and Type Enforcement
model embodied in SELinux.  That flexible MAC architecture and TE model
were in fact designed to address the shortcomings of such systems.
Again, see our published papers and presentations and external SELinux
resources, e.g.:
https://www.nsa.gov/research/selinux/background.shtml
https://www.nsa.gov/research/selinux/docs.shtml
http://freecomputerbooks.com/The-SELinux-Notebook-The-Foundations.html
http://seandroid.bitbucket.org/PapersandPresentations.html

Particularly with respect to comparisons with POSIX.1e, you may be
interested in:
http://www.securecomputing.com/pdf/secureos.pdf (not about SELinux per
se, but compares Type Enforcement, which is the core SELinux security
model, to POSIX.1e capability model)

> Any other interesting nuggets to keep a technical but non security
> focussed audience interested?

Re: SELinux talk

[Casey Schaufler]

On 5/12/2015 9:57 AM, Stephen Smalley wrote:
> On 05/12/2015 10:42 AM, Andrew Holway wrote:
>> Hello,
>>
>> I'm giving a talk on SELinux at a little conference here in Berlin in a
>> couple of days. I was going to do the following items.
>>
>> IEEE 1003.1e/2c - A withdrawn draft standard.

As Stephen says below, SELinux is more of a pendulum swing away from
than a derivative of that work and the TCSEC that inspired it.

>> Linux ACLS - Hacked together from IEEE 1003.1e/2c

Not a hack. Really. A port of the ACLs from Irix,
with the nasty parts replaced. Yes, based on 1003.1e/2c,
but all the UNIX systems did that, too.

>> SELinux -> An opensource solution for the US military.
>> DAC 1997 -> 2015 - The elephant in the room.

Oh! Please, expound. 


>>
>> I was wondering if anyone could provide me with specific bulletpoint
>> examples of the problems inherent with the current ACL system and how
>> SELinux can mitigate these problems.
> This has been repeatedly described in our published papers and
> presentations as well as many external SELinux resources.  In short form:
>
> DAC:
> - Decisions based only on user identity/ownership.
> - No protection against malicious or flawed applications (every
> application you run has access to everything to which you have access,
> and is free to propagate that access to others).
> - Subject to the whims, carelessness, or maliciousness of every user.
> - Typically only two major categories of users:  superuser or completely
> unprivileged, leading to overprivilege for many processes or weak
> permissions to work around.
>
> MAC, and in particular SELinux:
> - Decisions based on all security-relevant attributes, taking into
> account not only user identity but also active role, the trustworthiness
> and function of the program that is executing (encoded in the domain),
> the clearance of the user, etc.
> - Ability to confine malicious and flawed applications, including even
> ones that run as root.
> - Policy defined by administrator/organization, enforced over all users
> and their programs.
> - Support for fine-grained least privilege, ability to tailor to match
> the specific trustworthiness and function of each component.
>
>
>> Can anyone tell me about the relationship between IEEE 1003.1e/2c and
>> SELinux? 
> Largely none.  That withdrawn draft standard embodied the traditional
> view of Mandatory Access Control and Privileges embodied in the legacy
> trusted operating systems of the past, which is quite different from the
> flexible Mandatory Access Control architecture and Type Enforcement
> model embodied in SELinux.  That flexible MAC architecture and TE model
> were in fact designed to address the shortcomings of such systems.

The MAC component of P1003.1e/2c was sufficient to supply the Bell & LaPadula
model required by the Orange Book (the "traditional" model) but was also
carefully designed to allow for alternative models. One of the members of the
working group wanted to do Biba integrity. A timestamp model was also held up
as a something that had to be supportable. POSIX limits itself to interfaces,
so you can't really read much into what's going on underneath. You could support
the MAC interfaces on Linux (in support of SELinux or Smack) if you were so
inclined.

Capabilities are another story.

> Again, see our published papers and presentations and external SELinux
> resources, e.g.:
> https://www.nsa.gov/research/selinux/background.shtml
> https://www.nsa.gov/research/selinux/docs.shtml
> http://freecomputerbooks.com/The-SELinux-Notebook-The-Foundations.html
> http://seandroid.bitbucket.org/PapersandPresentations.html
>
> Particularly with respect to comparisons with POSIX.1e, you may be
> interested in:
> http://www.securecomputing.com/pdf/secureos.pdf (not about SELinux per
> se, but compares Type Enforcement, which is the core SELinux security
> model, to POSIX.1e capability model)
>
>> Any other interesting nuggets to keep a technical but non security
>> focussed audience interested?
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
>

SELinux talk

[Colin Walters]

Thanks everyone who attended the SELinux talk at Ohio LinuxFest, there
seemed to be a lot of interest from people afterwards about it.

I've put the slides up here:

http://web.verbum.org/selinux/linuxfest/img0.html

Since we ran out of time and couldn't get to any questions, feel free to
ask them here, on one of the mailing lists above.  Thanks again,
hopefully see you next year!





--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.