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. 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. 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. Is this a good enough description ? If not can you clarify your expectations ? > 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. 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. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc -- 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
