"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."

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. ;-)