LWN: Comments on "LSS: Kernel security subsystem reports"

LSS: Kernel security subsystem reports

nwmcsween — Thu, 04 Oct 2012 09:04:56 +0000

Brad why not play nice and have someone act as an in-between for grsec to lkml? Either that or slowly have the same implementations in grsec / pax extracted and polished to get included, sure there's bureaucracy (yama symlink restricts back and forth and then being merged into vfs). Or if you do it from a business prospective I understand that as well.

LSS: Kernel security subsystem reports

geofft — Sun, 30 Sep 2012 15:55:17 +0000

What happened to the red-letter edition of LWN? :)

LSS: Kernel security subsystem reports

spender — Sat, 29 Sep 2012 14:03:04 +0000

> I wasn't aware that you were calling AppArmor 'new' and claiming precedence over it because it changed its name. Sheesh. Yes, yes, you were first, well done, as long as you ignore another program which had the temerity to change its name at some point in its history. That changes everything, I'm sure. Semantic quibbling.

I used very specific words, which have a very specific meaning. I know, based on your previous arguments, that you feel words are arbitrary and their definitions subject to your own personal whims, but here are the facts:

I said I created real learning for grsecurity 4 years before AppArmor was released. It was released in 2006. It was announced in 2005 during the announcement of discontinuing Immunix OS. Two months later Novell bought Cowan's company (http://archives.neohapsis.com/archives/linux/immunix/2005...), but AppArmor was not released/announced in any available product until 2006. These are just facts.

Furthermore, codomain/subdomain are irrelevant to the discussion of learning, because they didn't have any, or even an audit2allow equivalent. This only began with what they called AppArmor, the utility being called genprof, and again the reason why I told you already you wouldn't be able to find any prior mention of learning. Read for yourself: http://archives.neohapsis.com/archives/linux/immunix/2005...

So there was no need for me to "ignore another program" to claim to be the first. I know it's shocking to you, but "AppArmor" was not just a name change, hence my MS-DOS/Windows reference in the first line of my reply.

So here you have the real facts and evidence straight from primary sources. Do you still prefer the "facts" pulled from your ass?

-Brad

LSS: Kernel security subsystem reports

nix — Sat, 29 Sep 2012 10:10:44 +0000

Ah, so you are now saying... precisely what I said just above, that in fact AppArmor already does implement this and has for ages. Perhaps you'll take back your repulsive personal attacks?

No, I didn't think so.

LSS: Kernel security subsystem reports

nix — Sat, 29 Sep 2012 10:09:45 +0000

Yes, I am aware of its codomain/subdomain history.

I wasn't aware that you were calling AppArmor 'new' and claiming precedence over it because it changed its name. Sheesh. Yes, yes, you were first, well done, as long as you ignore another program which had the temerity to change its name at some point in its history. That changes everything, I'm sure. Semantic quibbling.

A couple lines of perl operating effectively no differently than audit2allow. This is not real learning. It provides no predictive power

Yeah. That's all that it ever did. It never claimed to offer 'predictive power': it's an easy way to put together an initial set of rules based on what programs are actually doing. Providing proper predictive power of course involves automatically analyzing the programs in question and figuring out what they do, which is apt to slam straight into Rice's theorem and even if you avoid that by approximation is going to be terrifyingly unpleasant to write.

you're a hopeless cause: a glib peddler of intellectual dishonesty, arguing for the sake of semantic argument

