On 10/17/2017 8:28 AM, Simo Sorce wrote: > On Tue, 2017-10-17 at 07:59 -0700, Casey Schaufler wrote: >> On 10/17/2017 5:31 AM, Simo Sorce wrote: >>> On Mon, 2017-10-16 at 21:42 -0400, Steve Grubb wrote: >>>> On Monday, October 16, 2017 8:33:40 PM EDT Richard Guy Briggs >>>> wrote: >>>>> There is such a thing, but the kernel doesn't know about it >>>>> yet. This same situation exists for loginuid and sessionid >>>>> which >>>>> are userspace concepts that the kernel tracks for the >>>>> convenience >>>>> of userspace. As for its name, I'm not particularly picky, so >>>>> if >>>>> you don't like CAP_CONTAINER_* then I'm fine with >>>>> CAP_AUDIT_CONTAINERID. It really needs to be distinct from >>>>> CAP_AUDIT_WRITE and CAP_AUDIT_CONTROL since we don't want to >>>>> give >>>>> the ability to set a containerID to any process that is able to >>>>> do >>>>> audit logging (such as vsftpd) and similarly we don't want to >>>>> give >>>>> the orchestrator the ability to control the setup of the audit >>>>> daemon. >>>> A long time ago, we were debating what should guard against rouge >>>> processes from setting the loginuid. Casey argued that the >>>> ability to >>>> set the loginuid means they have the ability to control the audit >>>> trail. That means that it should be guarded by CAP_AUDIT_CONTROL. >>>> I >>>> think the same logic applies today. >>> The difference is that with loginuid you needed to give processes >>> able >>> to audit also the ability to change it. You do not want to tie the >>> ability to change container ids to the ability to audit. You want >>> to be >>> able to do audit stuff (within the container) without allowing it >>> to >>> change the container id. >> Without a *kernel* policy on containerIDs you can't say what >> security policy is being exempted. > The policy has been basically stated earlier. No. The expected user space behavior has been stated. > A way to track a set of processes from a specific point in time > forward. The name used is "container id", but it could be anything. Then you want Jose Bollo's PTAGS. It's insane to add yet another arbitrary ID to the task for a special purpose. Add a general tagging mechanism instead. We could add a gazillion new id's, each with it's own capability if we head down this road. > This marker is mostly used by user space to track process hierarchies > without races, these processes can be very privileged, and must not be > allowed to change the marker themselves when granted the current common > capabilities. Let's be clear. What happens in user space stays in user space. The kernel does not give a fig about user space policy. There has to be a kernel policy involved that a capability can exempt. > Is this a good enough description ? If not can you clarify your > expectations ? The kernel enforces kernel policy. Capabilities provide a mechanism to mark a process as exempt from some aspect of kernel policy. If you don't have a kernel policy, you don't get a capability. Clear? > >> Without that you can't say what capability is (or isn't) >> appropriate. > See if the above is sufficient please. > >> You need a reason to have a capability check that makes sense in the >> context of the kernel security policy. > I think the proposal had a reason, we may debate on whether that reason > is good enough. > >> Since we don't know what a container is in the kernel, > Please do not fixate on the word container. > >> that's pretty hard. We don't create "fuzzy" capabilities >> based on the trendy application behavior of the moment. If the >> behavior is not related it audit, there's no reason for it, and >> if it is, CAP_AUDIT_CONTROL works just fine. If this doesn't work >> in your application security model I suggest that is where you >> need to make changes. > The authors of the proposal came to the conclusion that kernel > assistance is needed. It would be nice to discuss the merits of it. > If you do not understand why the request has been made it would be more > useful to ask specific questions to understand what and why is the ask. I understand pretty darn well. > Pushing back is fine, if you have understood the problem and have valid > arguments against a kernel level solution (and possibly suggestions for > a working user space solution), otherwise you are not adding value to > the discussion. The presumption is that the request is reasonable. Adding a capability in support of an undefined behavior is unreasonable. Based on the discussion, CAP_AUDIT_CONTROL is completely rational. I understand that it would be difficult to support your application privilege model. I would like to look into helping out with that, but have too many burning knives in the air just now. > > Simo. > -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
