On Wednesday, June 08, 2011 03:08:38 PM Eric Paris wrote:
> On Wed, Jun 8, 2011 at 3:00 PM, Mr Dash Four
>
> <mr.dash.four@xxxxxxxxxxxxxx> wrote:
> >> int audit_log_secctx(struct auditbuffer *ab, u32 secid)
> >> {
> >> int len, rc;
> >> char *ctx;
> >>
> >> rc = security_secid_to_secctx(sid, &ctx, &len);
> >> if (rc) {
> >> audit_panic("Cannot convert secid to context");
> >> } else {
> >> audit_log_format(ab, " subj=%s", ctx);
> >> security_release_secctx(ctx, len);
> >> }
> >> return rc;
> >> }
> >>
> >> Such a function could be used a couple of places in the audit code
> >> itself.
> >
> > My view on this is that LSM error-handling should be part of LSM.
> >
> > I presume security_secid_to_secctx is going to be called from quite a few
> > places (well, I know of at least two now and they have nothing to do with
> > the LSM) and in my opinion it would be better if that error handling, if
> > adopted, is implemented within the function itself - whether by calling
> > another function, like the one you proposed above, or as part of the
> > secctx retrieval - this could be open to interpretation, but the point I
> > am trying to make is that whichever code security_secid_to_secctx is
> > invoked from shouldn't be involved in reporting/handling (internal LSM)
> > errors at all.
> >
> > I think I made that point in my previous post, but just wanted to make
> > sure that is the case.
>
> The LSM might report and error. It's up to the caller to figure out
> how to deal with that error. In this case we want to use the audit
> system so it's up to the audit system how to handle that error.
We are happy recording the failed number. Its the LSM people that say nuke the system.
So, I would put that in security_secid_to_secctx() so that everyone knows whose
requirements it was to do the nuclear option.
-Steve
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
