----- "Neil Horman" <nhor...@tuxdriver.com> wrote:
> On Tue, Aug 10, 2010 at 12:57:43PM -0400, Miloslav Trmac wrote:
> > 
> > ----- "Neil Horman" <nhor...@redhat.com> wrote:
> > 
> > > On Tue, Aug 10, 2010 at 11:40:00AM -0400, Miloslav Trmac wrote:
> > > > ----- "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.
> > >
> > > I'm not so sure I follow.  how can you receive messages on a socket in 
> > > response
> > > to requests that were sent from a different socket.  In the netlink 
> > > multicast
> > > and broadcast case, sure, but theres no need to use those.  I suppose you 
> > > could
> > > exit a process, start another process in which the pid gets reused, open 
> > > up a
> > > subsequent socket and perhaps confuse audit that way, but you're not 
> > > going to
> > > get responses to the requests that the previous process sent in that case.
> > I don't even need to open a subsequent socket - as son as the
> process ID is reused, the audit message is incorrect, which is not
> really acceptable in itself.
> > 
> But, you do, thats my point.  If a process exits, and another process starts 
> up
> that happens to reuse the same pid, it can't just call recvmsg on the socket
> descriptor that the last process used for netlink messages and expect to get 
> any
> data.
It _doesn't matter_ that I don't receive a response.  I have caused an 
operation in the kernel and the requested audit record is incorrect.  The audit 
subsystem needs to work even if - especially if - the userspace process is 
malicious.  The process might have wanted to simply cause a misleading audit 
record; or the operation (such as importing a key from supplied data) might not 
really need the response in order to achieve its effect.

> > > And
> > > in the event that happens, Audit should log a close event on the
> fd inquestion
> > > between the operations.
> > audit only logs explicitly requested operations, so an administrator
> that asks for crypto events does not automatically get any close
> events.  Besides, the audit record should be correct in the first
> place, instead of giving the admin a puzzle to decipher.
> I still don't see whats incorrect here.  If two processes wind up reusing a
> process id, thats audits problem to figure out, nothing elses.
If an operation attributed to user A is recorded by the kernel as being 
performed by user B, that is not an user problem.

> What exactly is
> the problem that you see involving netlink and audit here?  Compare whatever
> problem you see a crypto netlink protocol having in regards to audit to 
> another
> netlink protocol (say rtnetlink), and explain to me why the latter doesn't 
> have
> that issue as well.
AFAIK most netlink users in the kernel are not audited, and those that are 
typically only allow operations by system administrators.  And I haven't 
claimed that the other users are correct :)  Notably audit itself does not 
record as much information about the invoking process as we'd like because it 
is not available.

> > > Theres also the child process case, in which a child process might read
> > > responses from requests sent by a parent, and vice versa, since fork 
> > > inherits
> > > file descriptors, but thats an issue inherent in any mechanism you use,
> > > including the character interface, so I'm not sure what the problem is
> > > there.
> > Actually that's not a problem with ioctl() because the response is
> written back _before_ ioctl() returns, so it is always provided to the
> original calling thread.
> > 
> > With the current design the parent and child share the key/session
> namespace after fork(), but operation results are always reliably and
> automatically provided to the thread that invoked the operation,
> without any user-space collaboration.

> Is that _really_ that important?  That the kernel return data in the same call
> that its made?
Not for audit; but yes, it is important.

1) performance: this is not ip(8), where no one cares if the operation runs 
10ms or 1000ms.  Crypto is at least 2 operations per SSL record (which can be 
as little as 1 byte of application data), and users will care about the speed.  
Batching more operations into a single request is impractical because it would 
require very extensive changes in users of the crypto libraries, and the 
generic crypto interfaces such as PKCS#11 don't natively support batching so it 
might not even be possible to express this in some libraries.

2) simplicity and reliability: you are downplaying the overhead and 
synchronization necessary (potentially among multiple processes!) to simply 
receive a response, but it is still enormous compared to the single syscall 
case.  Even worse, netlink(7) says "netlink is not a reliable protocol.  ... 
but may drop messages".  Would you accept such a mechanism to transfer "write 
data to file" operations?  "Compress data using AES" is much more similar to 
"write data to file" than to "change this aspect of kernel routing 
configuration" - it is an application-level service, not a way to communicate 
long-term parameters to a pretty independent subsystem residing in the kernel.
    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