lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