3:40 p.m.
Linux provides two apis to add/delete/manage SAs and spd.
One is netlink which was extended to do key management. The
other is pfkeyv2, which our setkey and racoon uses.
With all that said, I am not able to figure out how to get "auid" from
pfkeyv2? I can use NETLINK_CB(skb).loginuid to get it when netlink is
used, but I don't think I can use this for pfkeyv2 since I am not using
netlink headers. I am using pfkey message headers, such as sadb_msg,
which don't include this.
Any ideas or suggestions?
Regards,
Joy
3:58 p.m.
New subject: [redhat-lspp] auditing labeled ipsec
Joy Latten wrote:
Linux provides two apis to add/delete/manage SAs and spd.
One is netlink which was extended to do key management. The
other is pfkeyv2, which our setkey and racoon uses.
With all that said, I am not able to figure out how to get "auid" from
pfkeyv2? I can use NETLINK_CB(skb).loginuid to get it when netlink is
used, but I don't think I can use this for pfkeyv2 since I am not using
netlink headers. I am using pfkey message headers, such as sadb_msg,
which don't include this.
Any ideas or suggestions?
While it's been a looong time since I looked at PFKEY I believe you can get away
with plucking the loginuid from the current task, yes? no?
--
paul moore
linux security @ hp
4:43 p.m.
New subject: [redhat-lspp] auditing labeled ipsec
On Wed, 2006-10-11 at 16:58 -0400, Paul Moore wrote:
Joy Latten wrote:
> Linux provides two apis to add/delete/manage SAs and spd.
> One is netlink which was extended to do key management. The
> other is pfkeyv2, which our setkey and racoon uses.
>
> With all that said, I am not able to figure out how to get "auid" from
> pfkeyv2? I can use NETLINK_CB(skb).loginuid to get it when netlink is
> used, but I don't think I can use this for pfkeyv2 since I am not using
> netlink headers. I am using pfkey message headers, such as sadb_msg,
> which don't include this.
>
> Any ideas or suggestions?
While it's been a looong time since I looked at PFKEY I believe you can get away
with plucking the loginuid from the current task, yes? no?
I was also wondering if that would be ok?
Joy
5:23 p.m.
New subject: [redhat-lspp] auditing labeled ipsec
On Wed, Oct 11, 2006 at 04:43:16PM -0500, Joy Latten wrote:
On Wed, 2006-10-11 at 16:58 -0400, Paul Moore wrote:
> While it's been a looong time since I looked at PFKEY I believe you can get
away
> with plucking the loginuid from the current task, yes? no?
>
I was also wondering if that would be ok?
If it's accurate when nobody is actively trying to subvert it, that's
good enough for the purposes of LSPP/CAPP evaluation where admins are
presumed to be trustworthy.
-Klaus
9:16 a.m.
New subject: [redhat-lspp] auditing labeled ipsec
Steve Grubb wrote:
On Wednesday 11 October 2006 16:40, Joy Latten wrote:
>The other is pfkeyv2, which our setkey and racoon uses.
What is pfkeyv2? IOW is it a syscall or how do you call it?
PF_KEYv2 is a socket family/protocol defined by RFC2367 whose original goal was
to standardize the interface between the in-kernel IPsec bits and the userland
key management daemon. It has it's problems but it also has a lot of
cross-platform support.
--
paul moore
linux security @ hp
9:24 a.m.
New subject: [redhat-lspp] auditing labeled ipsec
On Thursday 12 October 2006 10:16, Paul Moore wrote:
PF_KEYv2 is a socket family/protocol defined by RFC2367 whose
original goal
was to standardize the interface between the in-kernel IPsec bits and the
userland key management daemon.
OK, then the question becomes is the communication protocol asyncronous or
synchronous? If synchronous (the request is handled immediately and not
queued like netlink), then current task struct can be used. Otherwise, there
may be some more code needed to grab the loginuid during the send and store
it with the packet until dequeued. If it is async, there may be selinux
implications as well.
-Steve
4:34 p.m.
New subject: [redhat-lspp] auditing labeled ipsec
On Thu, 2006-10-12 at 10:24 -0400, Steve Grubb wrote:
On Thursday 12 October 2006 10:16, Paul Moore wrote:
> PF_KEYv2 is a socket family/protocol defined by RFC2367 whose original goal
> was to standardize the interface between the in-kernel IPsec bits and the
> userland key management daemon.
OK, then the question becomes is the communication protocol asyncronous or
synchronous? If synchronous (the request is handled immediately and not
queued like netlink), then current task struct can be used. Otherwise, there
may be some more code needed to grab the loginuid during the send and store
it with the packet until dequeued. If it is async, there may be selinux
implications as well.
pfkey doesn't appear to use a queue like netlink... it registers socket
protocol operations such as .recvmsg and .sendmsg which get called via
sock_recvmsg and sock_sendmsg.
Joy
6722
days inactive
6724
days old
linux-audit@lists.linux-audit.osci.io
7 comments
4 participants
participants (4)
-
Joy Latten -
Klaus Weidner -
Paul Moore -
Steve Grubb