From mboxrd@z Thu Jan 1 00:00:00 1970 From: Klaus Weidner Subject: Re: [PATCH] Add audit uid to netlink credentials Date: Thu, 10 Feb 2005 13:26:55 -0600 Message-ID: <20050210192655.GA14534@w-m-p.com> References: <20050210175221.GA13458@w-m-p.com> <20050210181023.92819.qmail@web50202.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kuznet@ms2.inr.ac.ru, davem@davemloft.net, netdev@oss.sgi.com To: Linux Audit Discussion Content-Disposition: inline In-Reply-To: <20050210181023.92819.qmail@web50202.mail.yahoo.com> Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com List-Id: netdev.vger.kernel.org On Thu, Feb 10, 2005 at 10:10:23AM -0800, Casey Schaufler wrote: > --- Klaus Weidner wrote: > > Both CAPP and LSPP assume trustworthy administrators, and those > > protection profiles don't really support the concept of fine grained > > capabilities for not-quite-administrator tasks. > > I don't know where you get that idea, as it is inconsistent with the > evaluations I have done. A fine grained capability model that is used > will always make an evaluation easier. A process that runs with partial > privilege requires much less supporting evidence for evaluation than > one that has superuser privilege. The Criteria may not require fine > grained privilege, but that does not mean it doesn't help. My point was that the security functional requirements in CAPP and LSPP related to audit and user management only differentiate between authorized users and authorized administrators, and adding a finer grained distinction to those SFRs would be incompatible with CAPP/LSPP. CAPP and LSPP permit extending the DAC and MAC policies by adding additional rules such as capability-based ones, but I'd normally expect that to cause more work instead of less when evaluating since all claims related to that policy would then need to be sufficiently tested and verified. But I think that's getting off-topic for this list. > > The CAPP and LSPP audit requirements include that audit records > > contain the subject identity, this corresponds to the login UID. > > The subject identity is the name of the subject, that is the process > ID. The user associated with the session is the login UID. The user is > not the subject. Sorry, I blame lack of caffeine for that mixup. The requirement I meant was that each auditable event needs to be associated with the identity of the user that caused the event. In the context of this discussion, that means that the login UID in audit records needs to correspond to the user identity of the user on whose behalf the process (subject) runs. For cron/at and other indirect execution methods, the daemon running the jobs needs to be able to correctly associate the login UID of the user who submitted the job with the audit records generated by that job. Usually such daemons will need the capability to change the login UID for forked processes in addition to generating user messages with a specific login UID included in the record, so the distinction between those two capabilities isn't all that useful in this case. > It is actually a very good idea to maintain modifications to system > security databases outside the audit trail proper. In the Orange Book > days the NSA went so far as to declare a that a reasonable procedure > for keeping them under revision control would be sufficient to meet the > audit requirements. Hmmm, this doesn't match the application note for FAU_SAR.1 in CAPP and LSPP that mentions that it is expected that a single tool will exist that satisfies all the various requirements related to audit information access. Of course application notes aren't normative, and you could claim that "grep" is the single tool usable for all types of audit trail access... -Klaus