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