[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ehbvivr5.fsf@xmission.com>
Date: Fri, 21 Jun 2013 03:49:34 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Daniel J Walsh <dwalsh@...hat.com>
Cc: Gao feng <gaofeng@...fujitsu.com>, Eric Paris <eparis@...hat.com>,
containers@...ts.linux-foundation.org, serge.hallyn@...ntu.com,
linux-kernel@...r.kernel.org, linux-audit@...hat.com,
matthltc@...ux.vnet.ibm.com, Aristeu Rozanski <aris@...hat.com>
Subject: Re: [Part1 PATCH 00/22] Add namespace support for audit
Daniel J Walsh <dwalsh@...hat.com> writes:
> Will I be able to use the audit namespace without the user namespace. I would
> prefer to be able to use the audit namespace long before I am willing to take
> a chance with the User Namespace for things like light weight virtualization
> and securing processes with MAC.
I will be very surprised if we settle on a design that allows it.
I still think even the existence of multiple audit contexts is a little
iffy but the desire seems strong enough Gao feng will probably work
through all of the issues.
Without restricting processes to a user namespace at the same time as
restricting them to an audit context it becomes very easy to violate the
important audit policies and to bury user space generated messages from
privileged userspace applications. At least in a user namespace we know
you are not privileged with respect to the rest of the system, so we
would only be dealing with userspace messages you would not be able to
generate otherwise.
As for taking a chance. You will probably safer with a simultaneous use
of user namespaces and having processes secured with a MAC. To the best
of my knowledge previous solutions have only been really safe when you
trusted the processes inside not to be malicious. A user namespace at
least means you can stop using uid 0 inside of your light weight
virtualization.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists