Memory protections followup
Following up on a couple of the comments on my last entry on SELinux memory protections vs. Zend Optimizer:
The policy does indeed look like it was generated automatically by audit2why or similar. This very clearly highlights a core problem with “learning mode” security schemes, which can blindly encapsulate dangerous behavior in a buggy application, or even an attack in progress. This issue was previously expounded by Josh Brindle in Status Quo Encapsulation.
Such techniques do have their place, although it is always recommended that such resulting policy be reviewed. Again, it is easy to find help.
It’s unfortunate that some vendors promote automated policy generation schemes as a core usability feature, leading many people to assume that this is a great idea, and even the way things are supposed to work.
Of course, nobody would ever capitalize on peoples’ combined fear and lack of expertise in an area and sell a “miracle” solution which doesn’t quite work. No, that would never happen.
As H.L. Mencken and some character on the single episode of CSI I suffered through said: “… there is always an easy solution to every problem — neat, plausible and wrong.”.
The idea that the problem of OS security can be solved effortlessly with the click of a mouse should be raising alarm bells in everyone’s heads by now, surely ?