Re: [PATCH] -mm (2.4.26-rc3-mm1) v2 Smack using capabilities 32 and 33

Quoting Casey Schaufler ([EMAIL PROTECTED]): > From: Casey Schaufler <[EMAIL PROTECTED]> > > This patch takes advantage of the increase in capability bits > to allocate capabilities for Mandatory Access Control. Whereas > Smack was overloading a previously allocated capability it is > now using a

[PATCH] capabilities: introduce per-process capability bounding set (v10)

>From 22da6ccb1a24d1b6fa481d990a26197c6bfdfa77 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Mon, 19 Nov 2007 13:54:05 -0500 Subject: [PATCH 1/1] capabilities: introduce per-process capability bounding set (v10) The capability bounding set is a set bey

[PATCH] file capabilities: don't prevent signaling setuid root programs.

a14f Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Tue, 20 Nov 2007 08:47:35 + Subject: [PATCH] file capabilities: don't prevent signaling setuid root programs. An unprivileged process must be able to kill a setuid root program started by the same us

Re: [PATCH] -mm (2.6.24-rc3-mm1) Smack using capabilities 32 and 33

Quoting Casey Schaufler ([EMAIL PROTECTED]): > From: Casey Schaufler <[EMAIL PROTECTED]> > > This patch takes advantage of the increase in capability bits > to allocate capabilities for Mandatory Access Control. Whereas > Smack was overloading a previously allocated capability it is > now using a

Re: [PATCH] 64bit capability support (legacy support fix)

Quoting Andrew Morton ([EMAIL PROTECTED]): > On Sat, 17 Nov 2007 21:25:27 -0800 Andrew Morgan <[EMAIL PROTECTED]> wrote: > > > The attached patch (171282b3553fcec43b9ab615eb7daf6c2b494a87) applies > > against 2.6.24-rc2-mm1. It addresses the problem reported by Kevin and > > Andy - ultimately, the

Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3

Quoting Chris Friedhoff ([EMAIL PROTECTED]): > On Tue, 20 Nov 2007 08:51:06 -0600 > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > Quoting Chris Friedhoff ([EMAIL PROTECTED]): > > > On Mon, 19 Nov 2007 17:16:44 -0600 > > > "Serge E. Hal

Re: [PATCH 1/1] capabilities: introduce per-process capability bounding set (v8)

Quoting Serge E. Hallyn ([EMAIL PROTECTED]): > How about the following? Argh, with the following on top of it... -serge >From 470a68120cda83875a281354b897f3bda04b58fc Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Tue, 20 Nov 2007 15:12:54 -0500 Subject

