11:41 a.m.
On Wed, 2004-09-15 at 10:02, Stephen Smalley wrote:
On Wed, 2004-09-15 at 09:59, Serge Hallyn wrote:
case AUDIT_SET:
- if (!capable(CAP_SYS_ADMIN))
- return -EPERM;
+ err = security_audit_set(status_get->mask);
+ if (err)
+ return err;
status_get = (struct audit_status *)data;
Hook is called _before_ setting of status_get?
Good point, we should send the status_get to the hook for finer-grained
controls.
And what checks that the
data length is at least sizeof(struct audit_status)? Looks like the
existing code is assuming that the caller didn't send a short message.
True.
@@ -364,8 +365,9 @@ static int audit_receive_msg(struct sk_b
audit_log_end(ab);
break;
case AUDIT_LOGIN:
- if (!capable(CAP_SYS_ADMIN))
- return -EPERM;
+ err = security_audit_login();
+ if (err)
+ return err;
login = (struct audit_login *)data;
ab = audit_log_start(NULL);
if (ab) {
Why not call the hook after extracting the data (and again, checking the
length) and pass the audit_login info to the hook.
I would also suggest a hook on AUDIT_USER.
Thanks, I will send a new patch with each of these incorporated.
-serge
--
=======================================================
Serge Hallyn
Security Software Engineer, IBM Linux Technology Center
serue(a)us.ibm.com
1:53 p.m.
New subject: [PATCH] LSM hooks for audit
Sorry, I wasn't thinking in my initial response. These operations are
exported via netlink, which is async, right? Hence, permission checks
based on current, including the existing capable() checks, are bogus;
you would be checking in the receiving context, not necessarily the
sending context. Sending context is not conveyed at present via
netlink_skb_parms (no security field) other than uid and capability
set. You can performs check upon netlink_send; see what SELinux does
there. SELinux policy already governs ability to create and use
netlink_audit_sockets and maps the netlink operations to read or write
flows, but doesn't offer any finer granularity than that.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
2:31 p.m.
New subject: [PATCH] LSM hooks for audit
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?
thanks,
-serge
2:39 p.m.
New subject: [PATCH] LSM hooks for audit
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).
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
6:57 p.m.
New subject: [PATCH] LSM hooks for audit
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
12:19 p.m.
New subject: [PATCH] LSM hooks for audit
Attached is a patch which moves the audit control authorization checks
to the netlink send side. They are automatically performed from the
dummy and capability LSM's, and if no LSMs are loaded. Based on this
patch, there would be no explicit LSM support for audit control, but the
audit_get_msgtype(sk, skb) function can be used by LSM's to keep their
security_netlink_send functions at least a little cleaner.
thanks,
-serge
--
=======================================================
Serge Hallyn
Security Software Engineer, IBM Linux Technology Center
serue(a)us.ibm.com
7400
days inactive
7402
days old
linux-audit@lists.linux-audit.osci.io
5 comments
3 participants
participants (3)
-
Serge E. Hallyn -
Serge Hallyn -
Stephen Smalley