Following various unresolved issues with existing mail archives for the Linux Security Modules mailing list, I’ve set up a new archive here.
It’s a mailman mirror of the vger list.
The Linux Security Modules (LSM) API provides security hooks for all security-relevant access control operations within the kernel. It’s a pluggable API, allowing different security models to be configured during compilation, and selected at boot time. LSM has provided enough flexibility to implement several major access control schemes, including SELinux, AppArmor, and Smack.
A downside of this architecture, however, is that the security hooks throughout the kernel (there are hundreds of them) increase the kernel’s attack surface. An attacker with a pointer overwrite vulnerability may be able to overwrite an LSM security hook and redirect execution to other code. This could be as simple as bypassing an access control decision via existing kernel code, or redirecting flow to an arbitrary payload such as a rootkit.
Minimizing the inherent security risk of security features, is, I believe, an essential goal.
Recently, as part of the Kernel Self Protection Project, support for marking kernel pages as read-only after init (ro_after_init) was merged, based on grsecurity/pax code. (You can read more about this in Kees Cook’s blog here). In cases where kernel pages are not modified after the kernel is initialized, hardware RO page protections are set on those pages at the end of the kernel initialization process. This is currently supported on several architectures (including x86 and ARM), with more architectures in progress.
It turns out that the LSM hook operations make an ideal candidate for ro_after_init marking, as these hooks are populated during kernel initialization and then do not change (except in one case, explained below). I’ve implemented support for ro_after_init hardening for LSM hooks in the security-next tree, aiming to merge it to Linus for v4.11.
Note that there is one existing case where hooks need to be updated, for runtime SELinux disabling via the ‘disable’ selinuxfs node. Normally, to disable SELinux, you would use selinux=0 at the kernel command line. The runtime disable feature was requested by Fedora folk to handle platforms where the kernel command line is problematic. I’m not sure if this is still the case anywhere. I strongly suggest migrating away from runtime disablement, as configuring support for it in the kernel (via CONFIG_SECURITY_SELINUX_DISABLE) will cause the ro_after_init protection for LSM to be disabled. Use selinux=0 instead, if you need to disable SELinux.
It should be noted, of course, that an attacker with enough control over the kernel could directly change hardware page protections. We are not trying to mitigate that threat here — rather, the goal is to harden the security hooks against being used to gain that level of control.
The slides are available here: http://namei.org/presentations/linux_kernel_security_linuxconeu2016.pdf
The talk began with a brief overview and history of the Linux kernel security subsystem, and then I provided an update on significant changes in the v4 kernel series, up to v4.8. Some expected upcoming features were also covered. Skip to slide 31 if you just want to see the changes. There are quite a few!
It’s my first visit to Berlin, and it’s been fascinating to see the remnants of the Cold War, which dominated life in 1980s when I was at school, but which also seemed so impossibly far from Australia.
I hope to visit again with more time to explore.
Here’s a summary of the 2016 Linux Security Summit, which was held last month in Toronto.
Presentation slides are available at http://events.linuxfoundation.org/events/archive/2016/linux-security-summit/program/slides.
This year, videos were made of the sessions, and they may be viewed at https://www.linux.com/news/linux-security-summit-videos — many thanks to Intel for sponsoring the recordings!
LWN has published some excellent coverage:
This is a pretty good representation of the main themes which emerged in the conference: container security, kernel self-protection, and integrity / secure boot.
Many of the core or low level security technologies (such as access control, integrity measurement, crypto, and key management) are now fairly mature. There’s more focus now on how to integrate these components into higher-level systems and architectures.
One talk I found particularly interesting was Design and Implementation of a Security Architecture for Critical Infrastructure Industrial Control Systems in the Era of Nation State Cyber Warfare. (The title, it turns out, was a hack to bypass limited space for the abstract in the cfp system). David Safford presented an architecture being developed by GE to protect a significant portion of the world’s electrical grid from attack. This is being done with Linux, and is a great example of how the kernel’s security mechanisms are being utilized for such purposes. See the slides or the video. David outlined gaps in the kernel in relation to their requirements, and a TPM BoF was held later in the day to work on these. The BoF was reportedly very successful, as several key developers in the area of TPM and Integrity were present.
— LinuxSecuritySummit (@LinuxSecSummit) August 25, 2016
Attendance at LSS was the highest yet with well over a hundred security developers, researchers and end users.
Special thanks to all of the LF folk who manage the logistics for the event. There’s no way we could stage something on this scale without their help.
Stay tuned for the announcement of next year’s event!
Refereed presentations include:
See the schedule for the full list of talks.
Also included are updates from Linux kernel security subsystem maintainers, and snacks.
The event this year is co-located with LinuxCon North America in Toronto, and will be held on the 25th and 26th of August. Standalone registration for the Linux Security Summit is $100 USD: click here to register.
You can also follow updates and news for the event via Twitter: @LinuxSecSummit
See you there!
This year, there will be a $100 registration fee for LSS, and you do not need to be registered for LinuxCon to attend LSS .
There’s also now an event twitter feed, for updates and announcements.
If you’ve been doing any interesting development, or deployment, of Linux security systems, please consider submitting a proposal!
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://email@example.com/
Please update any links you may have!
Thanks to all of those who participated, and to all the events folk at Linux Foundation, who handle the logistics for us each year, so we can focus on the event itself.
As with the previous year, we followed a two-day format, with most of the refereed presentations on the first day, with more of a developer focus on the second day. We had good attendance, and also this year had participants from a wider field than the more typical kernel security developer group. We hope to continue expanding the scope of participation next year, as it’s a good opportunity for people from different areas of security, and FOSS, to get together and learn from each other. This was the first year, for example, that we had a presentation on Incident Response, thanks to Sean Gillespie who presented on GRR, a live remote forensics tool initially developed at Google.
Overall, it seems the adoption of Linux kernel security features is increasing rapidly, especially via mobile devices and IoT, where we now have billions of Linux deployments out there, connected to everything else. It’s interesting to see SELinux increasingly play a role here, on the Android platform, in protecting user privacy, as highlighted in Jeffrey Vander Stoep’s presentation on whitelisting ioctls. Apparently, some major corporate app vendors, who were not named, have been secretly tracking users via hardware MAC addresses, obtained via ioctl.
We’re also seeing a lot of deployment activity around platform Integrity, including TPMs, secure boot and other integrity management schemes. It’s gratifying to see the work our community has been doing in the kernel security/ tree being used in so many different ways to help solve large scale security and privacy problems. Many of us have been working for 10 years or more on our various projects — it seems to take about that long for a major security feature to mature.
One area, though, that I feel we need significantly more work, is in kernel self-protection, to harden the kernel against coding flaws from being exploited. I’m hoping that we can find ways to work with the security research community on incorporating more hardening into the mainline kernel. I’ve proposed this as a topic for the upcoming Kernel Summit, as we need buy-in from core kernel developers. I hope we’ll have topics to cover on this, then, at next year’s LSS.
The committee would appreciate feedback on the event, so we can make it even better for next year. We may be contacted via email per the contact info at the bottom of the event page.
In previous years, attending the Linux Security Summit (LSS) has required full registration as a LinuxCon attendee. This year, LSS has been upgraded to a hosted event. I didn’t realize that this meant that LSS registration was available entirely standalone. To quote an email thread:
If you are only planning on attending the The Linux Security Summit, there is no need to register for LinuxCon North America. That being said you will not have access to any of the booths, keynotes, breakout sessions, or breaks that come with the LinuxCon North America registration. You will only have access to The Linux Security Summit.
Thus, if you wish to attend only LSS, then you may register for that alone, at no cost.
There may be a number of people who registered for LinuxCon but who only wanted to attend LSS. In that case, please contact the program committee at lss-pc_AT_lists.linuxfoundation.org.
Apologies for any confusion.