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

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

[Linda Walsh]

"Eric W. Biederman" wrote:
> What bug does adding two new system calls fix?
> Aren't we in a deep feature freeze at the moment.
> 
> It isn't even terribly obvious what they are for.
> The luid I think I have heard of the sess_id I haven't....
> What bug does adding these fix?
---
	The bug is that any major commercial operating system provides
at least "C2" or "CAPP" level 'trust' (including MS NT).  One of the requirements for this level of 'trust' is that audit actions be able to be
written corresponding to the appropriate 'authenticated' (as in they
gave a "password" (literal password or other biometric)).  Currently,
none of the uid values can be guaranteed to remain constant for
a login session.  Thus the luid fix.  

	Additionally, all of the major
systems companies provide systems (at a substantial premium) that 
meet the "B1" or "LSPP" trust levels (except MS which isn't really
a systems company anyway).  LSPP requires all the features of CAPP
and more.  The US Dod will "prefer" evaluated systems that
meet "CAPP" or above by Jan 1, 2001 and "require" such systems
by July 1, 2002.  In accordance with plans for Linux OS world domination,
infiltration of governments is vital (:-)).  

	To be on the "preferred"
list, Linux needs to have the feature set of and be evaluated to meet the 
"Controlled Access Protection Profile".  Some of our _*Engineering*_ goals
are to have CAPP in eval by early 2001 and the LSPP evaluation complete 
by 01, Jul, 2002.  It is also SGI's desire that all of this work goes
into the main Linux base for any and everyone to make use of.  Toward
this effort, we released a 'reference' B1 implementation (non-funcional
due to removal of code we didn't have full ownership of) on
http://oss.sgi.com/projects/ob1 from the IRIX/Trusted IRIX source.  Our
hope is that people will take ideas and code and help Linux to get to
those levels of "trust" (it isn't all kernel work).

	Other people proposed sess_id for the purpose of tracking
which particular session of a luid did the auditable action.  For
example, you could have more than one person logged in at the same
time.  sessid's can be guaranteed to be unique not only for the time
the computer is running -- but if stored and restored over reboots, 
over the life of the computer -- even if you generated 1/millisecond,
you'd still have to do that for about a 1000 years by my guestimation
and they are only supposed to be generated at the beginning of a 
session.

	For more information on the CAPP profile and the Common Criteria
for trusted computing systems, see www.commoncriteria.org.  Currently
about 8 member countries (Australia, Canada, France, Germany, Netherlands, New Zealand, UK and US) accept comupter systems evaluated at CAPP, LSPP
or any PP at EAL4 and below evaluated in any of the member countries.
In a separate agreement, there is a group of European-only countries
that accept CAPP, LSPP and any system up to EAL7 evaluated in one of
their member countries.  For more information on requirments you 
can also look at "www.itsec.gov.uk" and "radium.nscs.mil/tpep" and
the US Nat. Inst. of Comp. Security at
"http://csrc.nist.gov/topics/welcome.html".

Thank-you for asking! :-)

-linda

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

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

[Linda Walsh]

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