Re: [ISN] SELinux aims for security certification and credibility among cautious IT purchasers

From: InfoSec News (isnat_private)
Date: Tue Apr 02 2002 - 00:06:04 PST

  • Next message: InfoSec News: "[ISN] InfoSec News List Information"

    Forwarded from: Russell Coker <russellat_private>
    
    I've already posted some comments to the newsforge forum, but I think
    it would interest some readers to see them here (also I'll address
    some issues I didn't mention in the forum).
    
    On Mon, 1 Apr 2002 09:53, you wrote:
    > http://newsforge.com/article.pl?sid=02/03/22/1716241&tid=23
    >
    > Friday March 22, 2002
    > [06:12 PM GMT]
    > By Grant Gross
    >
    > Martin R. Dean, senior security researcher at the Cyberspace Policy
    > Institute (CPI) and principal engineer at Science Applications
    > International Corp., said SELinux still needs some enhancements,
    > such as becoming a fully integrated operating system instead of a
    > patch to Red Hat Linux, but the institute is starting to look for
    > partners to
    
    SE Linux is not "a patch to Red Hat".  It consists of a patch to the
    kernel (which most people probably get from immunix as they support
    new kernels long before the NSA) and patches to various utility and
    daemon programs.
    
    The patch to the kernel is not distribution specific.
    
    The patches to the applications apply to the versions of the
    applications that Red Hat ship.  This means that if you use different
    versions (because of having modified a Red Hat installation or because
    of using a distribution such as Debian that has different versions
    packaged) then you will have to do some coding to get the patches to
    apply.
    
    This does not inherantly make it a "Red Hat patch"!  In fact if you go
    through the archives of Debian software and find matching versions to
    the ones that the NSA have developed patches for then you would
    probably find it easier to get working than if you use the latest Red
    Hat beta.
    
    Also the sample policy has all the configured file locations matching
    the Red Hat locations, but getting these things changed is not
    difficult really, and the NSA people have been quite good at accepting
    my patches for such things so it's getting easier all the time.
    
    As far as I know no-one is distributing RPMs of SE Linux patched
    programs.  To the best of my knowledge I am the only person
    distributing packages of SE Linux for any distribution (if you have
    any information to the contrary then please contact me off-list - I
    have some code that's not yet ready for a beta even that I would like
    to discuss with RPM packaging people).  I only know of one person who
    is actively working on RPMs of SE Linux (although a few other people
    have talked about it).
    
    I am packaging SE Linux for Debian.  I packaged the kernel patches
    last year, and yesterday the "selinux" package (containing SE
    management utilities and sample policy) was admitted into
    Debian/unstable along with the SE Linux development package.  Also the
    maintainer of the "stat" package for Debian has SE support both in
    their package and in the upstream distribution.
    
    On my web site http://www.coker.com.au/selinux/ I have Debian packages
    for "ssh", "login", and "kdm" (needed to select the correct security
    ID for the user when they login), "cron" (must run cron jobs in the
    correct context), "procps" and "psmisc" (need to see the context of
    running processes from ps).
    
    These are all beta packages and should be regarded as very
    experimental.  I can't guarantee that your machine will be able to
    successfully boot after installing the SE policy.  I am still running
    my SE machines in debugging mode.
    
    
    The installation documents for SE Linux refer to installing the
    programs under /usr/local to avoid the packaging system.
    
    
    I believe that even though my packages are extremely experimental,
    they are still the best option for someone who wants to install
    packages of SE Linux.  I think that a reasonable conclusion from this
    is that Debian is better supported than Red Hat (but I admit that I am
    biased ;).
    
    > help guide the ultra-secure Linux distribution through the rigorous
    > EAL4 security certification, known formally as the Common Criteria
    > for Information Technology Security Evaluation standard.
    
    This is something that doesn't concern me.
    
    At the moment I see no evidence that anyone is interested in paying
    for Debian to be certified.  Also my main interest here is in the ISP
    environment where security certification isn't something that anyone
    seems to be interested in.
    
    I'm prepared to reconsider this if someone comes forward with the
    cash!  But I will never pay a cent towards certification, and neither
    will any of the companies I work for.
    
    > Microsoft is currently trying to get the EAL4 for its Windows 2000
    > OS, and Dean argues that for Linux to be competitive at places like
    > government agencies, where security ratings are used as a big
    > evaluation tool for buying technology products, SELinux also needs
    > the EAL4 rating.
    
    I am wondering if we need a new sub-distribution of Linux for such
    things.
    
    Getting the full Debian setup of 8000 packages certified in any way is
    impossible.  I think that a spin-off project in the manner of Progeny
    based on security has some interesting possibilities.  This would
    involve firstly removing things that don't interest the target market,
    then developing the policy and the tests for the core of the OS as
    well as developing some extra security packages (and making SE support
    a standard part of all the base packages).
    
    > NSA's SELinux documentation includes a sample security policy, but
    > configuring the fine-grained controls, down to what programs
    > individual users can run, does take some knowledge, Loscocco said.
    
    Knowledge of both the applications and of SE Linux.  Some of the
    interactions between daemons on my systems has surprised me!  I write
    a policy to allow a program to do what I think it needs to do, then I
    discover that it does many other things!  This is another thing that
    needs some work.  Applications need to be written to require less
    access to the system.
    
    Then there's difficult policy decisions, for example what do I do with
    an application that wants to read /proc/meminfo to see how much memory
    is in the system and to do a statfs() on each file system to see how
    much disk space is free?  Will the application run properly if I deny
    it such information?  I don't want to allow any application more
    access than it really needs.  Often I have to read the source of
    programs to determine what they are doing and why.
    
    > Westerman has written a graphical installer that's a first step to
    > pitching SELinux to mainstream users. "What we're looking at is
    > getting the operating system to the point where we can roll it out
    > to an elite IT organization, or where a user can run it on the
    > desktop," Dean said. "What we looking at is getting the SELinux
    > patch and the Linux operating system to the point where it's a
    > robust operating system, so it's not just the small thing that sits
    > on the server, but on everybody's desktop."
    
    If you want to do a Linux roll-out to 2000 desktops now then SE Linux
    will do the job.  Getting it configured correctly will be a lot of
    effort, but if you're installing so many machines then you've probably
    got the resources.
    
    > "With SELinux, we're not as worried about the next buffer overflow,"
    > Westerman said.
    
    Another thing is that when you write a SE policy for an application
    you can often see situations where bugs cause it to do things that it
    shouldn't.
    
    I've found two such bugs in commonly used Linux software already (but
    I don't believe that there's a security issue).
    
    > A security certified operating system that's had outside changes
    > made to it may lose its certification, and a distribution that's
    > downloaded from a site that's not part of the official certification
    > channels loses its certification, Westerman said.
    
    This is a problem for Debian.  But if you are just after security and
    not after a rubber-stamp then that probably won't worry you.
    
    > However, Loscocco said his goal would be to release changes back to
    > the GPL
    
    They have been very good at this so far.
    
    
    Russell Coker
    
    
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY
    of the mail.
    



    This archive was generated by hypermail 2b30 : Tue Apr 02 2002 - 03:23:21 PST