--- Paul Moore <[EMAIL PROTECTED]> wrote:
> Add a secctx_to_secid() LSM hook to go along with the existing
> secid_to_secctx() LSM hook.
I'll bite. Where does this get used?
There are already places in the networking and audit code where
a secid is gotten and saved for the sole purpose of getting a secctx
at some later time. My favorite example:
> static void ip_cmsg_recv_security(struct msghdr *msg, struct sk_buff *skb)
> {
> char *secdata;
> u32 seclen, secid;
> int err;
In the Smack case what's in skb is the secctx.
> err = security_socket_getpeersec_dgram(NULL, skb, &secid);
> if (err)
> return;
Smack pulls the secctx off the packet and finds a secid for it.
> err = security_secid_to_secctx(secid, &secdata, &seclen);
> if (err)
> return;
Just so that it can turn around and look up the secctx it had in the
first place.
> put_cmsg(msg, SOL_IP, SCM_SECURITY, seclen, secdata);
> security_release_secctx(secdata, seclen);
Fortunatly, this is no-op.
> }
I expect that the purpose of the proposed secctx_to_secid() is to
make it easier to implement more of these cases, where the only
reason to do the conversion is to have something to convert back
later. With SELinux as the only consumer of the LSM, and with the
SELinux secid mindset I suppose this could make sense. It would
also be perfectly reasonable if there was anything to do with a
secid except convert it to a secctx, but there isn't.
There. I got the righteous indignation off my chest. I say to
go ahead with adding this to the LSM because I need it to for
dealing with the aformentioned audit code, which I have looked
into fixing to use secctx instead of secid, and determined that
there are a couple cases where you end up with the secid in any
case.
In Linux 2.7 I propose that we fix these problems. Not today.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html