Linked by Thom Holwerda on Wed 5th Mar 2008 09:43 UTC, submitted by diegocg
Sun Solaris, OpenSolaris "OpenSolaris has launched a new project, Flexible Mandatory Access Control, to integrate the Flask/TE security scheme into their OS. This is the same underlying model implemented by SELinux, and follows other cross-platform Flask/TE integration projects such as SEDarwin and SEBSD. This is very exciting in terms of establishing compatible security across operating systems, particularly for Mandatory Access Control, which has traditionally been narrowly focused and generally incompatible. With FMAC, we're closer to seeing truly ubiquitous, cross-platform MAC security."
Order by: Score:
Trusted Solaris?
by Bitterman on Wed 5th Mar 2008 11:29 UTC
Bitterman
Member since:
2005-07-06

I thought they already had trusted Solaris?
This was developed by the NSA why not port SElinux?
Is Selinux fundamentally flawed?

Reply Score: 1

RE: Trusted Solaris?
by Redeeman on Wed 5th Mar 2008 12:03 UTC in reply to "Trusted Solaris?"
Redeeman Member since:
2006-03-23

Well lets just say that theres a reason we dont all wave SELinux flags... ;)

Reply Score: 6

RE[2]: Trusted Solaris?
by Bitterman on Wed 5th Mar 2008 13:22 UTC in reply to "RE: Trusted Solaris?"
Bitterman Member since:
2005-07-06

like what? any technical faults?
The only bad things about SElinux I hear are due to difficulty in rule building which although isn't meant for a joe desktop user the new building tools should be easy enough for a system admin to learn.
Mainly im trying to see what advantages this has over the current system.

Reply Score: 1

RE[3]: Trusted Solaris?
by sbergman27 on Wed 5th Mar 2008 13:47 UTC in reply to "RE[2]: Trusted Solaris?"
sbergman27 Member since:
2005-07-24

