![]() | |||||||||||||
Messages in this thread |
On Mon, 24 Apr 2006, Casey Schaufler wrote: > > Seems like a strawman. We aren't claiming that SELinux is perfect, > > and there is plenty of work ongoing on SELinux usability. But a > > fundamentally unsound mechanism is more dangerous than one that is > > never enabled; at least in the latter case, one knows where one > > stands. It is the illusory sense of security that accompanies > > path-based access control that is dangerous. > > I suggest that this logic be applied to the "strict policy", "targeted > policy", and "user written policy" presentations of SELinux. You never > know what the policy might be. You are conflating the policies provided with SELinux systems with the mechanisms of SELinux. One of the important features of SELinux is its policy flexibility, with clean separation of policy and mechanism. SELinux provides the mechanisms to control all security relevant access of processes to data, and accesses between processes. It is up to the policy to determine how much of that mechanism is utilized, according to desired security goals. Targeted policy in fact does perform a usability-security tradeoff (as all real security systems must do), aimed at the relatively simple case of protecting systems with a few internet facing services. This is the default policy shipped with _millions_ of Fedora and RHEL systems, and represent, to the best of my knowledge, the first ever releases of general purpose operating systems with MAC enabled by default. The aims and limitations of targeted policy are very well documented. If you wished, you could load a simpler policy which can offer an equivalent level of protection offered by non-MAC schemes such as AppArmor. In fact, some work has been going on more generally in this area in Japan during the last couple of years. Other types of users will want stricter policies, to meet their security goals. The SELinux mechanism is general enough to cater to very high levels of protection and assurance. So, please, consider that the mechanism of SELinux is quite separate from the types of policies which may be deployed. And that arguments regarding SELinux "complexity" often confuse these issues, as well as issues around tools and abstractions presented to users. To make a rough analogy (as Ted mentioned his IETF work earlier...): Network security is a complicated issue, the fundamental nature of which is determined by the protocols, systems and interactions between them. IPsec seeks to provide a robust scheme for protecting a specific set of protocols within a specific range of security goals. If you want to read all of the specifications, you'll find it's very complex (too complex, according to some). Yet, after many years of hard work, it's in widespread use by general users, most of who simply click on a button on their desktop to make it work. You wouldn't expect end users to actually configure IPsec at the lowest levels, and even sysadmins need the right tools and abstractions to effectively and safely deploy the technology (see how far an average sysadmin gets with racoon and its man page). The fundamental mechanisms of IPsec are sound. It has taken many, many years to get it to this stage, despite claims of it being "too complicated". In that time, several "simple" protocols were designed and implemented to address the "complexity" issues, but it turns out, after all, that with the right level of abstraction and tools, IPsec is not too complicated to be secure or to use: by the obvious example of both its widespread adoption and, afaik, no systemic security failures. Similarly: The Linux kernel has a specific level of complexity determined by the nature of its many and varied mechanisms for resource access and communications. SELinux seeks to reveal these and provide a mechanism to control all security relevant interactions, as required. Much work is underway on implementing and improving tools, and ensuring that the abstraction levels are optimal for different classes of users (e.g. end users, developers, sysadmins and security architects). I believe it will not be long until the new SELinux tools provide a much better experience for users, while the underlying security mechanisms will remain sound and capable of meeting a very wide range of security objectives. - James -- James Morris <jmorris@namei.org> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-04-25 09:52 [from the cache] ©2003-2008 | |||||||||||||