Tag Archives: lsm

LSM Mailing List Being Archived Again

Several folks noticed that all of the known LSM mailing list archives stopped archiving earlier this year.  We don’t know why and generally have not had any luck contacting the owners of several archives, including marc and gmane.  This is a concern, because the list is generally where Linux kernel security takes place and it’s important to have a public record of it.

The good news is that Paul Moore was finally able to re-register the list with mail-archive.com, and there is once again an active archive here: http://www.mail-archive.com/linux-security-module@vger.kernel.org/

Please update any links you may have!

Linux Security Summit 2011 – Presentation Slides

Just over a week ago, the 2011 Linux Security Summit was held in Santa Rosa CA, co-located with Linux Plumbers. It ran for a day, starting with refereed presentations, and then round-table discussions.

The home page for the summit is on the kernel.org wiki, and is currently unavailable, so I’m posting links to the slides here:

* Smack is Alive and Well
Casey Schaufler, Intel

* An Overview of the Linux Integrity Subsystem: Use Cases and Demonstration
David Safford and Mimi Zohar, IBM

* Digital Signature support for IMA/EVM
Dmitry Kasatkin and Ryan Ware, Intel  (presented by Casey)

* Protecting the Filesystem Integrity of a Fedora 15 Virtual Machine from Offline Attacks using IMA/EVM
Peter Kruus, The Johns Hopkins University Applied Physics Laboratory

* Efficient, TPM-free system integrity checking with device mapper: dm-verity
Will Drewry and Mandeep Baines, Google

* The Case for SE Android
Stephen Smalley, NSA

Roundtable discussions:

* Kernel Hardening [no slides]
Lead by Kees Cook, Canonical and Will Drewry, Google

* LSM Architecture
Lead by Kees Cook, Canonical and Casey Schaufler

The SE Android talk was a last minute replacement for Ryan Ware’s talk on MeeGo (Ryan was unfortunately not able to make it).

See the write-ups by by Paul Moore and LWN.

Feedback so far has been positive.  I think it’s valuable for the security developers to get together like this, after spending the rest of the year working remotely with each other.  Next year, we’ll likely be looking at co-locating with LPC/KS/LinuxCon in San Diego.  It may be worth thinking about expanding to a two-day event, with the first day following the same format, but then splitting into project groups on day two for BoFs/hack sessions.

Contact the program committee if you have any suggestions.

I’d like to thank the LPC folk, and especially Jesse Barnes, for allowing us to co-locate and taking care of all of the logistics — all we had to do was organize the talks and turn up.  Also thanks to the speakers, discussion leaders and attendees.  See you next year!

A brief note on the 2.6.30 kernel null pointer vulnerability

This is just to note that the Red Hat Security Response team have issued a preliminary comment on the 2.6.30 kernel null pointer vulnerability, as a comment in the associated bugzilla entry:

From Eugene Teo (Security Response Team)  2009-07-17 07:23:57 EDT

The Red Hat Security Response Team is aware of the Linux kernel local privilege
escalation exploit that is published in a number of security mailing lists and
websites. The flaw identified by CVE-2009-1897 is a null pointer dereference
vulnerability in the tun_chr_poll() function of the Linux kernel, introduced
via the upstream git commit 33dccbb0. This flaw affects kernel versions between
2.6.30-rc1 and 2.6.30-rc3 2.6.31-rc3 , and was addressed via the upstream
git commit 3c8a9c63.

The flaw affects only the Red Hat Enterprise Linux 5.4 beta kernel as the
upstream git commit 33dccbb0 was backported to the kernel as a normal bug fix.
We will be addressing this flaw in a future update to the beta kernel. It is
also possible to mitigate this flaw by ensuring that the permissions for
/dev/net/tun is restricted to root only.

The default SELinux policy, in Red Hat Enterprise Linux 5, allows processes in
the unconfined domains to map low memory in the kernel. The exploit did not
bypass the null pointer dereference protection in the Linux kernel. However, we
are updating the selinux-policy package to change this default configuration,
so that it prevents the unconfined processes from being able to map the low
memory. See bug 511143 for more information.

This issue does not affect any other released kernel in any Red Hat product.

In addition, future updates to Red Hat Enterprise Linux kernels may include the
'-fno-delete-null-pointer-checks' gcc CFLAGS. See:

We would like to thank Brad Spengler for bringing these issues to our

Note that I’m not a member of the security response team: I’m cc’d on the bug and noticed the statement when it was posted.

It is also worth highlighting that you should ensure that the permissions on


are correct.  It should look like this:

# ls -l /dev/net/tun
crw------- 1 root root 10, 200 2009-07-07 09:52 /dev/net/tun

It’s possible that some VPN package may change the permissions on this.

In terms of the SELinux aspect of the exploit, I’ve posted a brief comment in the LWN thread here.

Yes, there was a mistake in the SELinux policy, which allowed the unconfined user to bypass the mmap_min_addr check, which otherwise would have been enforced if the check was enabled (many disable it to get wine etc. working, btw, google disable mmap_min_addr).

This is being fixed in the policy.

The lesson learned here is that more careful review of policy changes needs to happen, and to ask the question as to whether the policy is capable of weakening default security.

The LSM interface is theoretically designed to only allow further restriction of access, but this is a special case, where we are applying policy to a kernel compilation option which can also have its value set via a sysctl. It’s not a typical “access this resource or not?” decision.

The policy bug is now fixed in the selinux-policy-2.4.6-252.el5 package.

The challenge now is to try and ensure that we don’t see this class of problem crop up again, for unusual cases such as this where the normally “restrictive” mode of LSM (i.e. where permissions can only be further restricted) does not apply.  We may need to rethink how this is managed in the kernel to reduce the possibility of such issues in LSM module policy, as the LSM API here appears to be violating the Hard to Misuse design principle.