----- "Neil Horman" <nhor...@redhat.com> wrote:
> On Tue, Aug 10, 2010 at 10:47:14AM -0400, Miloslav Trmac wrote:
> > ----- "Neil Horman" <nhor...@redhat.com> wrote:
> > > On Tue, Aug 10, 2010 at 09:24:31AM -0400, Steve Grubb wrote:
> > > > The problem with the netlink approach is that auditing is not as good 
> > > > because 
> > > > netlink is an async protocol. The kernel can only use the credentials 
> > > > that 
> > > > ride in the skb with the command since there is no guarantee the 
> > > > process has 
> > > > not changed credentials by the time you get the packet. Adding more 
> > > > credentials to the netlink headers is also not good. As it is now, the 
> > > > auditing is synchronous with the syscall and we can get at more 
> > > > information 
> > > > and reliably create the audit records called out by the protection 
> > > > profiles or 
> > > > FIPS-140 level 2.
> > > > 
> > > > -Steve
> > > 
> > > I think thats pretty easy to serialize though.  All you need to do is 
> > > enforce a
> > > rule in the kernel that dictates any creditial changes to a given context 
> > > must
> > > be serialized behind all previously submitted crypto operations.
> > That would be a bit unusual from the layering/semantics aspect - why
> should credential changes care about crypto operations when they don't
> care about any other operations? - and it would require pretty
> widespread changes throughout the kernel core.
> >     Mirek
> 
> 
> I'm sorry, I thought steve was referring to credentials in the sense of 
> changing
> keys/etc while crypto operations were in flight.
The audited values are mainly process/thread attributes: pid, ppid, 
{,e,fs}[ug]id, session id, and the like.  Most of these are attached to the 
netlink packet, and performing a lookup by PID is at packet handling time is 
unreliable - as far as I understand the netlink receive routine does not have 
to run in the same process context, so the PID might not even refer to the same 
process.
    Mirek
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to