What a repulsive person you are. Do you normally respond to factual correction with semantic quibbling and vile personal attacks accusing me of precisely what you yourself are doing? (Personal attacks which you'll note I cannot defend myself against, since if your assertions are true nothing I say is worth anything.)

Actually, I've seen you argue here before. Yes, you do revert to vile personal attacks whenever you're losing an argument.

LSS: Kernel security subsystem reports

spender — Fri, 28 Sep 2012 13:07:02 +0000

Replace "Obviously the learning SELinux" in the above with "Obviously the learning AppArmor" (typo).

Investigating further, however: the original article claims AppArmor is trying to create a learning mode similar to audit2allow. This makes no sense to me as it's essentially what they have already. The presentation slides and presenter notes contained at: http://kernsec.org/files/apparmor-update.odp also provide no hints as to the basis for the claim in the article. The only mention of learning is in the context of not dumping their existing "learning" logs through the auditing system. Maybe Jake can clear it up for us.

-Brad

LSS: Kernel security subsystem reports

spender — Fri, 28 Sep 2012 12:54:12 +0000

Do you call Windows MS-DOS too? You said "AppArmor" -- I specifically referred to the release of AppArmor, which was in 2006: https://lwn.net/Articles/166975/

Off-topic: it's also funny to go back and read arguments in posts like this: https://lwn.net/Articles/181508/

Yes, I am aware of its codomain/subdomain history. I'm not sure if you are or if you merely regurgitated information from the Wikipedia page for AppArmor. I urge you, since this entire discussion is about learning modes, to find any reference to a codomain/subdomain learning mode prior to mine in 2002. I can tell you that you won't find one, as this was the state of subdomain's "learning mode" circa 2005:
http://stuff.mit.edu/afs/athena/system/amd64_deb50/os/usr...

A couple lines of perl operating effectively no differently than audit2allow. This is not real learning. It provides no predictive power and thus will require manual intervention to create working policies. Obviously the learning SELinux is trying to match is that within grsecurity, which is significantly more advanced than audit2allow. It knows when to create roles and subjects, when to generalize file and network accesses on a number of levels, learns resource usage, offers simple human-understandable customization based on simple questions like "what resources are sensitive?" For what it's worth, these completely-automated policies have also held up well under formal analysis: http://secgroup.ext.dsi.unive.it/wp-content/uploads/2012/...

This information is more for the other readers really, as you're a hopeless cause: a glib peddler of intellectual dishonesty, arguing for the sake of semantic argument.

-Brad

LSS: Kernel security subsystem reports

nix — Fri, 28 Sep 2012 09:54:40 +0000

Um, you're not seriously claiming that AppArmor was released in 2006, are you? Its first release was in the 1990s.

LSS: Kernel security subsystem reports

spender — Thu, 27 Sep 2012 23:57:14 +0000

Oh, and to clarify, the reason why the capability situation is so ironic is that the SELinux policy developers claim the policies are developed with careful code inspection, yada yada, and yet the cases of granting CAP_DAC_OVERRIDE is something that can only happen in a vanilla kernel (not grsec kernel) using audit2allow to generate policies ;) Whoops!

-Brad

LSS: Kernel security subsystem reports

spender — Thu, 27 Sep 2012 23:47:23 +0000

Grsecurity had the first real learning mode back in 2002, 4 years before AppArmor was ever released.

All these "new" SELinux ideas have me laughing and remembering back to times like in 2006 where a learning mode was considered harmful: http://securityblog.org/brindle/2006/04/02/top-down-vs-bo...

BTW it's funny that for all the "years of development" involved in SELinux policies, they haven't noticed that CAP_DAC_OVERRIDE is a superset of CAP_DAC_READ_SEARCH privilege and have been blindly creating policies and modifying code to add capability support that requires CAP_DAC_OVERRIDE (a full override of DAC) when only CAP_DAC_READ_SEARCH is needed.

It reminds me of the Schopenhauer quote: "All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident."

And again (as the pattern seems to be) upstream is only a decade behind ;)

-Brad

LSS: Kernel security subsystem reports

nix — Thu, 27 Sep 2012 22:27:38 +0000

Beyond that, there are plans to add a "learning mode", similar to SELinux's audit2allow, so that policies can be created from the actions of running programs.

I'm reasonably sure something like this has been in AppArmor for many, many years. Certainly I remember Crispin demonstrating it (for that matter I remember using it).

Did it disappear? Where did it go?

LSS: Kernel security subsystem reports

josh — Thu, 27 Sep 2012 19:44:42 +0000

I wonder if it would make sense to have a libsecret interface to the kernel keyring API?