LSS: Kernel security subsystem reports
LSS: Kernel security subsystem reports
Posted Sep 28, 2012 9:54 UTC (Fri) by nix (subscriber, #2304)In reply to: LSS: Kernel security subsystem reports by spender
Parent article: LSS: Kernel security subsystem reports
Posted Sep 28, 2012 12:54 UTC (Fri)
by spender (guest, #23067)
[Link] (4 responses)
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:
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
Posted Sep 28, 2012 13:07 UTC (Fri)
by spender (guest, #23067)
[Link] (1 responses)
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
Posted Sep 29, 2012 10:10 UTC (Sat)
by nix (subscriber, #2304)
[Link]
No, I didn't think so.
Posted Sep 29, 2012 10:09 UTC (Sat)
by nix (subscriber, #2304)
[Link] (1 responses)
Actually, I've seen you argue here before. Yes, you do revert to vile personal attacks whenever you're losing an argument.
Posted Sep 29, 2012 14:03 UTC (Sat)
by spender (guest, #23067)
[Link]
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
http://stuff.mit.edu/afs/athena/system/amd64_deb50/os/usr...
LSS: Kernel security subsystem reports
LSS: Kernel security subsystem reports
LSS: Kernel security subsystem reports
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.)
LSS: Kernel security subsystem reports