Alexander wrote:
> On Tue, May 02, 2000 at 03:26:45PM -0700, Linda Walsh wrote:
> > "Alexander S . Guy" wrote:
> >
> > > I dunno, it seems like you should get the above fully operational before you
> >
> > > start requesting that specialized code be included w/ the mainline kernel.
> >
> > ---
> > Experience in the open-source community for us has been to "release early" and "release often".
> > Experience has show that trying to get one gigantic patch accepted by the community and into
> > the kernel is generally like trying to get that patch through an eye of a needle -- very difficult.
>
> I'm not saying that you shouldn't expose the patches to people. I'm just saying that you might
> (and I'm not trying to be rude here, and I might be totally off base), have something that
> actually provides functionality before you start adding hooks into the kernel.
---
It does provide real functionality. Applications can immediately be written to set/generate ID's.
It allows parallel work to *begin* on those applications. (The below is alot more legible on
a wide screen or variable font...sigh)
Part I:
(-2 : auditid); (-1: (wait for -2) Add audit id generation to applications)&
(0: A audit record token & record format) - (underway))&
(1 (.1: setting/getting the audit mask (128 bits) -- another CAP_AUDIT_CONTROL'ed operation) &
(.2: defining the meanings of the bits) &
(.3 (wait for 0 above) then:
(1.3.1 a module to implement /dev/audit to which audit records can be written to internally by the kernel
external writes (applications like login, passwd, etc) require CAP_AUDIT_WRITE.) &
(1.3.2 an audit daemon to grab the binary data out of /dev/kernel and write it to 1 or more files or
file systems.) & ) &
(2 ( (wait for 1 above) then:
(.1 audit events into kernel) &
(.2 audit events into apps (PAM et al.) &
(.3 audit filtering and report tools) &
(.4 audit configuration (how to choose which users get what audited))&
(optional - real time audit log monitor for security event detection)&)
(3 - documentation:
(.1 Linux Security Policy)& (.2 Security Target based on CAPP)& (.3TCB definition and Security analysis)&
(.4 Kernel security analysis)& (.5 - wait for 3.1 and 3.2, show correlation)&
(4 - wait on 3.2, tests to be written)&
(5 - wait for 1-4 all done, submit for formal third party eval, target early 2001)&
((II.1 - filesystem work:
(II.1.1 - MAC labels required in "a' filesystem, try to use existing ext2, ext3 or xfs - whatever is mature
enough to be working) | (create new filesystem type based on some existing type to add in
functionality (least preferred)) &
(II.1.2 - Very strongly desired - capability supporting filesystem - same as II.1 for implementation)&
(II.1.3 - S.D. - ACLs same as II.1 for implementation) &)
(II.2 - kernel work, .1-.3 wait as needed, note II.2.2 is a "connecting the dots" exercise)
(II.3 - documentation -- probably wait on I.3 above to extend (but can be separate effort)
(.1 Linux Security Policy)& (.2 Security Target based on LSPP)& (.3TCB definition and Security analysis)&
(.4 Kernel security analysis)& (.5 - wait for II.3.1 and II.3.2, show correlation)&
(II.4 - wait on II.3.2, more tests to be written)&
(II.5 - wait for II.1-4 all done AND I.2, submit for formal third party eval, target early to mid 2002 for
completion)&
As much as possible, I tried to indicate "(...)&" what can be done in parallel. We are looking at what
we can maybe share/reuse with Trusted BSD (for non kernel parts).
> > It's my belief that putting in small individually useful chunks will allow more people to jump
> > onboard with later coding and design issues. It's something akin to "open design".
>
> For something this important, I'd like to see more of an open architectural process happening, w/
> a real plan of attack.
Is the above something along the lines you were looking for? For exact requirements, please see:
http://www.radium.ncsc.mil/tpep/library/protection_profiles/CAPP-1.d.pdf (for CAPP) and
http://www.radium.ncsc.mil/tpep/library/protection_profiles/LSPP-1.b.pdf (for LSPP).
> Why don't you release a working add-on to Linux (going back to pcmcia-cs as an example), that people
> can pick up and use in their distributions. I don't know about other people think, but I couldn't
> give a rat's ass about claiming certification. I want an architected security solution that is
> comprehensive, and actually functions.
---
Why wasn't "SMP released as a working "add-on"? Auditing and MAC need to be integrated
into the kernel -- they can be build-time configurable, but they can't exist as separately developed
modules.
> Hahaha.. I'm not saying ``don't contribute'', I'm saying, ``contribute code that actually
> supplies real functionality''. I'd hate for something as big as trusted status to have the
> same real functionality as some of those v0.1 MP3 archiver scripts on freshmeat.. it's easy
> to hype, it's harder to get something that actually works.
---
This we know, but were the MP3 archiver scripts some large computer system vendor's project?
If I and my peers don't produce something of value to the company (something that actually works
and can be sold to meet requirements), it would be bad. Then I'm one of those poor programmers
standing on an off ramp with a sign "will program for food"...ok, maybe slight exaggeration, but
I would probably be put on something alot less fun to do.
-l
--
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