danwalsh


Dan Walsh's Blog

Got SELinux?


Share Next Entry
Linux fragmentation - a view from the Security community
danwalsh
Some History
------------
I have lived the Unix wars over the past 20 years. I worked on Project
Athena back at Digital Equipment (DEC) in the late 1980's and remember
all the effort that it took to make it work on multiple UNIX versions.

We had the best technology at the time. MIT and DEC had awesome
technology including instant messaging (Zephyr), security (Kerberos),
distributed management (Moira), secure file systems with Kerberized NFS
and AFS, shared name service via DNS and Hesiod, and a network windowing
system (X). You could walk up to any machine and log in and have the
same environment. We had single sign-on. We had universities working on
the product. It was a perfect system. But then we decided it need to run
on multiple different Unixes. We spent untold dollars making it work.
The problem was instead of improving the overall product, we spent all
of our time dealing with differences between the platforms. During this
time Microsoft was developing NT group-ware products and ended up
blowing us out of the water. The Unix wars had destroyed a great
product.

Linux consistency refocuses Unix developers
-------------------------------------------
After a few years of working on Microsoft platforms for managing
security infrastructure on Unix and Non-Unix platforms, I came to Linux.
Linux seemed to have corrected the problems of the UNIX wars. It was
community based, all vendors shared the same code and worked together to
build a common platform. Sure, there were multiple competing layered
products, but almost all could run on all the different distributions.
Third party vendors could fairly easily build to a single API and it
worked on everyone's Linux.

Three years ago, I was asked to work on the SELinux Team at Red Hat to
bring Mandatory Access Control to a mainstream operating system (OS).
MAC had been attempted before but had always failed or became a one-off
OS. OS vendors would ship the primary OS and then a "Trusted" version.
This "Trusted" version would quickly become out of date as the main
development efforts would always go into the primary OS and eventually
be ported to the "Trusted" version.

With SELinux we decided we could do both at the same time, using the
Open Source method, we could get multiple companies, and customers
working on it. We had some stumbles along the way, but through the use
of the Fedora Core collaborative development process we came up with a
single OS that uses MAC and handles everything from your laptop to a the
highest levels of security specified by government.

Today we have great technology. We have many companies and government
organizations collaboratively working on SELinux together, including Red
Hat, IBM, HP, NSA, DOD, Tresys, Trusted Computing Systems. We have a
significant open source community built around SELinux, colleges and
universities contributing and doing experiments with it. We have
multiple distributions shipping with SELinux including Fedora Core
(2,3,4 and soon 5), Red Hat Enterprise Linux 4, Gentoo, Debian, Ubuntu,
Suse and Slackware.

Security Deja Vu
----------------
Everything seems to be going great, but ... Novell, who last year
claimed to be the first Linux distribution to ship with SELinux
technology, suddenly announced that they are dropping support for it. To
replace it, they bought a product called AppArmor and are now asking
third party developers to use it instead of SELinux. Is this the
beginning of the Unix wars all over again?

Not only is AppArmor divergent from upstream/community, but it is also not
suitable as a real alternative to SELinux, because it lacks the flexibility
and scalability of SELinux to address the full range of security concerns,
and its limitations are not just in implementation but architectural.

Novell claims that AppArmor is easier to use for third parties. But now
users and developers have to choose one or the other mechanism for
providing MAC, and ignore the other platform's security mechanism. Or do
twice as much work, to support both. Think back to the Project Athena
example. Is this easier? Couldn't Novell have spent their money on
making SELinux easier to use? No, Novel chooses to split the user and
developer community. I am not sure what their goals are, but I feel this
hurts Linux and the open source movement. The community has now gotten
SELinux to the point where "easier" is coming, but built upon a solid
foundation.

My fear now is that the Linux OS community has given application
developers an excuse to support neither security infrastructure, because
supporting either of them would prevent their product from running in
the other environment. So, for a developer, supporting neither SELinux
or AppArmor is the cheapest alternative, and maximizes the potential
customer base.

Instead of leveraging collaborative open source development to make
Linux the most secure operating system in the world, the now fragmented
Linux security community will be doing battle over who has the prettier
GUI. And the ISV community will ignore us.

Conclusion
-----------
The best outcome would be to have Novell work with the SELinux/open source
community to bring the benefits of AppArmor to the architecture/infrastucture
that is SELinux. This collaboration would benefit the entire Linux community.

