public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Linda Walsh <law@sgi.com>
To: "Albert D. Cahalan" <acahalan@cs.uml.edu>, linux-kernel@vger.rutgers.edu
Subject: Re: [PATCH] (for 2.3.99pre6) audit_ids system calls
Date: Wed, 03 May 2000 00:05:06 -0700	[thread overview]
Message-ID: <390FCFA2.A71B9C3@sgi.com> (raw)
In-Reply-To: 200005030228.e432SVZ12218@jupiter.cs.uml.edu

"Albert D. Cahalan" wrote:
> I think I know what he means.
> 
> For "real security" you don't pretend that you can stop spies.
> The system is strictly DAC-based, and most likely uses a root
> account in the traditional way. Instead of adding new features,
> you verify that the existing ones work correctly. An LSPP/B1
> system full of bugs is worse than a perfect not-quite-C2 system.
> The latter will at least correctly enforce DAC, while the former
> might well let remote attackers get into kernel memory.
---
	Absolutely agree.  A DAC Protection Profile, if evaluated to
"EAL" (Evaluated Assurance Level) anything is better than an untested
system.  However, CAPP and LSPP both specify an EAL of "3".  This means
that their feature set has been Evaluated to meet a well-defined Level
of Assurance (documentation, testing, build methodology, code management,
some level of proof that the features provided meet the functional specs,
etc). We've seen distro's ship binary disks where the images on the disk
didn't match what was in the source.  We don't know what version of the
compiler was used, etc.  We don't know what was in those
binaries -- there's no third party evaluation, no standard measured
against.

	Under Common Criteria, Functional specifications are separate
from Assurance Levels.  In a given Protection Profile both a set
of functional specs is given as well as a set of Assurance requirements.

The Assurance requirements are covered in Part 3 of the Common Criteria
documents (ISO standard 15408).  The CC.org site seems to be down, so you
find more info at http://csrc.nist.gov/cc/ccv20/ccv2list.htm .  
The Common Criteria isn't just a Dod/US gov. thing.  It's also an ISO 
standard.  But wait, there's more -- if you call now you get these
free Ginsu Steak Knives *and* a Linux Security Policy for the unbelievable
low price...Goddess it's late...I think I better end this...:-)

Bon nuit & Au revoir,
-l

-- 
Linda A Walsh                    | Trust Technology, Core Linux, SGI
law@sgi.com                      | Voice: (650) 933-5338

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

       reply	other threads:[~2000-05-03  7:01 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200005030228.e432SVZ12218@jupiter.cs.uml.edu>
2000-05-03  7:05 ` Linda Walsh [this message]
     [not found] <390DCCB6.257F3CC6@sgi.com>
     [not found] ` <m1hfch3qeq.fsf@frodo.biederman.org>
2000-05-02 18:01   ` [PATCH] (for 2.3.99pre6) audit_ids system calls Linda Walsh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=390FCFA2.A71B9C3@sgi.com \
    --to=law@sgi.com \
    --cc=acahalan@cs.uml.edu \
    --cc=linux-kernel@vger.rutgers.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox