On 8/5/2015 1:08 PM, Steve Grubb wrote: > On Wednesday, August 05, 2015 03:16:58 PM Paul Moore wrote: >> On Wednesday, August 05, 2015 02:30:14 AM Richard Guy Briggs wrote: >>> On 15/08/04, Paul Moore wrote: >>>> On Saturday, August 01, 2015 03:42:23 PM Richard Guy Briggs wrote: >>>>> Signed-off-by: Richard Guy Briggs <r...@redhat.com> >>>>> --- >>>>> >>>>> include/uapi/linux/audit.h | 2 ++ >>>>> kernel/audit.c | 2 +- >>>>> kernel/audit_watch.c | 8 ++++---- >>>>> kernel/auditsc.c | 6 +++--- >>>>> 4 files changed, 10 insertions(+), 8 deletions(-) >>>> Yipee, less magic numbers! >>>> >>>> However, one question for you ... are we ever going to see a device or >>>> inode set to -1 in the userspace facing API? In other words, should the >>>> new #defines go in the uapi headers or simply in kernel/audit.h? Unless >>>> it is part of the API, let's leave it out of uapi as we have to be very >>>> careful about that stuff and I'd prefer to keep it minimal. >>> This is a good point. I did briefly thing about this at one point. >>> Perhaps Steve can answer this. It would be trivial to move it back to >>> uapi if needed. Would you be ok with it in include/linux/audit.h for >>> now? >> I have no problem with it in include/linux/audit.h, that is a kernel-only >> include that we can change at anytime. My concern is putting it into a uapi >> header which makes it very hard to change. >> >> I'm thinking we should just go ahead and put it in include/linux/audit.h for >> now as I can't think of a reason why userspace should be passing in an >> invalid dev/inode value, it just doesn't make sense. If the invalid tokens >> prove to be valuable for userspace, we can always move the #defines. > I can't imagine anyone auditing against a specific device or inode. Its like > auditing a pid when you really want the program name. Its much more useful to > audit by filename or directory and not inode/device. So, do whatever you > want. > The only unset value that people actually use is the auid because deamons > have > it unset.
I remember the Orange Book days when we were *required* to audit by dev/inode because it was the only true way to identify the object. Yes, it's analogous to auditing the pid, but we had to audit by that, too. The dev/indode and pid are the "true" names. Anything else is a hint at what you're looking at. I can easily imaging someone who really cares about the audit data supplying the dev/inode and pid. > > -Steve > > -- > Linux-audit mailing list > linux-au...@redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
