You are viewing james_morris

James Morris Below are the 3 most recent journal entries recorded in the "James Morris" journal:
May 29th, 2009
08:06 am


Linux Security Events in Portland
Several Linux security events are planned in association with LinuxCon this year in Portland, Oregon.

  • 2009 SELinux Developer Summit
    The CFP for this event has just been published. The developer summit will be held on the 20th of September as an ancillary event of LinuxCon. This is a one-day event, and developers are encouraged to submit proposals around the primary topics of extensibility and usability. We're hoping to have a flexible format this year, perhaps with half a day of talks and then half a day of hack sessions. Note that all attendees need to be registered for LinuxCon, and that earlybird registration ends this Monday, June 1st. Also, please subscribe to the event mailing list if you're planning to attend, so we can estimate numbers. More details are available at the summit web page.

  • Security Microconf
    A security microconf will be held at the co-located Plumbers Conference. The Call for Topics ends on June 15th, and anyone doing interesting work in Linux security should consider submitting a proposal. Also see the LWN topic discussion and Paul McKenney's recent blog entry on the event.

  • LinuxCon Talks
    There are several security-related talks at LinuxCon itself:

    I'll be giving a LinuxCon talk on adding extended attributes support to NFSv3, presenting a prototype implementation (based on the GPL IRIX code) for discussion. xattrs are a very common feature in Unix and Linux filesystems, but there is no standard for them, nor for conveying them over NFS. NFSv4 supports "named attributes", although this is based on the Solaris extended attribute scheme (subfiles), and somewhat incompatible the simple name/value string-based xattrs supported by Linux, BSD, IRIX etc. It would be nice to have Linux-style xattrs supported in NFSv3, with the current work then potentially forming the basis for a future NFSv4 protocol extension. If you're interested in this stuff, please consider attending and helping with the discussion.

Tags: , , , , , , , , , , , , , , , ,

(Leave a comment)

October 13th, 2008
10:54 am


SELinux and Security changes in the 2.6.27 Kernel
Here's an update on the main functional changes in security for the recently released 2.6.27 kernel.

  • SELinux deferred mapping of filesystem contexts
    This patch by Stephen Smalley addresses the case where "alien" SELinux security labels need to be written to the local filesystem, for example, in the case of building RPMs where the local policy is different to the policy on the system where the RPM is to be installed. This will help with enabling SELinux on build systems (e.g. in the Fedora infrastructure) and more generally with packagers and ISVs shipping third party policy with RPMS.

    The way this works is to allow locally invalid labels to be written to disk by certain users (namely, those with the standard CAP_MAC_ADMIN capability and the mac_admin SELinux permission). For security purposes the system will treat those files as if they were not labeled, which means that no normal application will be able to interact with them. A further patch was added to allow administrators to view the alien labels.

  • Show LSM mount options in /proc/mounts
    SELinux has several filesystem mount options specific to its security model, such as the ability to set security labels on a per-mount basis. This is useful for filesystems which do not have support for security labeling.

    These options were not being displayed in /proc/mounts, and Eric Paris wrote a patch which provides a general solution to this for all LSM modules with a new sb_show_options hook.

  • Split proc ptrace checking into read vs. attach
    With this patch from Stephen Smalley, the core ptrace permission code was split so that read-only access to process state could be differentiated from access requiring full control of the process. Several applications such as lsof need to do things like read the memory state of a process, but nothing else, so, it is now possible to allow that without also allowing general ptrace access.

    The LSM ptrace hook is now passed a flag, either PTRACE_MODE_READ or PTRACE_MODE_ATTACH, to allow the security modules to differentiate access in policy, if desired.

  • Removal of LSM dummy module
    Ever since the introduction of LSM, a 'dummy' module has always been the default when LSM was built but not configured with a specific security model. This has never been a good default, as people almost certainly need the capability module.

    Miklos Szeredi supplied a patch to remove the dummy module and ensure that the capability module is always compiled in as the default. With the capability code always compiled in, LSM was then further simplified to remove the secondary module stacking code. This was previously used by LSMs such as SELinux to dynamically stack capabilities, and now that it is known that capabilities is always there, this stacking can be performed by simply calling directly into the capability module.

  • Protect legacy applications from executing with insufficient privilege
    Andrew Morgan authored a patch to ensure that certain applications which are not granted all of the privileges they request or expect have their execution failed with EPERM. The counter-intuitiveness of this should be a hint as to the overall complexity and subtlety of OS security. The full background to this change is documented in this sendmail capabilities war story. If your brain doesn't explode when you read that, there is something wrong with you and you should probably be working in computer security, if not already.

    Filesystem capabilities were also promoted from experimental status in the kernel configuration to a standard option, and are indeed now enabled by default on at least one distribution (Fedora 10 development).

  • Fix setting of PF_SUPERPRIV by __capable()
    David Howells fixed a long standing bug in the capability code, where the PF_SUPERPRIV flag could have been set inappropriately on processes which were being probed for a privilege rather than actually using the privilege. This flag is set on a process when it exercises privilege (e.g. via capabilities), and may be later used for process accounting purposes. David's patch fixed the problem by cleanly demarcating the probing of capabilities vs. using them, resulting in a nice general code cleanup.

Upcoming changes

There's quite a lot coming up in security for the next couple of kernels, with major changes including David Howells' epic credentials API rewrite (which touches pretty much everything and is thus moving very slowly upstream), the Integrity framework and IMA from Mimi Zohar et al, and Trusted Boot (TXT) from Intel. It's not clear whether these will make the current merge window for 2.6.28, although some preparatory patches are already merged. Paul Moore has been doing a lot of work on labeled networking, which is maturing in terms of government/military requirements, and should also provide some very interesting functionality for general users down the track. There's been an updated code drop for Labeled NFS, although I've not yet had a chance to give it a detailed review (things get busy upstream when you combine KS/LPC and a kernel release). There are also possible merges of TOMOYO and AppArmor if the VFS pathname issue is resolved.

Tags: , , , , , , , , , , , ,

(3 comments | Leave a comment)

May 2nd, 2008
09:35 am


Labeled NFS Requirements Draft Submitted
Dave Quigley has just submitted an Internet Draft to the IETF outlining the requirements for Labeled NFS:

MAC Security Label Requirements for NFSv4 (link)

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:

Dave is hoping to have further discussion IETF 72 in July, and will be presenting on the state of the project at the SELinux Developer Summit ahead of that.

Tags: , , , , , , , , , , , , ,

(Leave a comment)

James Morris Powered by