Re: I prefer AppArmor's approach.

(Anonymous)

2006-02-18 01:23 am (UTC)

I know the potential of SELinux's ability. But I think SELinux's approach is not user friendly. I want SELinux to consider pathname-based approach to become more user friendly.

> Labeling the inodes with the security attributes and then using those security labels for the permission checks is the only approach to provide real enforcement of confidentiality and integrity guarantees,
Why do we have to worry that security labels are kept correctly assigned? Fedora Core introduces a cron job to check security labels are kept correctly assigned, for there is a possibility of existence of a moment that security labels are incorrectly assigned. At the moment when security labels are incorrectly assigned, how SELinux (or any inode's security-label-based MAC) can provide real enforcement?

> A single file may be accessible under multiple distinct paths,
TOMOYO Linux uses canonicalized absolute pathname that contains no "//", ".", ".." and symbolic links (unlike AppArmor) to ensure a single file with link-count = 1 is accessed under unique pathname.
A file need to be accessible under it's link-count's ways of paths because the file is designed to allow access under multiple distinct paths.

>each process can have its own distinct namespace (view of the filesystem tree),
TOMOYO Linux ignores each process's "/" directory (unlike AppArmor). (Even if a process is running under chroot()'ed environment, TOMOYO Linux derives canonicalized absolute pathname from outside the chroot()'ed environment.)

Please understand what you are breaking

illiterat

2006-02-24 10:19 pm (UTC)

TOMOYO Linux uses canonicalized absolute pathname that contains no "//", ".", ".." and symbolic links (unlike AppArmor) to ensure a single file with link-count = 1 is accessed under unique pathname. A file need to be accessible under it's link-count's ways of paths because the file is designed to allow access under multiple distinct paths.

So, a file with link count > 1 has multiple security policies ... depending on the name used to access it. Unix has never done this, and it is mostly completely insanity.

each process can have its own distinct namespace (view of the filesystem tree),
TOMOYO Linux ignores each process's "/" directory (unlike AppArmor). (Even if a process is running under chroot()'ed environment, TOMOYO Linux derives canonicalized absolute pathname from outside the chroot()'ed environment.)

Please learn what namespaces are, it has nothing to do with chroot(). There is not a static canonical name for even a file with link count == 1, when you have namespaces.

That's not to say some path name analysis wouldn't be useful (allowing the webserver to serve anything accessed from /home/*/public_html without having to label files comes to mind or allow access to all files in /home/* is an obvious application), but it certainly can't be the only way to specify security.


Re: Please understand what you are breaking

(Anonymous)

2006-02-27 11:45 pm (UTC)

Probably my explanation was incorrect.

TOMOYO Linux uses canonicalized absolute pathname that contains no "//", ".", ".." and symbolic links (unlike AppArmor) to ensure a single file with link-count = 1 is accessed under unique pathname. A file need to be accessible under it's link-count's ways of paths because the file is designed to allow access under multiple distinct paths.

was inappropriate. This should be

TOMOYO Linux uses canonicalized absolute pathname that contains no "//", ".", ".." and symbolic links (unlike AppArmor) so that the policy can specify a single file with link-count = 1 using 1 pathname. TOMOYO Linux's policy can specify a single file with link-count > 1 using it's link-count's ways of pathnames.



> So, a file with link count > 1 has multiple security policies ... depending on the name used to access it. Unix has never done this, and it is mostly completely insanity.
There are program files with link-count > 1. For example, busybox.
Why it is insanity to granting/rejecting access depending on the name used to access?
The busybox should be controlled depending on the name used to access, shouldn't it?



> Please learn what namespaces are, it has nothing to do with chroot(). There is not a static canonical name for even a file with link count == 1, when you have namespaces.
I'm sorry but I couldn't understand what you want me to figure out.
TOMOYO Linux controls access using canonicalized absolute pathname.
The canonicalized absolute pathname is derived based on the dynamic mount situation.
So, there is not a static canonicalized absolute pathname for a file.
TOMOYO Linux doesn't ensure that only resources whose security labels match the ones in the policy file are accessible.
TOMOYO Linux just ensures that only resources whose (dynamically derived) canonicalized absolute pathnames match ones (taken from a snapshot) in the policy file are accessible.

You are viewing danwalsh