Re: [PATCH 1/1] capabilities: introduce per-process capability bounding set (v8)

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > > Andrew, this version follows all of your suggestions. Definately nicer > > userspace interface. thanks > [...] > > > > /* Al

Re: [PATCH 1/1] capabilities: introduce per-process capability bounding set (v8)

Quoting Serge E. Hallyn ([EMAIL PROTECTED]): > Quoting Andrew Morgan ([EMAIL PROTECTED]): > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Serge E. Hallyn wrote: > > > Andrew, this version follows all of your suggestions. Definately nice

Re: [PATCH 1/1] capabilities: introduce per-process capability bounding set (v8)

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > > Andrew, this version follows all of your suggestions. Definately nicer > > userspace interface. thanks > [...] > > > > /* Al

Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3

Quoting Chris Friedhoff ([EMAIL PROTECTED]): > On Mon, 19 Nov 2007 17:16:44 -0600 > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > Quoting Chris Friedhoff ([EMAIL PROTECTED]): > > > Hello Serge, > > > > > > just to let you know: wit

file capabilities ("ltp") tests

Just fyi, here are the ltp tests I try to use to test file capabilities. It's a patch against the 20070430 ltp release, though it won't actually be hooked in until i write a reliable little test for whether fscaps are in the kernel and supported by userspace so compilation and testing don't erroneo

Re: [PATCH] 64bit capability support (legacy support fix)

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Andrew, > > The attached patch (171282b3553fcec43b9ab615eb7daf6c2b494a87) applies > against 2.6.24-rc2-mm1. It addresses the problem reported by Kevin and > Andy - ultimately, the legacy support wasn'

Re: Posix file capabilities in 2.6.24rc2; now 2.6.24-rc3

Quoting Chris Friedhoff ([EMAIL PROTECTED]): > Hello Serge, > > just to let you know: with 2.6.24-rc3 I have the same problem. Ok, so here is the flow. First off, using runlevel 5 on FC7, using 'log out' correctly brings you back to a new login prompt. Your problem is starting in runlevel 3, an

[PATCH 1/1] capabilities: introduce per-process capability bounding set (v8)

Andrew, this version follows all of your suggestions. Definately nicer userspace interface. thanks -serge >From b7c210160e3c210d63eca532289ca1c9caf1bd87 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Mon, 19 Nov 2007 13:54:05 -0500 Subject: [PATCH 1/1] cap

Re: [PATCH 2/2] capabilities: introduce per-process capability bounding set (v7)

of per-process capability bounding sets to kernels with file capabilities compiled in, right? Are we ok with that? > This has scalability designed in, at the expense of more system calls to > get the same (rare) work done. > > Cheers > > Andrew Thanks, -serge > > Serge E.

[PATCH RFC] cgroups: implement device whitelist cgroup+lsm

(This patch is based against the same CONFIG_COMMONCAP patch as the capability bounding set patch I just sent out) >From fcbd0bd0a8ee1e37a68f5381b47ec0746cb9b1cc Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Thu, 11 Oct 2007 15:27:48 -0400 Subject: [PATCH 2/2

[PATCH 2/2] capabilities: introduce per-process capability bounding set (v7)

>From 9ba95f1dbf88a512ffd423f6ccd627dc0460b052 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Mon, 12 Nov 2007 16:50:04 -0500 Subject: [PATCH 2/2] capabilities: introduce per-process capability bounding set (v7) The capability bounding set is a set bey

[RFC PATCH 1/2] capabilities: define CONFIG_COMMONCAP

>From 1512a99aedb7a75ac993ccef91a42c97e1baefc5 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Fri, 28 Sep 2007 10:33:33 -0500 Subject: [PATCH 1/2] capabilities: define CONFIG_COMMONCAP currently the compilation of commoncap.c is determined through Makefile l

Re: [PATCH] 64 bit capabilities

Quoting KaiGai Kohei ([EMAIL PROTECTED]): > Andrew Morgan, > > >> I'll post the patch of setfcaps/getfcap for his tree. > >> I believe it is better way to maintain. > >> > >> Thanks, > > The following patch to libcap enables to display file capabilities > recursively on the enumerated directories

Re: [PATCH] 64 bit capabilities

mprovement/fix. > > Can you suggest a change that would satisfy you here? > > Thanks > > Andrew > > Serge E. Hallyn wrote: > > > Other than the one comment below, > > > Acked-by: Serge Hallyn <[EMAIL PROTECTED]> > > > >> > - -st

Re: [PATCH] 64 bit capabilities

kernel, you will first > have to undo this other patch from Serge: > > From b68680e4731abbd78863063aaa0dca2a6d8cc723 Mon Sep 17 00:00:00 2001 > From: Serge E. Hallyn <[EMAIL PROTECTED]> > Date: Sun, 21 Oct 2007 16:41:38 -0700 > Subject: [PATCH] capabilities: clean up file c

Re: [PATCH] 64 bit capabilities

> > > > Note: to apply this patch against Linus' upstream kernel, you will first > > have to undo this other patch from Serge: > > > > From b68680e4731abbd78863063aaa0dca2a6d8cc723 Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <[EMAIL PROTECTED]

Re: [PATCH] 64 bit capabilities

capability formats) > > http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.6/ > > Cheers > > Andrew > > Note: to apply this patch against Linus' upstream kernel, you will first > have to undo this other patch from Serge: > > From b68680e4731abbd7886306

Re: [RFC PATCH] 64-bit-capabilities

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge, > > Here is my latest iteration of the 64-bit support. This is basically it > (sans porting it to Andrew's mm tree). > > Cheers > > Andrew > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Peter Dolding wrote: > > On 11/1/07, Casey Schaufler <[EMAIL PROTECTED]> wrote: > >> --- Peter Dolding <[EMAIL PROTECTED]> wrote: > >> Posix capabilities predate SELinux. SELinux is not interested in >

Re: [PATCH 2/2] VFS: Reorder vfs_getxattr to avoid unnecessary calls to the LSM

Quoting David P. Quigley ([EMAIL PROTECTED]): > Originally vfs_getxattr would pull the security xattr variable using > the inode getxattr handle and then proceed to clobber it with a subsequent > call > to the LSM. This patch reorders the two operations such that when the xattr > requested is in t

Re: [PATCH 1/2] VFS/Security: Rework inode_getsecurity and callers to return resulting buffer

Quoting David P. Quigley ([EMAIL PROTECTED]): > This patch modifies the interface to inode_getsecurity to have the function > return a buffer containing the security blob and its length via parameters > instead of relying on the calling function to give it an appropriately sized > buffer. Security

Re: [PATCH] file capabilities: allow sigcont within session (v2)

Quoting Stephen Smalley ([EMAIL PROTECTED]): > On Wed, 2007-10-31 at 18:49 -0500, Serge E. Hallyn wrote: > > >From 5bff8967f45a35f858b96ca673d9bf98eac53d49 Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <[EMAIL PROTECTED]> > > Date: Wed, 31 Oct 2007 11:22:04 -0500

[PATCH] file capabilities: allow sigcont within session (v2)

>From 5bff8967f45a35f858b96ca673d9bf98eac53d49 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Wed, 31 Oct 2007 11:22:04 -0500 Subject: [PATCH 1/1] file capabilities: allow sigcont within session (v2) (This is a proposed fix to http://bugzilla.kernel.org/show_b

Re: [PATCH RFC] Alternative 64-bit capability patch

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge, > > Here is a more fully formed 64-bit capabilities patch than the one I > sent you last week. Its still subject to a bunch of testing. > > [The patch is against Linus' v2.6.24-rc1 tree.] Hi

Re: [PATCH] 2.6.23: Filesystem capabilities 0.17

Quoting Olaf Dietsche ([EMAIL PROTECTED]): > This patch implements filesystem capabilities. It allows to > run privileged executables without the need for suid root. > > Changes: > - updated to 2.6.23 > - fix const correctness > - fix secureexec > > This patch is available at: >

Re: [PATCH 1/2] VFS/Security: Rework inode_getsecurity and callers to return resulting buffer

Quoting David P. Quigley ([EMAIL PROTECTED]): > On Fri, 2007-10-26 at 10:02 -0500, Serge E. Hallyn wrote: > > Quoting David P. Quigley ([EMAIL PROTECTED]): > > > On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote: > > > > Quoting David P. Quigley ([EMAIL PROT

Re: [PATCH 1/2] VFS/Security: Rework inode_getsecurity and callers to return resulting buffer

Quoting Stephen Smalley ([EMAIL PROTECTED]): > On Fri, 2007-10-26 at 10:02 -0500, Serge E. Hallyn wrote: > > Quoting David P. Quigley ([EMAIL PROTECTED]): > > > On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote: > > > > Quoting David P. Quigley ([EMAIL PROT

Re: [PATCH 1/2] VFS/Security: Rework inode_getsecurity and callers to return resulting buffer

Quoting David P. Quigley ([EMAIL PROTECTED]): > On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote: > > Quoting David P. Quigley ([EMAIL PROTECTED]): > > > This patch modifies the interface to inode_getsecurity to have the > > > function return a buffer containin

Re: [PATCH 1/2] VFS/Security: Rework inode_getsecurity and callers to return resulting buffer

Quoting David P. Quigley ([EMAIL PROTECTED]): > On Thu, 2007-10-25 at 19:02 -0500, Serge E. Hallyn wrote: > > Quoting David P. Quigley ([EMAIL PROTECTED]): > > > static int task_alloc_security(struct task_struct *task) > > > @@ -2423,14 +2

Re: [PATCH RFC 1/2] capabilities: fix compilation with strict type checking (v2)

Quoting Chris Wright ([EMAIL PROTECTED]): > * Casey Schaufler ([EMAIL PROTECTED]) wrote: > > --- Chris Wright <[EMAIL PROTECTED]> wrote: > > > > > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > > > > Here is a new version of the 64-bit capability patches

Re: [PATCH 1/2] VFS/Security: Rework inode_getsecurity and callers to return resulting buffer

Quoting David P. Quigley ([EMAIL PROTECTED]): > This patch modifies the interface to inode_getsecurity to have the > function return a buffer containing the security blob and its length via > parameters instead of relying on the calling function to give it an > appropriately sized buffer. Sec

Re: [PATCH 2/2] VFS: Reorder vfs_getxattr to avoid unnecessary calls to the LSM

Quoting James Morris ([EMAIL PROTECTED]): > On Mon, 22 Oct 2007, David P. Quigley wrote: > > > Originally vfs_getxattr would pull the security xattr variable using > > the inode getxattr handle and then proceed to clobber it with a subsequent > > call > > to the LSM. This patch reorders the two o

[PATCH RFC 2/2] capabilities: implement 64-bit capabilities (v2)

ts pass. thanks, -serge PS - both these patches make checkpatch complain about new typedefs. I don't mind ripping them out, but am sticking with existing style in that code. Changing that probably takes a separate patch. >From 5689df8467768f6d1d19ba5daf80a435f4dcdd85 Mon Sep 17 00:00:00 2

[PATCH RFC 1/2] capabilities: fix compilation with strict type checking (v2)

-serge >From 5fa6261565970df73dc7a297861b01f696522ba4 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 15:39:10 -0400 Subject: [PATCH 3/4] capabilities: fix compilation with strict type checking (v2) Since at least 1998 the STRICT_CAP_T_TYPECHECKS o

Re: LSM and Containers

Quoting Peter Dolding ([EMAIL PROTECTED]): > On 10/25/07, Crispin Cowan <[EMAIL PROTECTED]> wrote: > > Peter Dolding wrote: > > > The other thing you have not though of and is critical. If LSM is the > > > same LSM across all containers. What happens if that is breached and > > > tripped to disab

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

Quoting David P. Quigley ([EMAIL PROTECTED]): > On Wed, 2007-10-24 at 21:04 +0200, Jan Engelhardt wrote: > > On Oct 24 2007 19:59, Simon Arlott wrote: > > >On 24/10/07 19:51, Jan Engelhardt wrote: > > >> On Oct 24 2007 19:11, Simon Arlott wrote: > > >>> > > >>>* (I've got a list of access rules whi

Re: LSM and Containers (was: LSM conversion to static interface)

Quoting Crispin Cowan ([EMAIL PROTECTED]): > Peter, I may be mistaken, but I think you are talking about an entirely > different issue than the LSM static interface issue, so I've changed the > subject. > > Peter Dolding wrote: > > You are all focusing on vendors. I am thinking server farm or peo

[PATCH RFC] capabilities: remove STRICT_CAP_T_TYPECHECKS

Quoting Serge E. Hallyn ([EMAIL PROTECTED]): > From cd7c384f76d2c0f6b12a1c0936d54ae9c5e7cb4c Mon Sep 17 00:00:00 2001 > From: Serge E. Hallyn <[EMAIL PROTECTED]> > Date: Fri, 19 Oct 2007 15:39:10 -0400 > Subject: [PATCH RFC] capabilities: fix compilation with strict ty

[PATCH RFC] capabilities: fix compilation with strict type checking

>From cd7c384f76d2c0f6b12a1c0936d54ae9c5e7cb4c Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Fri, 19 Oct 2007 15:39:10 -0400 Subject: [PATCH RFC] capabilities: fix compilation with strict type checking (v2) Since at least 1998 the code under STRICT_CAP_T_T

Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > > Quoting Chris Wright ([EMAIL PROTECTED]): > >> * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > >>> I guess now that I've writte

Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

Quoting Chris Wright ([EMAIL PROTECTED]): > * Serge E. Hallyn ([EMAIL PROTECTED]) wrote: > > I guess now that I've written this out, it seems pretty clear > > that capget64() and capget64() are the way to go. Any objections? > > How is capget64() different from capget()

Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

Quoting Andrew Morton ([EMAIL PROTECTED]): > On Tue, 16 Oct 2007 16:41:59 -0500 > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote: > > > To properly test this the libcap code will need to be updated first, > > which I'm looking at now... > > This see

Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

Quoting Stephen Smalley ([EMAIL PROTECTED]): > On Mon, 2007-10-15 at 21:31 -0500, Serge E. Hallyn wrote: > > >From 7dd503c612afcb86b3165602ab264e2e9493b4bf Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <[EMAIL PROTECTED]> > > Date: Mon, 15 Oct 2007 20:57:52 -0400

Re: [PATCH] /proc Security Hooks

Quoting Max Kellermann ([EMAIL PROTECTED]): > Add two LSM hooks for limiting access to the proc file system. > > security_proc_task() defines the visibility of tasks in /proc. > > security_proc_generic() lets the LSM define who will see "generic" > proc entries (see fs/proc/generic.c). > > This

Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

Quoting Stephen Smalley ([EMAIL PROTECTED]): > On Mon, 2007-10-15 at 21:31 -0500, Serge E. Hallyn wrote: > > >From 7dd503c612afcb86b3165602ab264e2e9493b4bf Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <[EMAIL PROTECTED]> > > Date: Mon, 15 Oct 2007 20:57:52 -0400

[RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

>From 7dd503c612afcb86b3165602ab264e2e9493b4bf Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 20:57:52 -0400 Subject: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities We are out of capabilities in the 32-bit capability fields, an

[PATCH 1/2 -mm] capabilities: clean up file capability reading

001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Mon, 15 Oct 2007 17:33:24 -0400 Subject: [PATCH 1/2] capabilities: clean up file capability reading Simplify the vfs_cap_data structure. Also fix get_file_caps which was declaring __le32 v1caps[XATTR_CAPS_SZ] on the stack, but XATTR_CAPS_SZ is al

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

Quoting Eric W. Biederman ([EMAIL PROTECTED]): > Casey Schaufler <[EMAIL PROTECTED]> writes: > > > --- "Eric W. Biederman" <[EMAIL PROTECTED]> wrote: > > > > > >> Likely. Until we have a generalized LSM interface with 1000 config > >> options like netfilter I don't expect we will have grounds to

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

Quoting Eric W. Biederman ([EMAIL PROTECTED]): > "Serge E. Hallyn" <[EMAIL PROTECTED]> writes: > Also I'm thinking towards what do we have to do isolate the security > module stuff in the context of a namespace. So that a person in > a container can setup their ow

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

Quoting Casey Schaufler ([EMAIL PROTECTED]): > > --- Kyle Moffett <[EMAIL PROTECTED]> wrote: > > > On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote: > > > Kyle Moffett <[EMAIL PROTECTED]> writes: > > > > > >> On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote: > > >>> SElinux is not all e

Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

Quoting Eric W. Biederman ([EMAIL PROTECTED]): > Kyle Moffett <[EMAIL PROTECTED]> writes: > > > On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote: > >> What we want from the LSM is the ability to say -EPERM when we can clearly > >> articulate that we want to disallow something. > > > > This so

[PATCH 2/2 -mm] capabilities: introduce per-process capability bounding set (v4)

>From d93ecb90d82f9e2b7f48c74f5e6ed97cac3683c7 Mon Sep 17 00:00:00 2001 From: Serge Hallyn <[EMAIL PROTECTED]> Date: Fri, 28 Sep 2007 10:33:56 -0500 Subject: [PATCH 2/2 -mm] capabilities: introduce per-process capability bounding set (v4) The capability bounding set is a set beyond which capabili

[PATCH 1/2 -mm] capabilities: define CONFIG_COMMONCAP

>From 54c70ca7671750fe8986451fae91d42107d0ca90 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Fri, 28 Sep 2007 10:33:33 -0500 Subject: [PATCH 1/2 -mm] capabilities: define CONFIG_COMMONCAP currently the compilation of commoncap.c is determined through Makefile l

Re: [PATCH 0/3] capabilities: per-process capbset

Quoting James Morris ([EMAIL PROTECTED]): > On Mon, 1 Oct 2007, Serge E. Hallyn wrote: > > > Here is a new per-process capability bounding set patchset > > which I expect to send to linux-kernel soon. It makes > > the capbset per-process. A process can only permanently &

Re: [PATCH 0/3] capabilities: per-process capbset

Quoting Serge E. Hallyn ([EMAIL PROTECTED]): > Here is a new per-process capability bounding set patchset > which I expect to send to linux-kernel soon. It makes > the capbset per-process. A process can only permanently > remove bits from it's bounding set, not add them.

[PATCH 3/3] capabilities: reduce current's caps when reducing bset

>From 2a0af2a5364ab568fa603cc9fdaeeef67d82dc56 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Fri, 28 Sep 2007 14:07:03 -0500 Subject: [PATCH 3/3] capabilities: reduce current's caps when reducing bset When a task sets it's capability bounding set, en

[PATCH 1/3] capabilities: define CONFIG_COMMONCAP

>From 3bba066917dd4a8a7c368ee1d2e163c3d619bb92 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Fri, 28 Sep 2007 10:33:33 -0500 Subject: [PATCH 1/3] capabilities: define CONFIG_COMMONCAP currently the compilation of commoncap.c is determined through Makefile l

[PATCH 2/3] capabilities: introduce per-process capability bounding set (v3)

>From eb29cb5c636b310efb995a1787ac0b8f0e9a13a1 Mon Sep 17 00:00:00 2001 From: Serge Hallyn <[EMAIL PROTECTED]> Date: Fri, 28 Sep 2007 10:33:56 -0500 Subject: [PATCH 2/3] capabilities: introduce per-process capability bounding set (v3) The capability bounding set is a set beyond which capabilities

[PATCH 0/3] capabilities: per-process capbset

Here is a new per-process capability bounding set patchset which I expect to send to linux-kernel soon. It makes the capbset per-process. A process can only permanently remove bits from it's bounding set, not add them. To remove bits, CAP_SYS_ADMIN is currently needed. Maybe that's not the best

Re: [PATCH] capabilities: introduce per-process capability bounding set (v2)

Quoting Serge E. Hallyn ([EMAIL PROTECTED]): > Two comments on this patch. > > One issue that is buggine me is when capabilities are not in the > kernel, we get no warning of that. You can do PR_SET_CAPBSET, > and PR_GET_CAPBSET shows the right results after. But you are in >

[PATCH] capabilities: introduce per-process capability bounding set (v2)

Two comments on this patch. One issue that is buggine me is when capabilities are not in the kernel, we get no warning of that. You can do PR_SET_CAPBSET, and PR_GET_CAPBSET shows the right results after. But you are in no way constrained by that bset. It's not clear how to fix that, because of

Re: [PATCH 2/3] CRED: Split the task security data and move part of it into struct cred

Quoting David Howells ([EMAIL PROTECTED]): > Move into the cred struct the part of the task security data that defines how > a > task acts upon an object. The part that defines how something acts upon a > task > remains attached to the task. > > For SELinux this requires some of task_security_s

[PATCH RFC] capabilities: properly use task_capability_lock

What is the justification for needing to grab task_capability_lock when applying bprm caps to current during exec->compute_creds? If I'm not mistaken, we do in fact need the below patch to prevent weirdnesses between fork and capset/capget. It also addresses a FIXME in fs/open.c where sys_access

Re: [2.6 patch] remove securebits

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > > To summarize more clearly, I think that so long as we support > > process trees with a sort of !SECURE_NOROOT support, that > > support sho

Re: [2.6 patch] remove securebits

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Attached is what I consider only an RFC patch. > > I've not really thought through (to my satisfaction) the re-purposing of > current->keep_capabilities in the non-filesystem-supporting-capability > c

Re: [2.6 patch] remove securebits

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Attached is what I consider only an RFC patch. > > I've not really thought through (to my satisfaction) the re-purposing of > current->keep_capabilities in the non-filesystem-supporting-capability > c

Re: [2.6 patch] remove securebits

Quoting Adrian Bunk ([EMAIL PROTECTED]): > On Mon, Aug 27, 2007 at 10:09:42AM -0500, Serge E. Hallyn wrote: > > Quoting Adrian Bunk ([EMAIL PROTECTED]): > > > On Fri, Aug 24, 2007 at 08:50:10PM -0700, Andrew Morgan wrote: > > > > > > > > FWIW, in the mm

Re: [2.6 patch] remove securebits

Quoting Adrian Bunk ([EMAIL PROTECTED]): > On Fri, Aug 24, 2007 at 08:50:10PM -0700, Andrew Morgan wrote: > > > > FWIW, in the mm kernel, I've actually already removed them when one > > configures without capabilities. > > > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-

Re: [2.6 patch] remove securebits

Quoting Adrian Bunk ([EMAIL PROTECTED]): > It seems that since it was added in kernel 2.2.0 (sic) securebits > was never used. > > This patch therefore removes it. Actually IIUC Andrew Morgan had plans of making securebits per-process, which would make them far more usable. Now maybe he'd just

Re: [PATCH] V3 file capabilities: alter behavior of cap_setpcap

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Andrew Morgan wrote: > > Andrew Morgan wrote: > >> Serge E. Hallyn wrote: > >>> (Sorry, I should have ran shorter tests to get these results a little > >&

Re: [PATCH] V2 file capabilities: alter behavior of cap_setpcap

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Let's try that again with fewer exotic characters. (Still not exactly > sure how I was attacked by i18n.) > > Cheers > > Andrew > > Andrew Morgan wrote:

Re: [PATCH 1/1] file capabilities: don't ensure we break with 64-bit caps

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > >> Then, after all, perhaps it is time to just introduce file capabilities > >> with a simultaneous kernel change to 64-bits now, while all thi

Re: [PATCH 1/1] file capabilities: don't ensure we break with 64-bit caps

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > >> The code you are contemplating now which reserves a magic number for > >> 64-bits and we can't use that magic number; we've create

Re: file capabilities: clear fcaps on inode change (v3)

Quoting James Morris ([EMAIL PROTECTED]): > On Tue, 7 Aug 2007, Serge E. Hallyn wrote: > > > Yeah, I did that in v1, but didn't want to add two new security_ hooks. > > But I'll send a v4 doing that. > > Yep, add what's actually needed. > > Continua

Re: file capabilities: clear fcaps on inode change (v3)

Quoting Trond Myklebust ([EMAIL PROTECTED]): > On Tue, 2007-08-07 at 17:17 -0500, Serge E. Hallyn wrote: > > > diff --git a/fs/splice.c b/fs/splice.c > > index e36c003..2df95f3 100644 > > --- a/fs/splice.c > > +++ b/fs/splice.c > > @@ -827,6 +827,12

file capabilities: clear fcaps on inode change (v3)

>From 905b8352d5b2373666b4e18d4d9ffa41049e0a0a Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Tue, 7 Aug 2007 11:40:41 -0400 Subject: file capabilities: clear fcaps on inode change (v3) When a file with posix capabilities is overwritten, the file capabilitie

Re: [PATCH 1/1] file capabilities: clear fcaps on inode change (v2)

Quoting James Morris ([EMAIL PROTECTED]): > On Tue, 7 Aug 2007, Serge E. Hallyn wrote: > > > Shall I resend without the LSM_NEED_LOCK, or do you still want a more > > fundamental change? > > > Removing the needlock is enough, the rest was just a query/suggestion. O

Re: [PATCH 1/1] file capabilities: clear fcaps on inode change (v2)

Quoting Stephen Smalley ([EMAIL PROTECTED]): > On Mon, 2007-08-06 at 13:52 -0500, Serge E. Hallyn wrote: > > >From 1376764cbb54243f088cf00c39000c4f4418f461 Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <[EMAIL PROTECTED]> > > Date: Mon, 6 Aug 2007 14:20:06 -0400

Re: [PATCH 1/1] file capabilities: clear fcaps on inode change (v2)

Quoting James Morris ([EMAIL PROTECTED]): > On Mon, 6 Aug 2007, Serge E. Hallyn wrote: > > > + err = security_inode_killpriv(out->f_path.dentry, LSM_NEED_LOCK); > > + if (err) > > + return err; > > + > > err = should_remove_suid(out-&g

Re: [PATCH 1/1] file capabilities: don't ensure we break with 64-bit caps

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > >> So far as I can see there are two types of issue: > >> > >> - a new capability comes along - it is needed to run an app >

Re: [PATCH 1/1] file capabilities: don't ensure we break with 64-bit caps

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > > Andrew, James, Stephen, Chris, > > > > The following is all-but-untested (just compiles with relevant config > > combinations). But

[PATCH 1/1] file capabilities: don't ensure we break with 64-bit caps

64-bit capabilities would be formed. Please let me know if you have an objection. thanks, -serge >From 64284b5cff82a713d31247f37c2e8b393faa30d3 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Mon, 6 Aug 2007 17:45:05 -0400 Subject: [PATCH 1/1] file capabiliti

[PATCH 1/1] file capabilities: clear fcaps on inode change (v2)

>From 1376764cbb54243f088cf00c39000c4f4418f461 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Mon, 6 Aug 2007 14:20:06 -0400 Subject: [PATCH 1/1] file capabilities: clear fcaps on inode change (v2) When a file with posix capabilities is overwritten, the file cap

Re: [PATCH RFC] file capabilities: alter behavior of cap_setpcap

Quoting Andrew Morgan ([EMAIL PROTECTED]): > Andrew Morgan wrote: > > Serge E. Hallyn wrote: > >>> 0. fix the implementation of cap_setpcap. It is supposed to mean 'this > >>> process can raise capabilities, outside its permitted set, in _its own_ >

Re: [PATCH RFC] file capabilities: clear fcaps on inode change

Quoting Andrew Morgan ([EMAIL PROTECTED]): > My current working preference is: 0, 3, 1, 2. I don't consider any of > them as urgent as getting the inode modification protection fixed. Oops. Right. I'm not sure I'll have a laptop with me tomorow, but I'll try to get a patch out no later than som

Re: [PATCH RFC] file capabilities: clear fcaps on inode change

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > > Meanwhile, any chance you would get some time to implement the cap_bset > > vs fcaps change you wanted? I'd have to look at my checklist to be

Re: [PATCH RFC] file capabilities: clear fcaps on inode change

Quoting Andrew Morgan ([EMAIL PROTECTED]): > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Serge E. Hallyn wrote: > >> Yes. I'd thought about adding a security_ops->inode_change() or > >> somesuch hook, but there were two reasons I didn't. Fir

Re: [RFC: 2.6 patch] make the *FS_SECURITY options no longer user visible

Quoting Adrian Bunk ([EMAIL PROTECTED]): > Please correct me if any of the following assumptions is wrong: > - SELinux is currently the only user of filesystem security labels > shipped with the Linux kernel > - if a user has SELinux enabled he wants his filesystems to support > security labels

Re: [PATCH RFC] file capabilities: clear fcaps on inode change

x27;t appear to be in the loop for this sort of > security sensitive event. Is there a reason for not making it so? > > Cheers > > Andrew > > Serge E. Hallyn wrote: > > When you > > > > setfcaps -c cap_net_admin=p -e /bin/ping > > cp /bin/sh

Re: [PATCH RFC] file capabilities: clear fcaps on inode change

Quoting Seth Arnold ([EMAIL PROTECTED]): > On Fri, Jul 27, 2007 at 12:31:11PM -0500, Serge E. Hallyn wrote: > > When you > > > > setfcaps -c cap_net_admin=p -e /bin/ping > > cp /bin/sh /bin/ping > > > > then /bin/ping should lose its file capabilit

[PATCH RFC] file capabilities: clear fcaps on inode change

00:00:00 2001 From: Serge E. Hallyn <[EMAIL PROTECTED]> Date: Fri, 27 Jul 2007 10:56:10 -0400 Subject: [PATCH RFC] file capabilities: clear fcaps on inode change When a file with posix capabilities is overwritten, the file capabilities, like a setuid bit, should be removed. Signed-off-by

Re: [PATCH try #3] security: Convert LSM into a static interface

Quoting Arjan van de Ven ([EMAIL PROTECTED]): > > > > > :) > > > > Actually, given that when lsm was being introduced, lsm seemed to > > improve performance overall, have you taken any measurements to show > > that this is actually the case? Of course it makes sense that it would, > > but witjo

Re: [PATCH try #3] security: Convert LSM into a static interface

Quoting Arjan van de Ven ([EMAIL PROTECTED]): > > > Right, the ability to boot with security.capability=disabpled (or > > whatever) and then load a custom module without having to use a whole > > new kernel is something I'm sure end-users want. > > > > Especially since compiling a kernel which wo

<    1   2   3   >