Well, the 12% (on x86 for reads) to 147% (on SH series processors for writes, and no that's not a typo) cpu overhead of SELinux is rather significant. (And that impacts heat dissipation and battery life as well, of course.) Not sure how this new OpenSolaris implementation will compare. I think the overhead is supposed to be somewhat lower in Linux kernel 2.6.24. We'll see, I guess.

My understanding is that one pays a performance overhead even with selinux "disabled", unless he manually adds "selinux=0" to the kernel boot params AND the option for SELinux to honor that boot param has been compiled in.

Edited 2008-03-05 13:58 UTC

Reply Score: 6

RE[4]: Trusted Solaris?
by Bitterman on Wed 5th Mar 2008 14:35 UTC in reply to "RE[3]: Trusted Solaris?"
Bitterman Member since:
2005-07-06

woh thanks i had never heard that but i'll take your word for it. that is a pretty bad performance hit. Personally i'll still deal with it cause i want some security infrastructure to get adopted. Open source has way, way too many programs on a machine. I mean look at debians repo's you got 20,000 different applications. That is ALOT of security bugs waiting to be found or already found and being exploited. There needs to be a wrapper in the middle to protect the machine from poor code. Weather it be Selinux or another type of MAC system, or stack protection I dont know or care, but there needs to be something between poor code and free reign of a machine. for now SElinux appears to be the one with the most active development and adoption.

Reply Score: 1

RE[5]: Trusted Solaris?
by Method on Wed 5th Mar 2008 15:20 UTC in reply to "RE[4]: Trusted Solaris?"
Method Member since:
2006-05-15

Those performance numbers came from a developer who made a patch that reduces it down to 1% and 11% (x86 and SH respectively) (http://marc.info/?l=selinux&m=118906566911337&w=2). The patch and those numbers were in the very same email so the poster knew of the effort to address it. Linux 2.6.24 has those patches so the performance issue is now addressed. This specific issue was only on file read/write revalidation.

Edited 2008-03-05 15:29 UTC

Reply Score: 1

RE[6]: Trusted Solaris?
by sbergman27 on Wed 5th Mar 2008 15:38 UTC in reply to "RE[5]: Trusted Solaris?"
sbergman27 Member since:
2005-07-24

The patch and those numbers were in the very same email so the poster knew of the effort to address it. Linux 2.6.24 has those patches so the performance issue is now addressed.


Which is why I mentioned that things were supposed to be better in 2.6.24 in my post. Why so defensive? Why is it that one cannot point out problems, costs, and limitations of SELinux without drawing such ire?

Anyway, I'll also point out that no current production distro has these patches, and that RHEL will likely not have them for about a year.

The Fedora Core 5 SELinux FAQ (the latest available) claims a 7% penalty overall (presumably for x86) but notes that the benchmark was old and that the overhead had probably increased due to changes in networking code. It is fair to say that as of now, and stretching back the last few years, SELinux exacts, and has exacted, a significant performance penalty. And that's not even considering the fact that when I log into my Fedora 8 desktop with SELinux enabled, the 3rd largest consumer of memory on the system is sealert.

I wish SELinux advocates would be a little more candid about the true costs of SELinux, rather than admitting to issues only after there is a fix available.

Edited 2008-03-05 15:49 UTC

Reply Score: 2

RE[4]: Trusted Solaris?
by PlatformAgnostic on Wed 5th Mar 2008 17:09 UTC in reply to "RE[3]: Trusted Solaris?"
PlatformAgnostic Member since:
2006-01-02

Any idea why the cost is so high?

On Windows, we do the expensive security check when you open a handle (aka fd) and you are granted tbe desired rights until you close the handle. There is a cost when using handles of checking that the handle has been given the right needed for each operation, but it's a single AND and a comparison that happens in the handle table lookup codepath.

What does SELinux do that is more expensive?

Reply Score: 3

RE[5]: Trusted Solaris?
by sbergman27 on Wed 5th Mar 2008 18:20 UTC in reply to "RE[4]: Trusted Solaris?"
sbergman27 Member since:
2005-07-24

Any idea why the cost is so high?

In this case, apparently it was checking more frequently than necessary. From the email that Method and I were looking at:

I found a overhead in selinux_file_permission function.
This is a function that is called in read/write calls,
and does SELinux permission check.
SELinux checks permission both in open and read/write time.
Stephen Smalley sugessted that we can usually skip permission check
in selinux_file_permission.
By this patch,
permission check in selinux_file_permssion is done only when
- sid of task has changed after file open
- sid of inode has changed after file open
- policy load or boolean change happen after file open

Just how much work has actually gone into optimizing SELinux performance is unclear to me. The Fedora Core 5 SeLinux FAQ, which is the latest available, has this to say:

SELinux performance tuning continues to be a priority of the development team.

The "Unofficial SELinux FAQ" says:

Currently, the performance overhead is approximately 7%. There has been little effort to date to optimise the SELinux code for performance, and in some cases such as networking the impact may be higher. The SELinux development team is looking at improving performance. If you set "selinux=0" as a kernel boot option, SELinux will have no performance impact.

There has been quite a bit of work on the performance of SE Linux. In early 2005, SE Linux was optimised for machines with 32 or more CPUs. Recently changes have been made to the kernel code to reduce memory use (not in kernel.org or distribution kernels yet).

So, based upon that, while there has been little effort to date to optimize SELinux code for performance, there has been quite a bit of work on the performance of SE Linux. But those of us unfortunate enough to have fewer than 32 cores are SOL in any case. ;-)

The official SELinux FAQ is mum on the issue.

Edited 2008-03-05 18:32 UTC

Reply Score: 3

RE[5]: Trusted Solaris?
by Method on Wed 5th Mar 2008 18:20 UTC in reply to "RE[4]: Trusted Solaris?"
Method Member since:
2006-05-15

Any idea why the cost is so high?

On Windows, we do the expensive security check when you open a handle (aka fd) and you are granted tbe desired rights until you close the handle. There is a cost when using handles of checking that the handle has been given the right needed for each operation, but it's a single AND and a comparison that happens in the handle table lookup codepath.

What does SELinux do that is more expensive?


It use to revalidate read/write perms on every read and write so that if access were revoked, due to file relabeling, policy reload, an open file descriptor being passed to a domain that did not have read/write access or policy boolean change the access would be denied.

Now it still supports that but doesn't have to consult the policy each time because it keeps the policy sequence number, which is incremented and keeps track of relabels.

This is different than most other implementations because we wanted to support revocation and wanted to be able to fully understand, via policy, what domains could access what files. Unfortunately we can't fully support revocation due to the ability to mmap() files.

Edited 2008-03-05 18:24 UTC

Reply Score: 2

RE[6]: Trusted Solaris?
by PlatformAgnostic on Fri 7th Mar 2008 02:42 UTC in reply to "RE[5]: Trusted Solaris?"
PlatformAgnostic Member since:
2006-01-02

The revocation issue is interesting and one that is totally unsupported by Windows in the current incarnations. It could be implemented for all kernel securable objects, however, without breaking the driver ABI(I've got a way in mind).

Application compatibility, on the other hand, would suffer greatly. And it would create the risk of data loss and mysterious failures when an application can open a file successfully with write access but then fails to write due to asynchronous changes to the ACL. As a practical matter, do these revocations work? Is it easy for an administrator to do it through the tools available, or is this just a theoretical capability of the system?

Reply Score: 2

RE[4]: Trusted Solaris?
by danieldk on Wed 5th Mar 2008 19:11 UTC in reply to "RE[3]: Trusted Solaris?"
danieldk Member since:
2005-11-18

Well, the 12% (on x86 for reads) to 147% (on SH series processors for writes, and no that's not a typo) cpu overhead of SELinux is rather significant.


That's a too unbalanced statement. 12% overhead on what? As far as I know, the overhead is on certain system calls. Most CPU-intensive applications will relatively only spend very little time in system calls. So, overall, the impact is not that much, while it does give much more security. Seems like a fair trade-off to me.

Reply Score: 2

RE: Trusted Solaris?
by Method on Wed 5th Mar 2008 13:25 UTC in reply to "Trusted Solaris?"
Method Member since:
2006-05-15

It is a port of SELinux. Specifically a port of the pre-GPL version.

Trusted Solaris has been abandoned for various reasons (it was always way behind Solaris, hard to maintain, etc) and not all Sun customers were happy with trusted extensions.

Edited 2008-03-05 13:26 UTC

Reply Score: 2

RE[2]: Trusted Solaris?
by binarycrusader on Wed 5th Mar 2008 14:12 UTC in reply to "RE: Trusted Solaris?"
binarycrusader Member since:
2005-07-06

It is a port of SELinux. Specifically a port of the pre-GPL version.

Trusted Solaris has been abandoned for various reasons (it was always way behind Solaris, hard to maintain, etc) and not all Sun customers were happy with trusted extensions.


I don't know where you got your information, but it is wrong.

Contrary to your assertion that Trusted Solaris was abandoned, all of its technology has instead been integrated into the main release. In addition, if you actually take the time to read many discussions on opensolaris.org about the Trusted Extensions it brought, you would see that government customers especially liked them.

So, I assert that your source of information needs review.

Edited 2008-03-05 14:21 UTC

Reply Score: 7

RE[3]: Trusted Solaris?
by Method on Wed 5th Mar 2008 14:55 UTC in reply to "RE[2]: Trusted Solaris?"
Method Member since:
2006-05-15

I don't know where you got your information, but it is wrong.

Contrary to your assertion that Trusted Solaris was abandoned, all of its technology has instead been integrated into the main release. In addition, if you actually take the time to read many discussions on opensolaris.org about the Trusted Extensions it brought, you would see that government customers especially liked them.

So, I assert that your source of information needs review.


Right, So Trusted Solaris technology hasn't been integrated into the main release. One of the main things that was dropped from Trusted Solaris is fine grained labeling (which some Sun people claim is unnecessary). Trusted Extensions simply does not do the same thing that Trusted Solaris did. I have personal knowledge of ex-Sun customers that found Trusted Extensions inadequate for their uses.

Granted many components of Trusted Solaris has been brought into Trusted Extensions (e.g., trusted X, labeled networking, etc). I may have been a little harsh by saying 'abandoned' and for that I apologize.

Reply Score: 3

RE[4]: Trusted Solaris?
by binarycrusader on Wed 5th Mar 2008 16:12 UTC in reply to "RE[3]: Trusted Solaris?"
binarycrusader Member since:
2005-07-06

"I don't know where you got your information, but it is wrong.

Contrary to your assertion that Trusted Solaris was abandoned, all of its technology has instead been integrated into the main release. In addition, if you actually take the time to read many discussions on opensolaris.org about the Trusted Extensions it brought, you would see that government customers especially liked them.

So, I assert that your source of information needs review.


Right, So Trusted Solaris technology hasn't been integrated into the main release.
"

No, technology from Trusted Solaris has been integrated into the main release. Maybe not the GA release yet (though I thought it was) though.

One of the main things that was dropped from Trusted Solaris is fine grained labeling (which some Sun people claim is unnecessary). Trusted Extensions simply does not do the same thing that Trusted Solaris did. I have personal knowledge of ex-Sun customers that found Trusted Extensions inadequate for their uses.


Regardless of personal knowledge of such things, it's hardly news that some folks find certain technology inadequate for their uses. Some people like things, some don't. Some people have their needs met, some don't.

Just as many people find SELinux inadequate for their needs. I certainly do. I absolutely despise SELinux and believe it to be the worst thing ever. Maybe the concept is great, but the implementation in most GNU/Linux distributions is horrid and unusable.

Granted many components of Trusted Solaris has been brought into Trusted Extensions (e.g., trusted X, labeled networking, etc). I may have been a little harsh by saying 'abandoned' and for that I apologize.


That was my main point. Sun engineers took the "best of breed" technology from Trusted Solaris and integrated it. Trusted Solaris, to the engineers, was really just Solaris + Trusted Extensions from what I've been told.

Reply Score: 3

RE[4]: Trusted Solaris?
by Elektronkind on Fri 7th Mar 2008 01:21 UTC in reply to "RE[3]: Trusted Solaris?"
Elektronkind Member since:
2006-09-22

The Trusted Solaris extensions got integrated into Solaris with Solaris 10 Update 3.

I know this well because I had to fix the Solaris OpenAFS client driver because it directly molested a cred_t and the TS integration changed the size of that Private struct, and that broke binary compatibility in OpenAFS driver. ddi_cred(9F) to the rescue... that's what OpenAFS should have used in the first place.

Yes, Method needs to get his/her sources straight. Binarycrusader is correct. "Trusted Solaris" ceased being a separate product and its functionality was folded into Solaris 10 proper. This is why you don't see a "Trusted Solaris 10" product... because it is Solaris 10.

Edited 2008-03-07 01:25 UTC

Reply Score: 2

RE: Trusted Solaris?
by spikeb on Wed 5th Mar 2008 14:48 UTC in reply to "Trusted Solaris?"
spikeb Member since:
2006-01-18

from what i can tell, they are implementing what one could call SESolaris...so it's not exactly a matter of what is wrong with selinux - this seems to be that, for solaris

Reply Score: 4