Quoting David Herrmann (dh.herrm...@gmail.com):
> Hi
>
> This series adds a new LSM hook for the socketpair(2) syscall. The idea
> is to allow SO_PEERSEC to be called on AF_UNIX sockets created via
> socketpair(2), and return the same information as if you emulated
> socketpair(2) via a temporary
Quoting Richard Guy Briggs (r...@redhat.com):
> Implement audit kernel container ID.
>
> This patchset is a preliminary RFC based on the proposal document (V3)
> posted:
> https://www.redhat.com/archives/linux-audit/2018-January/msg00014.html
Patchset looks good to me.
Acked-by: Serge Hall
On Thu, Mar 01, 2018 at 02:41:04PM -0500, Richard Guy Briggs wrote:
...
> +static inline bool audit_containerid_set(struct task_struct *tsk)
Hi Richard,
the calls to audit_containerid_set() confused me. Could you make it
is_audit_containerid_set() or audit_containerid_isset()?
> +{
> + retu
On Fri, Feb 02, 2018 at 05:05:22PM -0500, Paul Moore wrote:
> On Tue, Jan 9, 2018 at 7:16 AM, Richard Guy Briggs wrote:
> > Containers are a userspace concept. The kernel knows nothing of them.
> >
> > The Linux audit system needs a way to be able to track the container
> > provenance of events a
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> On Mon, Jan 8, 2018 at 10:36 AM, Serge E. Hallyn wrote:
> > Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> >> On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn wrote:
> >> > Quoting Mahesh
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> On Mon, Jan 8, 2018 at 10:11 AM, Serge E. Hallyn wrote:
> > Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> >> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn wrote:
> >> > Quo
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> On Mon, Jan 8, 2018 at 7:47 AM, Serge E. Hallyn wrote:
> > Quoting James Morris (james.l.mor...@oracle.com):
> >> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
> >> I meant in terms of "marking" a
Quoting James Morris (james.l.mor...@oracle.com):
> On Mon, 8 Jan 2018, Serge E. Hallyn wrote:
>
> > > Also, why do we need the concept of a controlled user-ns at all, if the
> > > default whitelist maintains existing behavior?
> >
> > In past discu
On Mon, Jan 08, 2018 at 11:35:26AM +1100, James Morris wrote:
> On Tue, 2 Jan 2018, Mahesh Bandewar (महेश बंडेवार) wrote:
>
> > On Sat, Dec 30, 2017 at 12:31 AM, James Morris
> > wrote:
> > > On Wed, 27 Dec 2017, Mahesh Bandewar (महेश बंडेवार) wrote:
> > >
> > >> Hello James,
> > >>
> > >> Seems
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> On Wed, Nov 29, 2017 at 9:57 AM, Serge E. Hallyn wrote:
> > Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> >> On Tue, Nov 28, 2017 at 3:04 PM, Serge E. Hallyn wrote:
> >> > Quoting Mahesh
On Wed, Nov 29, 2017 at 07:35:31PM -0500, Theodore Ts'o wrote:
> On Wed, Nov 29, 2017 at 11:28:52AM -0600, Serge E. Hallyn wrote:
> >
> > Just to be clear, module loading requires - and must always continue to
> > require - CAP_SYS_MODULE against the initial user nam
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> On Tue, Nov 28, 2017 at 3:04 PM, Serge E. Hallyn wrote:
> > Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> > ...
> >> >> diff --git a/security/commoncap.c b/security/commoncap.c
> >&
Quoting Theodore Ts'o (ty...@mit.edu):
> Half the problem here is that with containers, people are changing the
> security model, because they want to let untrusted users have "root",
> without really having "root". Part of the fundamental problem is that
> there are some well-meaning, but fundame
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
...
> >> diff --git a/security/commoncap.c b/security/commoncap.c
> >> index fc46f5b85251..89103f16ac37 100644
> >> --- a/security/commoncap.c
> >> +++ b/security/commoncap.c
> >> @@ -73,6 +73,14 @@ int cap_capable(const struct cred *cred
Quoting Mahesh Bandewar (mah...@bandewar.net):
> From: Mahesh Bandewar
>
> With this new notion of "controlled" user-namespaces, the controlled
> user-namespaces are marked at the time of their creation while the
> capabilities of processes that belong to them are controlled using the
> global ma
Quoting Mahesh Bandewar (mah...@bandewar.net):
> From: Mahesh Bandewar
>
> Add a sysctl variable kernel.controlled_userns_caps_whitelist. This
> takes input as capability mask expressed as two comma separated hex
> u32 words. The mask, however, is stored in kernel as kernel_cap_t type.
>
> Any c
Quoting Eric W. Biederman (ebied...@xmission.com):
> single sandbox. I am not at all certain that the capabilities is the
> proper place to limit code reachability.
Right, I keep having this gut feeling that there is another way we
should be doing that. Maybe based on ksplice or perf, or maybe m
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
...
> >>
> >> ==
> >>
> >> +controlled_userns_caps_whitelist
> >> +
> >> +Capability mask that is whitelisted for "controlled" user namespaces.
> >> +Any capability that is miss
Quoting chris hyser (chris.hy...@oracle.com):
> On 11/06/2017 10:23 PM, Serge E. Hallyn wrote:
> >I think I definately prefer what I mentioned in the email to Boris.
> >Basically a "permanent capability bounding set". The normal bounding
> >set gets reset to
Quoting Mahesh Bandewar (mah...@bandewar.net):
> From: Mahesh Bandewar
>
> Add a sysctl variable kernel.controlled_userns_caps_whitelist. This
I understand the arguments in favor of whitelists in most cases for
security purposes. But given that you've said the goal here is to
prevent use of a c
Quoting Mahesh Bandewar (mah...@bandewar.net):
> From: Mahesh Bandewar
>
> With this new notion of "controlled" user-namespaces, the controlled
> user-namespaces are marked at the time of their creation while the
> capabilities of processes that belong to them are controlled using the
> global ma
Quoting Mahesh Bandewar (mah...@bandewar.net):
> From: Mahesh Bandewar
>
> Add a sysctl variable kernel.controlled_userns_caps_whitelist. This
> takes input as capability mask expressed as two comma separated hex
> u32 words. The mask, however, is stored in kernel as kernel_cap_t type.
>
> Any c
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> Of course. Let's take an example of the CVE that I have mentioned in
> my cover-letter -
> CVE-2017-7308(https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7308).
> It's well documented and even has a
> exploit(https://github.com/x
On Thu, Nov 09, 2017 at 09:55:41AM +0900, Mahesh Bandewar (महेश बंडेवार) wrote:
> On Thu, Nov 9, 2017 at 4:02 AM, Christian Brauner
> wrote:
> > On Wed, Nov 08, 2017 at 03:09:59AM -0800, Mahesh Bandewar (महेश बंडेवार)
> > wrote:
> >> Sorry folks I was traveling and seems like lot happened on this
On Mon, Nov 06, 2017 at 07:01:58PM -0500, Boris Lukashev wrote:
> On Mon, Nov 6, 2017 at 6:39 PM, Serge E. Hallyn wrote:
> > Quoting Boris Lukashev (blukas...@sempervictus.com):
> >> On Mon, Nov 6, 2017 at 5:14 PM, Serge E. Hallyn wrote:
> >> > Quoting Danie
On Mon, Nov 06, 2017 at 09:16:03PM -0500, Daniel Micay wrote:
> On Mon, 2017-11-06 at 16:14 -0600, Serge E. Hallyn wrote:
> > Quoting Daniel Micay (danielmi...@gmail.com):
> > > Substantial added attack surface will never go away as a problem.
> > > There
>
Quoting Boris Lukashev (blukas...@sempervictus.com):
> On Mon, Nov 6, 2017 at 5:14 PM, Serge E. Hallyn wrote:
> > Quoting Daniel Micay (danielmi...@gmail.com):
> >> Substantial added attack surface will never go away as a problem. There
> >> aren't a finite numbe
Quoting Daniel Micay (danielmi...@gmail.com):
> Substantial added attack surface will never go away as a problem. There
> aren't a finite number of vulnerabilities to be found.
There's varying levels of usefulness and quality. There is code which I
want to be able to use in a container, and code
Quoting Mahesh Bandewar (महेश बंडेवार) (mahe...@google.com):
> On Sat, Nov 4, 2017 at 4:53 PM, Serge E. Hallyn wrote:
> >
> > Quoting Mahesh Bandewar (mah...@bandewar.net):
> > > Init-user-ns is always uncontrolled and a process that has SYS_ADMIN
> > > that be
Quoting Mahesh Bandewar (mah...@bandewar.net):
> Init-user-ns is always uncontrolled and a process that has SYS_ADMIN
> that belongs to uncontrolled user-ns can create another (child) user-
> namespace that is uncontrolled. Any other process (that either does
> not have SYS_ADMIN or belongs to a co
Quoting Mahesh Bandewar (mah...@bandewar.net):
> From: Mahesh Bandewar
>
> [Same as the previous RFC series sent on 9/21]
>
> TL;DR version
> -
> Creating a sandbox environment with namespaces is challenging
> considering what these sandboxed processes can engage into. e.g.
> CVE-201
On Mon, Dec 05, 2016 at 04:36:51PM -0800, Andy Lutomirski wrote:
> On Mon, Dec 5, 2016 at 4:28 PM, John Stultz wrote:
> > On Tue, Nov 22, 2016 at 4:57 PM, John Stultz wrote:
> >> On Tue, Nov 8, 2016 at 4:12 PM, Andy Lutomirski
> >> wrote:
> >>> On Tue, Nov 8, 2016 at 4:03 PM, Alexei Starovoitov
Quoting Eric W. Biederman (ebied...@xmission.com):
> Signed-off-by: "Eric W. Biederman"
Acked-by: Serge Hallyn
Thanks, Eric.
> ---
> fs/namespace.c | 19 ++-
> include/linux/user_namespace.h | 1 +
> kernel/user_namespace.c| 1 +
> 3 files changed, 20
Quoting Eric W. Biederman (ebied...@xmission.com):
> Signed-off-by: "Eric W. Biederman"
Acked-by: Serge Hallyn
> ---
> include/linux/user_namespace.h | 1 +
> kernel/user_namespace.c| 1 +
> net/core/net_namespace.c | 15 +++
> 3 files changed, 17 insertions(+)
>
>
Quoting Eric W. Biederman (ebied...@xmission.com):
> Signed-off-by: "Eric W. Biederman"
Acked-by: Serge Hallyn
> ---
> include/linux/user_namespace.h | 1 +
> kernel/cgroup.c| 15 +++
> kernel/user_namespace.c| 1 +
> 3 files changed, 17 insertions(+)
>
>
Quoting Eric W. Biederman (ebied...@xmission.com):
> Signed-off-by: "Eric W. Biederman"
Acked-by: Serge Hallyn
> ---
> include/linux/user_namespace.h | 1 +
> ipc/namespace.c| 42
> +++---
> kernel/user_namespace.c| 1 +
> 3 files
Quoting Eric W. Biederman (ebied...@xmission.com):
> Signed-off-by: "Eric W. Biederman"
Acked-by: Serge Hallyn
> ---
> include/linux/user_namespace.h | 1 +
> kernel/user_namespace.c| 1 +
> kernel/utsname.c | 31 ++-
> 3 files changed, 28 in
Quoting Eric W. Biederman (ebied...@xmission.com):
> Signed-off-by: "Eric W. Biederman"
Acked-by: Serge Hallyn
> ---
> include/linux/user_namespace.h | 1 +
> kernel/pid_namespace.c | 22 ++
> kernel/user_namespace.c| 1 +
> 3 files changed, 20 insertions(
Quoting Eric W. Biederman (ebied...@xmission.com):
> The same kind of recursive sane default limit and policy
> countrol that has been implemented for the user namespace
> is desirable for the other namespaces, so generalize
> the user namespace refernce count into a ucount.
>
> Signed-off-by: "Er
Quoting Eric W. Biederman (ebied...@xmission.com):
> Export the export the maximum number of user namespaces as
^ note if you resend, duplicate "export the"
> /proc/sys/userns/max_user_namespaces.
>
> Signed-off-by: "Eric W. Biederman"
Acked-by: Serge Hallyn
> ---
> include/linux/user_names
On Mon, Dec 07, 2015 at 05:38:50PM -0500, Tejun Heo wrote:
> Implement cgroup_get_from_path() using kernfs_walk_and_get() which
> obtains a default hierarchy cgroup from its path. This will be used
> to allow cgroup path based matching from outside cgroup proper -
> e.g. networking and perf.
Hi T
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
> >
> > Hey Eric,
> >
> > the patches look nice.
> >
> > The hand-forcing of the passed-in net_ns into a copy of current->nsproxy
> >
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>
> The user interface is: register_net_sysctl_table and
> unregister_net_sysctl_table. Very much like the current
> interface except there is a network namespace parameter.
>
> With this any sysctl registered with register_net_sysctl_table
> will o
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>
> In the -mm tree the rules for access an nsproxy have changed,
> and in get_net_ns_by_pid we access the nsproxy, so update
> it to follow the new rules.
>
> Signed-off-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
Yup, looks right.
I assume Pavel'
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
> >>
> >> +static struct net *get_net_ns_by_pid(pid_t pid)
> >> +{
> >> + struct task_struct *tsk;
> >> + struct net *net;
> &g
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
>
> The simplest thing to implement is moving network devices between
> namespaces. However with the same attribute IFLA_NET_NS_PID we can
> easily implement creating devices in the destination network
> namespace as well. However that is a little b
Quoting Jeff Garzik ([EMAIL PROTECTED]):
> Eric W. Biederman wrote:
> >Jeff Garzik <[EMAIL PROTECTED]> writes:
> >
> >>David Miller wrote:
> >>>I don't accept that we have to add another function argument
> >>>to a bunch of core routines just to support this crap,
> >>>especially since you give no
Quoting David Miller ([EMAIL PROTECTED]):
> From: [EMAIL PROTECTED] (Eric W. Biederman)
> Date: Sat, 23 Jun 2007 11:19:34 -0600
>
> > Further and fundamentally all a global achieves is removing the need
> > for the noise patches where you pass the pointer into the various
> > functions. For long
namespaces to show up in -mm :)
(Not intended for *any* sort of inclusion consideration :)
Example usage:
ifconfig eth0:0 192.168.1.16
echo -n "ip 192.168.1.16" > /proc/$$/attr/exec
exec /bin/sh
-serge
From: Serge E. Hallyn <[EMAIL PROTECTED](none)>
Date: Wed
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> This whole debate on network devices show up in multiple network namespaces
> is just silly. The only reason for wanting that appears to be better
> management.
A damned good reason. Clearly we want the parent namespace to be able
to control what
Quoting Cedric Le Goater ([EMAIL PROTECTED]):
> Sam Vilain wrote:
> > jamal wrote:
> >>> note: personally I'm absolutely not against virtualizing
> >>> the device names so that each guest can have a separate
> >>> name space for devices, but there should be a way to
> >>> 'see' _and_ 'identify' the
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
> > I think we're reaching the limits of namespaces. It would be much easier
> > with a container id in each kernel object we want to isolate.
>
> Nope. Except for the fact that names are peculiar (sockets, network
> device names, IP address, routes.
Quoting Kirill Korotaev ([EMAIL PROTECTED]):
> Cleanup of dev_base list use, with the aim to make device list
> per-namespace.
> In almost every occasion, use of dev_base variable and dev->next pointer
> could be easily replaced by for_each_netdev loop.
> A few most complicated
53 matches
Mail list logo
