Re: [PATCH] (for 2.3.99pre6) audit_ids system calls

From: Linda Walsh (law@sgi.com)
Date: Tue May 02 2000 - 18:08:57 EST


Rik van Riel wrote:

> On Tue, 2 May 2000, Linda Walsh wrote:
> > Alan Curry wrote:
> >
> > > So finally, you admit CAPP is a bug :)
> > ---
> > Lack of CAPP is a bug definitely, but CAPP
> > itself...well...it is government issue ya know...:-)
>
> Personally I'd rather see Linux chose for real security than
> for some paperwork issue.

---

It isn't so much "security" per se as "trust". "Trust" is when you can have a system evaluated to particular specifications and have that trust be independantly evaluated. This evaluation would be respected in Netherlands by "Netherlands National Communications Security Agency".

Also, what do you mean "real security"? By which standard is it measured and evaluated? Is there a security policy? A security target defined? Other parts of the CAPP require those to be written down. Tests are required to show that the provided functionality has been verified. A set of system files, the Trusted Computing Base (TCB) needs to be defined. Each file in the TCB has to be evaluated for one of three classifications "Security enforcing", "Security relevant" and "Not Security Relevant". Has someone written (I hope?) a security analysis of every system call and every ioctl/fcntl? These are formal elements of a secure system. These are all items that need to be there before having a CAPP compliant system. It isn't just about luid's or audit, they are necessary but insufficient. The CAPP even describes in detail what events must be audited. We want to have all of this in the main kernel and want to give away our evaluation evidence. >>> Now note, it is my plan that 'auditing' should be a configurable option, both at build time and at run-time. But it can't be impllemented as a module any more than SMP code could be put in a module. It can be all made a configurable. Same with LSPP's MAC -- another TBD at build time.

If Linus prefers, I'll draw up the necessary AUDIT selection options now and make the "uid"s part of it. But I don't see any run or build time config of the system-jump table in the X86, so I'm guessing there are some things that are 'just in the kernel' and some things that can be configured.

It might be an interesting task for you to define a "real security" Protection Profile and submit it to the Common Criteria. Note that CAPP requirements are required for the "Labeled Security Protection Profile" (LSPP/B1) as well. At that level you start getting kernel level enforcement of user->access->data that is non-circumventable and non-discretionary. You also have strong data integrity mechanisms in place to protect system data from users and users from virus's.

> Having a security enhancement in the kernel is fine by me, > but this sounds like it's nothing more than a paper enhancement. --- Accountability isn't just a paper thing. It can also be used to support real-time intrusion detection.

-linda

-- Linda Walsh @ SGI | Core Linux - Trust Technology 1200 Crittenden Lane MS:30-3-802 | Voice: (650) 933-5338 Mountain View, CA 94043 | Email: law@sgi.com

- 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/



This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:11 EST