Thanks. Too bad, having the checks on the receiving side would have
been nice.
I will see if I can come up with a clean solution through dummy.c on the
netlink_send side before I leave this weekend. The use of the
CAP_SYS_ADMIN checks on the receiving side in the mainline code should
be fixed...
-serge
On Wed, 2004-09-15 at 14:39, Stephen Smalley wrote:
On Wed, 2004-09-15 at 15:31, Serge E. Hallyn wrote:
> > Sorry, I wasn't thinking in my initial response. These operations are
> > exported via netlink, which is async, right? Hence, permission checks
>
> I was wondering about that. Based on the original code I assumed that
> it was synchronous.
>
> Taking a second look at net/netlink, I guess not.
>
> Is there any reason why we can't find the task belonging to
> NETLINK_CREDS(skb)->pid and send that along to the security_* hooks?
Race conditions. Untrusted sender fires off a netlink message to set
some value, then immediately exec's a privilege-changing program so that
when the receiver evaluates the task's credentials, the task is running
privileged. I think you either have to do all of your mediation at
netlink_send time (as in the SELinux code) or get a security field into
netlink_skb_parms (but then you have lifecycle management issues, which
seems difficult to separate from having a general security field in the
sk_buff itself).
--
=======================================================
Serge Hallyn
Security Software Engineer, IBM Linux Technology Center
serue(a)us.ibm.com