This Internet-Draft outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into NFSv4.1 . It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. It also gives a brief explanation of what kinds of protections MAC systems offer and why existing NFSv4 protection mechanisms are not sufficient.
This draft is a generalization the original Security Enhanced NFS document posted last year, addressing the general need for mandatory access control support in NFS.
NFSv4 currently supports two access control schemes: standard DAC and ACLs. MAC labeling support is required for technologies such as SELinux and OpenSolaris FMAC.
Essentially what's needed is a way to convey MAC labels over the wire (for both setting and retrieving their values), and to be able to enforce security policy using those labels. The server needs to be able to determine the security label of the remote client process when enforcing policy, and all systems need to be able to ensure they understand each other's labels, or be able to translate them. A "Domain of Interpretation" (DOI) attribute is used to determine the meaning of labels, a term which may be familiar to those who've braved the IPsec specifications. The confidentiality and integrity of these security attributes must be protected in transit, while all parties need to be authenticated. We also need to be able to handle the case where either the client or server does not have MAC enabled, and to ensure non-breakage with existing implementations. There's a lot more in the details, but that's the gist of it.
It may seem at first glance that NFSv4 named attributes (NAs) would provide the required labeling functionality, but they're not a good fit. NAs are specifed as opaque to the system and user-managed, while MAC security labels are managed by the system. NAs also do not provide necessary semantics such as conveying client security attributes or negotiation of DOI. There are also issues with attribute namespaces (which are user-managed and unspecified) and labeling atomicity. Another possible approach is to implement Linux/BSD-style extended attributes (EAs), which are simple text string attributes associated with files, in contrast with the NA "subfile" scheme. This would potentially only solve the attribute namespace issue, and is also not a good general solution. EAs are also not currently part of the NFSv4 specification, and it seems like a contentious area in any case.
The current Labeled NFS prototype code utilizes NFSv4 recommended attributes (RAs), which are fully extensible, already exist, and are already used for similar management of metadata (e.g. ACLs). This seems to be the simplest and most straightforward approach.
Once there's consensus on the requirements, the next step will be to develop a protocol specification and hopefully have it incorporated into NFSv4. v4.1 is currently in "last call", so the next candidate would be v4.2, it seems. The prototype code for Linux/SELinux will continue to be developed alongside the standards process.
For those interested in following or contributing to the project, there are several relevant mailing lists:
2008 SELinux Developer Summit Schedule Now Up We managed to get the SELinux developer summitschedule published a few days early. Hopefully, this will help people who are making travel arrangements to OLS.
As mentioned, a lot of high quality proposals were submitted. To ensure that all important topics can be covered, the format of the summit has been changed to moderated discussion panels with presentations; rather than the original plan of having a set of fixed-length presentations followed by discussion panels.
Presentations will now be 10-20 minutes, with a greater focus on discussion. This provides much more flexibility, and is derived somewhat from experience with the kernel networking summit, which has been very successful with short presentations driving discussions.
All SELinux developers and folk with a technical interest in SELinux and related technologies are welcome to attend. Don't forget that you also need to be registered to attend OLS.
Relatedly, I just read Spot's report on attending FISL in Brazil. Sounds like it was an exciting and productive event. With over 7000 attendees, I wonder if this was the largest FOSS conference ever?
As suspected, most of the proposals arrived at the last possible moment. It looks like we have more proposals than can reasonably fit in one day, so the organizing team now has the interesting task of squeezing as much in as possible without overloading the schedule. This is going to be very difficult, as pretty much all of the submissions are of excellent quality.
In any case, we should have the schedule finalized and published within a week or so.
If you've been working on something interesting, there are some slots still open for the informal 30-minute talks. We're also accepting suggestions for discussion topics and panels.
Send your ideas/proposals to the organizing team: selinux-summit-team AT namei.org
SELinux Developer Summit 2008 Announced We've just announced the SELinux Developer Summit for 2008, which will be held in Ottawa (as an OLS mini-summit) on July 22nd. A CfP will be issued early next week, where we'll be looking for people to submit talks and panel topics.
In previous years, the project has had the SELinux Symposium, generously run by Tresys, with an invite-only developer summit tacked onto the end.
The new Developer Summit is intended to track with the evolution of SELinux as a wider community project, and we are very pleased to be able to hold an open event this year in conjunction with OLS.
All developers and folk with a strong technical interest in SELinux and related Flask/TE projects are encouraged to attend. Note that attendees need to also be registered for OLS.
There'll be more information on the CfP and schedule soon -- this is something of a heads up for those planning travel and who may be wish to start thinking about presentation and discussion topics.
So, there'll be quite a lot of SELinux content at OLS, some of which I've previously mentioned. To summarize, in addition to the Developer Summit, there'll be:
So, if you're involved with SELinux or otherwise interested in it, I'd suggest flying, driving, walking or swimming (I'm pretty sure this is possible) to Ottawa this July.
There are quite a lot of security-related items this year, with several covering SELinux. I've had a talk accepted on the general state of the SELinux project. If you can read Japanese, see Yuichi Nakamura's blog entry (he's presenting on SELinux in consumer electronics).
We're hoping to hold an SELinux developer event in conjunction with OLS. Hopefully there'll be more to say on that soon.
It's interesting to see so many Indian flags next to speakers' names this year. No doubt related to the enthusiastic efforts of the grassroots community in India as evidenced by FOSS.IN and the growing number and scope of regional conferences.
A quick google returns regional conferences this year in Delhi, Calicut, Chennai and Pune. I probably missed some. A few of them happen around the same time (February or so ) and if its similar next year, then there's scope for folk who are interested in both traveling around India and in FOSS to do some kind of geek tour -- on PTO, I'd imagine, unless your management is epically cool.
It's great to see other distributions adopting SELinux. I'm anticipating that the Ubuntu community will bring in fresh ideas and perspectives based on their overall focus on usability.
SELinux has always been an entirely open project and it was never intended to be specific to any particular distribution or company (a perception which unfortunately has emerged in recent times). Hopefully, adoption by Ubuntu (and others) will help to dispel such myths, including the myth that SELinux is difficult to use. It would be unrealistic not to expect a few teething problems in Ubuntu, but experience with Fedora has shown that they can be fixed, and that stronger security can be made highly usable in the general case.
Something interesting to consider is that with SELinux support, Ubuntu is now a potentially LSPP/EAL4+ certifiable distribution. As many will know, such certifications are important requirements for significant classes of government and military procurement, and we are also seeing some such users moving exclusively to open systems.
Side note: it seems that there'll be some SELinux talks and events at OLS: nothing official quite yet, but keep your calendars open!
What is Security Enhanced PostgreSQL ? Good overview from Kaigai Kohei, with cute diagrams.
Schneier blogs about the future of security as a standard feature, eliminating the "best of breed vs suites" decision:
That they're forced to spend money on IT security is an artifact of the youth of the computer industry. And sooner or later the need to buy security will disappear.
It will disappear because IT vendors are starting to realize they have to provide security as part of whatever they're selling.
Interesting article, but the concept of shipping security features by default is significantly established and even pioneered within FOSS. For example, the idea that mandatory access control could be enabled by default, in a general purpose OS, was I think unheard of until SELinux was released as a standard part of Fedora.
Linux systems have many best of breed security features available as standard, typically for free: firewalling, PAM, OpenSSH (thanks OpenBSD folk), binary protection, code review, vulnerability response, audit, crypto, network stack hardening, and so on. The inclusion of such features as standard, rather than expensive, layered products with vendor lock-in written all over them, is itself an innovation in computer security. An innovation which is being adopted by major OS vendors.
I was surprised to see Bruce interviewed a few months back, being asked what he thought Linux had contributed to security, and to see him answer something along the lines of merely raising the bar for Windows. That may be true to an extent, but I think he seems to underestimate (or not understand) the direct value provided now to the millions of systems running Linux, many of which are running all kinds of critical workloads. We're talking stock exchanges, large banking systems, Google, telephone exchanges, cell phones, supercomputers, file and print servers, much of the web, mail servers, routers, hospitals, military, government, and almost anything you can think of. FOSS achievements stand alone, and frankly, have enabled progress which simply would otherwise not have occurred.
For those who may have missed it, Linuxworld covered SELinux mitigation of vulnerabilities. I was interviewed for this, which I think is the first time I've been interviewed for a magazine.
Government Computer News has coverage of the Labeled NFS effort on its front page today. Dave Quigley presented on the topic this week at IETF 71 -- it'll be very interesting to see how that turned out, as IETF acceptance is a critical requirement for the project.
This is very exciting in terms of 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.
I'll be interested to see how they approach the integration, with the opportunity to learn lessons from the SELinux experience.
It'll also be great to have an expanded TE/Flask community. According to their project page, areas of work include improving usability (we can never have enough of that), desktop integration via XACE, integration with Xen (presumably via XSM), Labeled NFS, and Labeled IPSec. It seems they already have a separate project for the latter, txipsec.
I'll be watching with great interest, and would like to offer any assistance in ensuring interoperability with SELinux.
$100k FIPS-140 certification vs. $19.95 Amazon purchase of Scrubs DVD My morning email slog was greatly enhanced by some choice quotes from Peter Gutmann on the IETF Security Area Advisory Group list:
Compare this to the example I gave earlier of performing a TLS exchange with Amazon. This performs an in-depth test of all the crypto algorithms (corresponding to the FIPS algorithm tests, including ones that FIPS ignores), and the crypto mechanisms (many/most of which FIPS again ignores). In other words simply by connecting to Amazon using TLS and ordering a "Scrubs" DVD for $19.95 I'm getting more comprehensive algorithm testing than I can for a five-figure sum with the FIPS algorithm tests.
This was based on a FIPS-140 crypto certification costing $100,000 (which was challenged in a followup as costing a mere $30,000).
He then describes what he believes would be a better way to use the $100k in assuring a crypto product, including the purchase of a $45k home theater system, beer, and setting a up fake banking web site as a honeypot to attract Russian mafia.
The Linux Foundation does not speak for me I'd like to say, somewhat for the sake of the OpenSolaris folk who are currently having a bit of a rough time, that I personally strongly disagree with certain statements coming out of the Linux Foundation, such as those claiming that the "L in LAMP is literal". [1]
Of course, LAMP has long been representative of the concept of a free software stack. The term itself has been tremendously useful as a means to identify an open approach to developing and deploying systems. The L does of course not have to mean Linux any more than the P needs to mean PHP or Perl. Aside from OpenSolaris, there are many good choices for operating systems in an open stack, such as OpenBSD.
While LF is an industry consortium representing several companies and organizations with various interests in Linux, it certainly does not generally represent the Linux community.
As a Linux developer, I'd like to continue to extend support and encouragement to OpenSolaris developers.
I believe that such attacks on other open projects serve to damage the general interests of FOSS. Interestingly, LF has granted itself authority to respond to "competitors’ attacks" [2], a role which is surely undermined by themselves undertaking such attacks, especially on emerging FOSS projects.
Since 2.6.23, it has been possible to prevent applications from mapping low pages (to prevent null pointer dereferencing in the kernel) via the /proc/sys/vm/mmap_min_addr sysctl, which sets the minimum address allowed for such mappings.
So, if you have a recent kernel still affected by the vmsplice issue, try:
echo 65536 > /proc/sys/vm/mmap_min_addr
(If it is not already set, of course).
If using SELinux, the system must be running in enforcing mode.
Note that there was a bug in the mmap_min_addr code until 2.6.24-rc5, although I do not believe it affects mitigation of this particular exploit.
Generally, it is a good idea to have mmap_min_addr set, although it is disabled by default in the upstream kernel as it can affect a some applications (e.g. users of vm86 mode such as X).
As SELinux is able to selectively enforce the setting via policy, it can be enabled for the general case on recent SELinux systems. If not using SELinux, processes with CAP_SYS_RAWIO are allowed to bypass the setting.
IBM article: Role-based access control in SELinux Serge Hallyn of IBM and general kernel hacking fame has written a great article on Role-based access control (RBAC) in SELinux.
The article is also something of a tutorial, implementing a security scheme for a simple store cash register system, with downloads available for a Gentoo-based SELinux from Scratch qemu image; and for standard Fedora 8 systems.
It's great to see these kinds of projects coming from the community!
Using SELinux Kiosk Mode in Fedora 8 Fedora 8 now has support for Dan Walsh's SELinux kiosk mode, or xguest, which he has previously described in some detail.
The good news is that it's utterly simple to use:
Upgrade to the very latest Fedora 8 -- simply ensure you have run:
# yum update
Install the xguest package and necessary dependencies:
# yum install xguest
Ensure you're running SELinux in enforcing mode:
# getenforce Enforcing
Log out from X, and you should see a new "X Guest User" user in the GDM welcome screen:
Click on the X Guest User account, and you will be logged straight into a GNOME session.
The GNOME session will run as a very tightly locked down SELinux account, which can only be accessed via GDM. It is essentially authorized only to surf the web.
PAM namespace is utilized so that the session has private views of shared writable filesystem space (e.g. /tmp), while Sabayon is used to load a custom GNOME configuration.
Any local changes made by the user, such as writes to $home or their desktop settings will be lost after they log out.
Thomas Mraz's PAM SELinux permit package ensures that the xguest account is only active in enforcing mode, to ensure the account cannot be used to attack the system if it is in permissive mode.
Further technical detail may be found in the package's README file.
Where would you use this? Dan has found it useful for family members with various levels of computer skill, while I can imagine that xguest would also be quite handy for things like LUG events, conference booths, training, Linux demonstrations, information kiosks etc.
If you come up with any cool uses, or enhancements, please let us know.
SELinux mitigates remote root vulnerability in OpenPegasus According to Red Hat Security Advisory RHSA-2008-0002, a recently discovered stack overflow flaw in OpenPegasus is mitigated by standard SELinux targeted policy in RHEL4 and RHEL5:
... an unauthenticated remote user could trigger this flaw and potentially execute arbitrary code with root privileges. (CVE-2008-0003)
Note that the tog-pegasus packages are not installed by default on Red Hat Enterprise Linux. The Red Hat Security Response Team believes that it would be hard to remotely exploit this issue to execute arbitrary code, due to the default SELinux targeted policy on Red Hat Enterprise Linux 4 and 5, and the SELinux memory protection tests enabled by default on Red Hat Enterprise Linux.
The enhanced memory protection tests in RHEL5 contribute here to mitigation.
Btw, for those able to attend FUDCon in Raleigh over the weekend, there will be a few SELinux folk around to answer questions, listen to feedback etc.
Update: Someone asked for more Fedora-specific information to compare with other distributions. Here's a well-maintained page on Fedora Security Features.
SELinux mitigates HPLIP vulnerability I missed this one at the time, but a member of the Red Hat security response team just pointed me at this RHEL advisory from October, where a vulnerability in HPLIP was mitigated by standard targeted policy.
That is, SELinux provided zero-day protection against local users exploiting this vulnerability to run arbitrary code as root.
FOSS.IN/2007 Wrapup I'm finally back from FOSS.IN/2007, although my body clock seems to be lost somewhere in the Arabian Sea.
The push to make the conference more contributor-focused seemed to work very well.
The final talk slot, which was given to Rusty on short notice, included an invitation for FOSS developers to come down and stand on the stage. First, people who had contributed code to a project -- way more people than anyone expected -- stood up and came down. Then, progressively, people who'd submitted a bug report, or written documentation, or helped others, and finally, anyone who'd used FOSS. Here's what it looked like:
Members of the then non-audience passed the microphone around for some ad-hoc lightning talks on what they were doing.
Following that, Atul spoke about the future of FOSS contribution in India, explaining that FOSS.IN would not move around the country, as it is preferred that each region develop their own event. Organizers of other Indian FOSS conferences provided brief overviews of each, including the entirely student-run FOSS Meet@NITC in Calicut.
It was a great ending to a great conference, and overall, simply refreshing to see so much grassroots activity.
An older attendee wrote a nice email to the conference mailing list with some interesting observations, such as "You are prime-movers of modern India" and "Some had weird hairstyles". Indeed, as has been noted by others, including Simon Phipps, there's an intense enthusiasm for technology in India which I've not seen elsewhere.
I really would not be surprised, within ten years, to see India become the top FOSS contributing country.
As a foreign speaker, I found the conference to be a great opportunity to spread knowledge in a direct way -- beyond what is possible via code, documentation, blogging etc. -- and can highly recommend it to others. Rusty had fun, although he definitely under-assessed his final talk.
If you've ever wondered what it's like to return from your morning coffee run to be serenaded by a Nadaswaram, "the world's loudest non-brass acoustic instrument", here's a video starring Andrew Cowie, Spot Calloway and the omnipresent Rusty as part of the audience.
Both talks were well attended -- I think about 500 for the kernel talk, and 100 for the SELinux talk, with lots of good questions and post-talk hallway discussions.
![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small}
james_morris's journal
