lkml.org 
[lkml]   [2017]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFC: Audit Kernel Container IDs
    On 2017-09-14 12:33, Eric W. Biederman wrote:
    > Richard Guy Briggs <rgb@redhat.com> writes:
    >
    > > The trigger is a pseudo filesystem (proc, since PID tree already exists)
    > > write of a u64 representing the container ID to a file representing a
    > > process that will become the first process in a new container.
    > > This might place restrictions on mount namespaces required to define a
    > > container, or at least careful checking of namespaces in the kernel to
    > > verify permissions of the orchestrator so it can't change its own
    > > container ID.
    >
    > Why a u64?

    u32 will roll too quickly. UUID is large enough that it adds
    significantly to audit record bandwidth. I'd prefer u64, but can look
    at the difference of accommodating a UUID...

    > Why a proc filesystem write and not a magic audit message?

    A magic audit message requires CAP_AUDIT_WRITE, which we'd like to use
    sparingly. Given that orchestrators will already require it to send
    the mandatory AUDIT_VIRT_*, this doesn't seem like an unreasonable burden.

    I was originally leaning towards an audit message trigger or a syscall.

    > I don't like the fact that the proc filesystem entry is likely going to
    > be readable and abusable by non-audit contexts?

    This proposal wasn't going to start with that link being readable, but
    its filesystem structure and link names would be, perhaps giving away
    too much already.

    I think we will need to find a way for the orchestrator or one of its
    authorized agents to read this information while blocking reads from
    unauthorized agents, otherwise this would be of very limited use.

    > Why the ability to change the containerid? What is the use case you are
    > thinking of there?

    This was covered in the end of the conversation with Paul Moore (that
    maybe you got tired reading?) I'd originally proposed having it write
    once, but Paul figured there was no good reason to restrict it and leave
    that decision up to the orchestrator. The use case would be adding
    other processes to a container, but it could be argued all additional
    processes should be spawned by the first process in a container.

    > Eric

    - RGB

    --
    Richard Guy Briggs <rgb@redhat.com>
    Sr. S/W Engineer, Kernel Security, Base Operating Systems
    Remote, Ottawa, Red Hat Canada
    IRC: rgb, SunRaycer
    Voice: +1.647.777.2635, Internal: (81) 32635

    \
     
     \ /
      Last update: 2017-09-14 20:08    [W:5.547 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site