Because the cool kids are doing it, here are photos of the bookshelves above my desk:
Click for more detail.
The OLS 2008 schedule is up:
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.
Christer Edwards has announced support for SELinux in Ubuntu 8.04, and documented the installation procedure:
$ sudo aptitude install selinux
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!
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.
As noted at SELinux News, OpenSolaris has launched a new project, Flexible Mandatory Access Control (FMAC), 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 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.
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.
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.
References:
[1] http://www.linux-foundation.org/weblogs/amanda/2008/02/17/hey-jonathan-the-l-in-lamp-is-literal/
[2] http://www.linux-foundation.org/en/About
Rafal Wojtczuk of McAfee Avert Labs posted an interesting analysis of the “qaaz” exploit for the recent vmsplice vulnerabilities.
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.
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!
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:
# yum update
# yum install xguest
# getenforce
Enforcing
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.
Enjoy!