-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
New article on opensource.com describing SELinux enforcement in simple terms. Check it out.
http://opensource.com/business/13/11/selinux-policy-guide
Daniel J Walsh wrote:
New article on opensource.com describing SELinux enforcement in simple terms. Check it out.
That's... sick. I mean, deeply sick....
mark
That's excellent!
On Wed, Nov 13, 2013 at 3:30 PM, m.roth@5-cent.us wrote:
Daniel J Walsh wrote:
New article on opensource.com describing SELinux enforcement in simple terms. Check it out.
That's... sick. I mean, deeply sick....
mark-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Wed, Nov 13, 2013 at 17:10:43 +0000, Tony Scully tonyjscully@gmail.com wrote:
That's excellent!
The mls case might have been overly simplified. It didn't cover writing, where the dominance goes in the other direction. People might be incorrectly left with the impression the top secret can do everything that secret can do.
On Wed, 2013-11-13 at 11:13 -0600, Bruno Wolff III wrote:
On Wed, Nov 13, 2013 at 17:10:43 +0000, Tony Scully tonyjscully@gmail.com wrote:
That's excellent!
The mls case might have been overly simplified. It didn't cover writing, where the dominance goes in the other direction. People might be incorrectly left with the impression the top secret can do everything that secret can do. --
I agree with you on the danger of oversimplification in generel with regard to explaining SELinux
This is also why i find it sub-optimal to leave the two other default security models out of the equation (RBAC/IBAC)
It is mentioned in the article that SELinux complements Linux security, by briefly touching on IBAC one would clarify at least to some degree how SELinux associates with Linux security
RBAC by itself is worth mentioning in my view, if only to have touched on each security attribute in a security context tuple.
The idea of the illustrated article is nice, but the article is not comprehensive.
Granted, there are constraints. You cannot simply publish a three page article on a medium like this i suspect
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/13/2013 12:35 PM, Dominick Grift wrote:
On Wed, 2013-11-13 at 11:13 -0600, Bruno Wolff III wrote:
On Wed, Nov 13, 2013 at 17:10:43 +0000, Tony Scully tonyjscully@gmail.com wrote:
That's excellent!
The mls case might have been overly simplified. It didn't cover writing, where the dominance goes in the other direction. People might be incorrectly left with the impression the top secret can do everything that secret can do. --
I agree with you on the danger of oversimplification in generel with regard to explaining SELinux
This is also why i find it sub-optimal to leave the two other default security models out of the equation (RBAC/IBAC)
It is mentioned in the article that SELinux complements Linux security, by briefly touching on IBAC one would clarify at least to some degree how SELinux associates with Linux security
RBAC by itself is worth mentioning in my view, if only to have touched on each security attribute in a security context tuple.
The idea of the illustrated article is nice, but the article is not comprehensive.
Granted, there are constraints. You cannot simply publish a three page article on a medium like this i suspect
Maybe a followup that describes RBAC. Not sure how the analogy would work though.
Suggestions welcome.
Dog Role, See Eye Dog Role, Rescue Dog Role.
RBAC is always hard to describe especially when you start defining SELinux Users.
Login User -> SELinux User -> roles -> Types.
The Russian dolls model is the best I have come up with.
On Wed, 2013-11-13 at 13:10 -0500, Daniel J Walsh wrote:
Maybe a followup that describes RBAC. Not sure how the analogy would work though.
Suggestions welcome.
Dog Role, See Eye Dog Role, Rescue Dog Role.
RBAC is always hard to describe especially when you start defining SELinux Users.
Login User -> SELinux User -> roles -> Types.
The Russian dolls model is the best I have come up with.
Yes, that makes things a bit more complicated
because if you want to fully explain it then you also get into the concepts of "automatically transitioning" versus "manually changing"
So for example you want to give the dog the discretion to eat the cat food as the cat ( by associating the cat role (which in turn is associated to the cat type) to the dog identity.
Then if the dog wants to eat the cat food like the cat , he can simply manually change to the cat role with associated cat type
Or you could force the dog to only be able to eat cat food as the cat by making dog automatically role and type transition on the main entry point. That way he can only access cat food as a cat (LOL)
On Wed, 2013-11-13 at 19:35 +0100, Dominick Grift wrote:
On Wed, 2013-11-13 at 13:10 -0500, Daniel J Walsh wrote:
Maybe a followup that describes RBAC. Not sure how the analogy would work though.
Suggestions welcome.
Dog Role, See Eye Dog Role, Rescue Dog Role.
RBAC is always hard to describe especially when you start defining SELinux Users.
Login User -> SELinux User -> roles -> Types.
The Russian dolls model is the best I have come up with.
Yes, that makes things a bit more complicated
because if you want to fully explain it then you also get into the concepts of "automatically transitioning" versus "manually changing"
So for example you want to give the dog the discretion to eat the cat food as the cat ( by associating the cat role (which in turn is associated to the cat type) to the dog identity.
Then if the dog wants to eat the cat food like the cat , he can simply manually change to the cat role with associated cat type
Or you could force the dog to only be able to eat cat food as the cat by making dog automatically role and type transition on the main entry point. That way he can only access cat food as a cat (LOL)
By the way (nit pick):
I do not think that cats and dog interact with cat and dog food respectively
Interaction requires two active entities. dog and cat food are passive entities.
So in my view dogs and cats operate on dog and cat food respectively instead
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/13/2013 12:13 PM, Bruno Wolff III wrote:
On Wed, Nov 13, 2013 at 17:10:43 +0000, Tony Scully tonyjscully@gmail.com wrote:
That's excellent!
The mls case might have been overly simplified. It didn't cover writing, where the dominance goes in the other direction. People might be incorrectly left with the impression the top secret can do everything that secret can do.
Yes I don't think we need to take the analogy too far...
Thanks! Its an interesting approach for SELinux guide/document.
it is a interesting approach...but why tux(kernel/pinguin) has this psycho face, hehe.
On Wed, Nov 13, 2013 at 3:10 PM, Lakshmipathi.G lakshmipathi.g@gmail.comwrote:
Thanks! Its an interesting approach for SELinux guide/document.
--
Cheers, Lakshmipathi.G FOSS Programmer. www.giis.co.in
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
On Wed, Nov 13, 2013 at 4:10 PM, Daniel J Walsh dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
New article on opensource.com describing SELinux enforcement in simple terms. Check it out.
It is often said that people who are concerned with security, and selinux in particular, are too serious and do not know how to describe in simple terms a complex subjects.as selinux (or a MAC system FWIW)
The article shows the opposite. So congratulations
Best
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKDlmQACgkQrlYvE4MpobOjsACfZ4Vtbl8ypCUcN4ofVv/UeeVy /+0AoNGtmaM2Sz2ONX1fOtW/TpTcm2Ob =td+O
-----END PGP SIGNATURE-----
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Dne 13.11.2013 16:10, Daniel J Walsh napsal(a):
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
New article on opensource.com describing SELinux enforcement in simple terms. Check it out.
http://opensource.com/business/13/11/selinux-policy-guide
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlKDlmQACgkQrlYvE4MpobOjsACfZ4Vtbl8ypCUcN4ofVv/UeeVy /+0AoNGtmaM2Sz2ONX1fOtW/TpTcm2Ob =td+O
-----END PGP SIGNATURE-----
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
I believe it is a great introduction to SELinux.
If we give SELinux talks, people want to see a real world analogy which helps them to understand SELinux basics.
Dan, I think now people will want more articles like this one ;-)
On Nov 13, 2013, at 10:10 AM, Daniel J Walsh dwalsh@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
New article on opensource.com describing SELinux enforcement in simple terms. Check it out.
Thank you thank you! Coworkers often trip over SELinux and ask me about it while we sort it out but don't need to know it in detail (for example our VMware folks recently tried out infrastructure navigator and kicked off sealerts from all of our linux VMs). I've been forwarding this a lot and getting great feedback. It's really well done, fun to read, and gives a clear idea of what it's about and why.
Maria
selinux@lists.fedoraproject.org
-
Bruno Wolff III -
Daniel J Walsh -
Dominick Grift -
Lakshmipathi.G -
leo kirotawa -
Maria Iano -
mark -
Miroslav Grepl -
Tony Scully -
yersinia