Steve Grubb <sgrubb@xxxxxxxxxx> writes: > On Tuesday, May 12, 2015 03:57:59 PM Richard Guy Briggs wrote: >> On 15/05/05, Steve Grubb wrote: >> > I think there needs to be some more discussion around this. It seems like >> > this is not exactly recording things that are useful for audit. >> >> It seems to me that either audit has to assemble that information, or >> the kernel has to do so. The kernel doesn't know about containers >> (yet?). > > Auditing is something that has a lot of requirements imposed on it by security > standards. There was no requirement to have an auid until audit came along and > said that uid is not good enough to know who is issuing commands because of su > or sudo. There was no requirement for sessionid until we had to track each > action back to a login so we could see if the login came from the expected > place. Stop right there. You want a global identifier in a realm where only relative identifiers exist, and make sense. I am sorry that isn't going to happen. EVER. Square peg, round hole. It doesn't work, it doesn't make sense, and most especially it doesn't allow anyone to reconstruct anything, because it does not make sense and does not match what the kernel is doing. Container IDs do not, and will not exist. There is probably something reasonable in your request but until you stop talking that nonsense I can't see it. Global IDs take us into the namespace of namespaces problem and that isn't going to happen. I have already bent as far in this direction as I can go. Further namespace creation is not a privileged event which makes the requestion for a container ID make even less sense. With anyone able to create whatever they want it will not be a identifier that makes any sense to someone reading an audit log. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
