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
<[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
