Re: [PATCH 09/19] fs: Refuse uid/gid changes which don't map into s_user_ns

On Wed, Dec 02, 2015 at 09:40:09AM -0600, Seth Forshee wrote: > Add checks to inode_change_ok to verify that uid and gid changes > will map into the superblock's user namespace. If they do not > fail with -EOVERFLOW. This cannot be overriden with ATTR_FORCE. > > Signed-off-by: Seth Forshee

Re: [PATCH 01/19] block_dev: Support checking inode permissions in lookup_bdev()

On Wed, Dec 02, 2015 at 09:40:01AM -0600, Seth Forshee wrote: > When looking up a block device by path no permission check is > done to verify that the user has access to the block device inode > at the specified path. In some cases it may be necessary to > check permissions towards the inode,

Re: [PATCH 07/19] fs: Check for invalid i_uid in may_follow_link()

On Wed, Dec 02, 2015 at 09:40:07AM -0600, Seth Forshee wrote: > Filesystem uids which don't map into a user namespace may result > in inode->i_uid being INVALID_UID. A symlink and its parent > could have different owners in the filesystem can both get > mapped to INVALID_UID, which may result in

Re: [PATCH 08/19] cred: Reject inodes with invalid ids in set_create_file_as()

On Wed, Dec 02, 2015 at 09:40:08AM -0600, Seth Forshee wrote: > Using INVALID_[UG]ID for the LSM file creation context doesn't > make sense, so return an error if the inode passed to > set_create_file_as() has an invalid id. > > Signed-off-by: Seth Forshee Acked-by:

Re: [PATCH 05/19] userns: Replace in_userns with current_in_userns

On Wed, Dec 02, 2015 at 09:40:05AM -0600, Seth Forshee wrote: > All current callers of in_userns pass current_user_ns as the > first argument. Simplify by replacing in_userns with > current_in_userns which checks whether current_user_ns is in the > namespace supplied as an argument. > >

Re: [PATCH 03/19] fs: Treat foreign mounts as nosuid

On Wed, Dec 02, 2015 at 09:40:03AM -0600, Seth Forshee wrote: > From: Andy Lutomirski > > If a process gets access to a mount from a different user > namespace, that process should not be able to take advantage of > setuid files or selinux entrypoints from that filesystem.

Re: [PATCH 02/19] block_dev: Check permissions towards block device inode when mounting

On Wed, Dec 02, 2015 at 09:40:02AM -0600, Seth Forshee wrote: > Unprivileged users should not be able to mount block devices when > they lack sufficient privileges towards the block device inode. > Update blkdev_get_by_path() to validate that the user has the > required access to the inode at the

Re: [PATCH 09/19] fs: Refuse uid/gid changes which don't map into s_user_ns

Quoting Seth Forshee (seth.fors...@canonical.com): > On Fri, Dec 04, 2015 at 11:27:38AM -0600, Serge E. Hallyn wrote: > > On Wed, Dec 02, 2015 at 09:40:09AM -0600, Seth Forshee wrote: > > > Add checks to inode_change_ok to verify that uid and gid changes > > > will map

Re: [PATCH 17/19] fuse: Support fuse filesystems outside of init_user_ns

Quoting Seth Forshee (seth.fors...@canonical.com): > Update fuse to translate uids and gids to/from the user namspace > of the process servicing requests on /dev/fuse. Any ids which do > not map into the namespace will result in errors. inodes will > also be marked bad when unmappable ids are

Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns

MAP requires root has always been a bit silly, and this would > be a great opportunity to simplify things a bit.) > > - Ted > > > On Fri, Dec 04, 2015 at 01:11:43PM -0600, Serge E. Hallyn wro

Re: [PATCH 18/19] fuse: Restrict allow_other to the superblock's namespace or a descendant

Quoting Seth Forshee (seth.fors...@canonical.com): > Unprivileged users are normally restricted from mounting with the > allow_other option by system policy, but this could be bypassed > for a mount done with user namespace root permissions. In such > cases allow_other should not allow users

Re: [PATCH RFC] Introduce new security.nscapability xattr

Quoting Eric W. Biederman (ebied...@xmission.com): > "Serge E. Hallyn" <serge.hal...@ubuntu.com> writes: > > > A common way for daemons to run with minimal privilege is to start as root, > > perhaps setuid-root, choose a desired capability set, set PR_SET_KEEPCAP

Re: [PATCH 15/19] capabilities: Allow privileged user in s_user_ns to set file caps

On Fri, Dec 04, 2015 at 02:36:27PM -0600, Seth Forshee wrote: > On Fri, Dec 04, 2015 at 01:42:06PM -0600, Serge E. Hallyn wrote: > > Quoting Seth Forshee (seth.fors...@canonical.com): > > > A privileged user in a super block's s_user_ns is privileged > > > towards that

Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns

On Fri, Dec 04, 2015 at 06:11:52PM -0500, Theodore Ts'o wrote: > On Fri, Dec 04, 2015 at 02:45:32PM -0600, Seth Forshee wrote: > > On Fri, Dec 04, 2015 at 02:07:36PM -0600, Serge E. Hallyn wrote: > > > Heh, I was looking over > > > http://www.gossamer-threads.co

Re: [PATCH 10/19] fs: Update posix_acl support to handle user namespace mounts

Quoting Seth Forshee (seth.fors...@canonical.com): > ids in on-disk ACLs should be converted to s_user_ns instead of > init_user_ns as is done now. This introduces the possibility for > id mappings to fail, and when this happens syscalls will return > EOVERFLOW. > > Signed-off-by: Seth Forshee

Re: [PATCH 11/19] fs: Ensure the mounter of a filesystem is privileged towards its inodes

Quoting Seth Forshee (seth.fors...@canonical.com): > The mounter of a filesystem should be privileged towards the > inodes of that filesystem. Extend the checks in > inode_owner_or_capable() and capable_wrt_inode_uidgid() to > permit access by users priviliged in the user namespace of the >

Re: [PATCH 12/19] fs: Don't remove suid for CAP_FSETID in s_user_ns

Quoting Seth Forshee (seth.fors...@canonical.com): > Expand the check in should_remove_suid() to keep privileges for > CAP_FSETID in s_user_ns rather than init_user_ns. > > Signed-off-by: Seth Forshee Acked-by: Serge Hallyn > --- >

Re: [PATCH 13/19] fs: Allow superblock owner to access do_remount_sb()

Quoting Seth Forshee (seth.fors...@canonical.com): > Superblock level remounts are currently restricted to global > CAP_SYS_ADMIN, as is the path for changing the root mount to > read only on umount. Loosen both of these permission checks to > also allow CAP_SYS_ADMIN in any namespace which is

Re: [PATCH 14/19] fs: Permit FIBMAP for users with CAP_SYS_RAWIO in s_user_ns

Quoting Seth Forshee (seth.fors...@canonical.com): > Signed-off-by: Seth Forshee Acked-by: Serge Hallyn > --- > fs/ioctl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/ioctl.c b/fs/ioctl.c > index

[PATCH RFC] Introduce new security.nscapability xattr

A common way for daemons to run with minimal privilege is to start as root, perhaps setuid-root, choose a desired capability set, set PR_SET_KEEPCAPS, then change uid to non-root. A simpler way to achieve this is to set file capabilities on a not-setuid-root binary. However, when installing a

Re: [PATCH 1/2] security: remove unused cap_is_fs_cap function

On Tue, Nov 17, 2015 at 03:25:23PM +0800, Yaowei Bai wrote: > Since commit 3bc1fa8a ("LSM: remove BSD secure level security module") > there is no user of cap_is_fs_cap any more, so remove it. > > Signed-off-by: Yaowei Bai Acked-by: Serge Hallyn

Re: [PATCH 2/2] security/capability.h: cap_issubset/isclear can be boolean

On Tue, Nov 17, 2015 at 03:25:24PM +0800, Yaowei Bai wrote: > This patch makes cap_issubset/isclear return bool due to these > functions only using either one or zero as their return > value. > > No functional change. > > Signed-off-by: Yaowei Bai Acked-by:

Re: [PATCH 3/3] apparmor: use list_next_entry instead of list_entry_next

On Mon, Nov 16, 2015 at 09:46:33PM +0800, Geliang Tang wrote: > list_next_entry has been defined in list.h, so I replace list_entry_next > with it. > > Signed-off-by: Geliang Tang Seems reasonable. Acked-by: Serge Hallyn > --- >

Re: [PATCH v3] capabilities.7, prctl.2: Document ambient capabilities

On Tue, Nov 03, 2015 at 03:42:17PM -0800, Andy Lutomirski wrote: > Reviewed-by: Kees Cook > Signed-off-by: Andy Lutomirski Looks good, thanks. Acked-by: Serge Hallyn > --- > > Changes from v2: Add a note about arg3 == 0 in

Re: [PATCH] userns/capability: Add user namespace capability

On Sat, Oct 17, 2015 at 05:58:04PM +0200, Tobias Markus wrote: > Add capability CAP_SYS_USER_NS. > Tasks having CAP_SYS_USER_NS are allowed to create a new user namespace > when calling clone or unshare with CLONE_NEWUSER. > > Rationale: > > Linux 3.8 saw the introduction of unpriviledged user

Re: [PATCH] (linus git 02/19/08) Smack update for file capabilities

Quoting Casey Schaufler ([EMAIL PROTECTED]): From: Casey Schaufler [EMAIL PROTECTED] Update the Smack LSM to allow the registration of the capability module as a secondary LSM. Integrate the new hooks required for file based capabilities. Hi Casey, to help people keep their mailboxes

Re: Possible problem in linux file posix capabilities

Quoting Casey Schaufler ([EMAIL PROTECTED]): --- Serge E. Hallyn [EMAIL PROTECTED] wrote: Two quick fixes for you right now (apart from the one you've already got :) would be 1. give wireshark cap_kill, by doing something like capset cap_kill=ep /bin

Re: [PATCH] exporting capability code/name pairs (try #5.1)

Quoting Greg KH ([EMAIL PROTECTED]): On Mon, Feb 18, 2008 at 04:12:53PM +0900, Kohei KaiGai wrote: Greg KH wrote: On Fri, Feb 15, 2008 at 12:38:02PM -0600, Serge E. Hallyn wrote: This patch enables to export code/name of capabilities supported on the running kernel

Re: Possible problem in linux file posix capabilities

Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): Hello, I'm not sure it is you the right person to contact. I tried to run latest normal user wireshark with SUID dumpcap without success under linux-2.6.24.2. After looking around it seems to be related to the file in the kernel

Re: Possible problem in linux file posix capabilities

Quoting Andrew G. Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: | Andrew, this pretty much was bound to happen... we need to figure out | what our approach here should be. My preference is still to allow | signals when p-uid==current-uid

Re: [PATCH] exporting capability code/name pairs (try #5.1)

Quoting Kohei KaiGai ([EMAIL PROTECTED]): Li Zefan wrote: - snip - +error1: + kobject_put(capability_kobj); +error0: + printk(KERN_ERR Unable to export capabilities\n); + + return 0; Should return -EFXXX .. Oops, I fixed it as follows. Thanks for your pointed out.

Re: [PATCH] exporting capability code/name pairs (try #4)

that, this tested fine for me. thanks, -serge 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] capabilities: define CONFIG_COMMONCAP currently the compilation of commoncap.c

Re: [PATCH 1/3] exporting capability code/name pairs (try #3)

Quoting Kohei KaiGai ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Kohei KaiGai ([EMAIL PROTECTED]): All that being said, the friendliness factor of this is somewhat undeniable, and so I can see why folk might want it in the kernel anyway. If so, would it possible to move this code

Re: [PATCH] per-process securebits

Quoting Andrew G. Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the patch adding per-process secure-bits. This patch was generated over 2.6.24-rc8-mm1 + my privilege escalation bugfix. Cheers Andrew Ref: 6a63d67f37e50dd2031b3a050ebac1e64eae916e

Re: [PATCH] per-process securebits

Quoting Andrew G. Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew, Just to be clear, I'm not sure I agree that I'm hiding anything! I've tried very hard to limit this functionality to only being enabled if the still experimental LSM

Re: [RFC PATCH] per-process securebits

Quoting Andrew G. Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: | Quoting Andrew G. Morgan ([EMAIL PROTECTED]): | Here is my latest per-process secure-bits patch. | | Hey Andrew, | | looks really good. Two comments inline. Thanks

[PATCH 4/4] user namespaces: handle user namespaces in file sigio

From 1fa55246fc67f44e9c77829cb88a0df59e559bb5 Mon Sep 17 00:00:00 2001 From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tue, 4 Dec 2007 15:37:48 -0800 Subject: [PATCH 4/4] user namespaces: handle user namespaces in file sigio Store user namespaces in fown_struct. _f_modown() sets the user_ns to

[PATCH 3/4] user namespaces: enforce CAP_NS_OVERRIDE for cross-namespace kill

From 491e532e336a98b1b9d1ecda6f4160d0c0adde89 Mon Sep 17 00:00:00 2001 From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thu, 29 Nov 2007 08:18:16 -0800 Subject: [PATCH 3/4] user namespaces: enforce CAP_NS_OVERRIDE for cross-namespace kill Require CAP_NS_OVERRIDE to 'kill' across user namespaces.

[PATCH 2/4] containers: add CAP_NS_OVERRIDE capability

From ce1cf14000860f82ab59a5253bbe468da767e77f Mon Sep 17 00:00:00 2001 From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wed, 28 Nov 2007 18:52:28 -0800 Subject: [PATCH 2/4] containers: add CAP_NS_OVERRIDE capability containers: add CAP_NS_OVERRIDE capability Signed-off-by: [EMAIL PROTECTED]

Re: [RFC PATCH] per-process securebits

Quoting Andrew G. Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is my latest per-process secure-bits patch. Thanks Andrew, I'll check this out tonight or this weekend. -serge Cheers Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux)

Re: [LTP] file capabilities ltp test

Quoting Subrata Modak ([EMAIL PROTECTED]): Quoting Subrata Modak ([EMAIL PROTECTED]): Here is a patch to add some file capability tests to ltp. Thanks. I am running this and will get back to you soon. I am not able to execute this through:

Re: [LTP] file capabilities ltp test

Hi Subrata, here is yet another version. There must be a cleaner way to do this, but this appears to at least work so I'd like to let it sit for awhile and see how it goes. (The reason for splitting up the libcap and CONFIG_SECURITY_CAPABILITIES checks is that if libcap isn't there then the

file capabilities ltp test

Here is a patch to add some file capability tests to ltp. Andrew, the inh_capped test should detect the bug you just found and fixed. Note that it finds it when it tries to raise cap_sys_admin to pI while still having setpcap in pE, but that's of course expected given the bug. Subject, the

Re: [TOMOYO #6 retry 02/21] Add struct vfsmount to struct task_struct.

I must say I personally prefer the apparmor approach. But I'd recommend you get together and get this piece pushed on its own, whichever version you can agree on. Yes it needs a user, but at this point I would think both tomoyo and apparmor have had enough visibility that everyone knows the

Re: [RFC PATCH] Adding prctl override support for LSMs

Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Attached is a quick RFC patch for modifying the way the LSM's handle prctl() checks. Currently, the only thing LSMs can do with prctl() calls is add more restrictions to their use than the default

Re: TOMOYO Linux Security Goal

Quoting Tetsuo Handa ([EMAIL PROTECTED]): Hello. Serge E. Hallyn wrote: * namespace manipulation. (i.e. mount()/umount()/pivot_root()) do you track mounts namespace cloning? Yes. TOMOYO can recognize mount operation with the following flags. --bind --move

Re: TOMOYO Linux Security Goal

Quoting Tetsuo Handa ([EMAIL PROTECTED]): Hello. Serge E. Hallyn wrote: Does a process get different mount trees by just calling clone() or unshare()? My understanding is that clone() or unshare() disables propergation of mount tree changes when somebody calls mount() or umount

Re: TOMOYO Linux Security Goal

Quoting Tetsuo Handa ([EMAIL PROTECTED]): Hello. Thank you for feedback. Serge E. Hallyn wrote: TOMOYO Linux is a DIY tool for understanding and protecting your system. TOMOYO Linux policy definitions are absolutely readable to Linux users, and TOMOYO Linux supports unique

Re: POSIX file capabilities for directories

Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello, in updating the documentation http://www.friedhoff.org/posixfilecaps.html I discovered that it is possible

Re: [PATCH] Exporting capability code/name pairs

Quoting KaiGai Kohei ([EMAIL PROTECTED]): This patch enables to export the code/name pairs of capabilities under /capability of securityfs. In the current libcap, it obtains the list of capabilities from header file on the build environment statically. However, it is not enough portable

[PATCH 1/1] capabilities: oom_kill: don't set PF_SUPERPRIV for oom check

From ed2e7764917fd56d9743630bd7072f67ff30adc2 Mon Sep 17 00:00:00 2001 From: Serge Hallyn [EMAIL PROTECTED] Date: Wed, 26 Dec 2007 15:04:50 -0800 Subject: [PATCH 1/1] capabilities: oom_kill: don't set PF_SUPERPRIV for oom check With 64-bit capabilities came an inadvertent change such that the

Re: TOMOYO Linux Security Goal

Quoting Tetsuo Handa ([EMAIL PROTECTED]): This document is intended to specify the security goal that TOMOYO Linux is trying to achieve, so that users can evaluate whether TOMOYO Linux will meet their needs, and kernel developers can evaluate whether TOMOYO Linux deserved to be in-tree. 1.

Re: POSIX file capabilities for directories

Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello, in updating the documentation http://www.friedhoff.org/posixfilecaps.html I discovered that it is possible to give directories through setcap also the extended attribute capability and therefor grant them capabilities. Is this is intended

Re: empty capability sets and suid-0-bit binaries

Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello, in updating the documetation http://www.friedhoff.org/posixfilecaps.html I noticed a change in the behavior. There was the behavior, when the extended attribute capability was present but with empty sets, even a suid-0-bit binary was not

[PATCH 1/1] capabilities: oom_kill: don't set PF_SUPERPRIV for oom check

Hi Andrew Morgan, does this patch look reasonable to you? thanks, -serge From ed2e7764917fd56d9743630bd7072f67ff30adc2 Mon Sep 17 00:00:00 2001 From: [EMAIL PROTECTED] [EMAIL PROTECTED](none) Date: Wed, 26 Dec 2007 15:04:50 -0800 Subject: [PATCH 1/1] capabilities: oom_kill: don't set

Re: [PATCH 5/7] Security: Change current-fs[ug]id to current_fs[ug]id()

Quoting David Howells ([EMAIL PROTECTED]): Change current-fs[ug]id to current_fs[ug]id() so that fsgid and fsuid can be separated from the task_struct. Hi David, this one looks straightforward enough. Unfortunately I don't have patch 6. In either of my linux-security-module-receiving

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

Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [I've droped lkml] KaiGai Kohei wrote: But !cap_xxx is a bit misunderstandable for me. Someone may misunderstand this line means any capabilities except for cap_xxx. I like '!', but you're going

Re: [PATCH 1/2] namespaces: introduce sys_hijack (v10)

Quoting Casey Schaufler ([EMAIL PROTECTED]): --- Serge E. Hallyn [EMAIL PROTECTED] wrote: Quoting Stephen Smalley ([EMAIL PROTECTED]): On Tue, 2007-11-27 at 10:11 -0600, Serge E. Hallyn wrote: Quoting Crispin Cowan ([EMAIL PROTECTED]): Just the name sys_hijack makes me concerned

Re: [PATCH 2/2] hijack: update task_alloc_security

Quoting Crispin Cowan ([EMAIL PROTECTED]): Serge E. Hallyn wrote: Quoting Casey Schaufler ([EMAIL PROTECTED]): Could y'all bring me up to speed on what this is intended to accomplish so that I can understand the Smack implications? It's basically like ptracing a process

Re: [PATCH 1/2] namespaces: introduce sys_hijack (v10)

Quoting Stephen Smalley ([EMAIL PROTECTED]): On Tue, 2007-11-27 at 16:38 -0600, Serge E. Hallyn wrote: Quoting Stephen Smalley ([EMAIL PROTECTED]): On Tue, 2007-11-27 at 10:11 -0600, Serge E. Hallyn wrote: Quoting Crispin Cowan ([EMAIL PROTECTED]): Just the name sys_hijack makes me

Re: [PATCH] (2.4.26-rc3-mm2) -mm Update CAP_LAST_CAP to reflect CAP_MAC_ADMIN

Quoting Casey Schaufler ([EMAIL PROTECTED]): From: Casey Schaufler [EMAIL PROTECTED] Bump the value of CAP_LAST_CAP to reflect the current last cap value. It appears that the patch that introduced CAP_LAST_CAP and the patch that introduced CAP_MAC_ADMIN came in more or less at the same time.

Re: [PATCH 1/2] namespaces: introduce sys_hijack (v10)

Quoting Crispin Cowan ([EMAIL PROTECTED]): Just the name sys_hijack makes me concerned. This post describes a bunch of what, but doesn't tell us about why we would want this. What is it for? Please see my response to Casey's email. And I second Casey's concern about careful management of

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

rid of this legacy support. thanks, -serge Thanks Andrew Serge E. Hallyn wrote: This patch is needed to preserve legacy behavior when CONFIG_SECURITY_FILE_CAPABILITIES=y. Without this patch, xinit can't kill X, so manually starting X in runlevel 3 then exiting your window manager

Re: [PATCH 2/2] hijack: update task_alloc_security

[EMAIL PROTECTED] Para: Mark Nelson [EMAIL PROTECTED] C?pia: [EMAIL PROTECTED], linux-security-module@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED], Stephen Smalley [EMAIL PROTECTED], James Morris [EMAIL PROTECTED], Serge E. Hallyn [EMAIL PROTECTED] Assunto: Re: [PATCH 2/2] hijack

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

Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This looks good to me. [As you anticipated, there is a potential merge issue with Casey's recent addition of MAC capabilities - which will make CAP_MAC_ADMIN the highest allocated capability: ie.,

Re: [PATCH 1/2] namespaces: introduce sys_hijack (v10)

Quoting Stephen Smalley ([EMAIL PROTECTED]): On Tue, 2007-11-27 at 10:11 -0600, Serge E. Hallyn wrote: Quoting Crispin Cowan ([EMAIL PROTECTED]): Just the name sys_hijack makes me concerned. This post describes a bunch of what, but doesn't tell us about why we would want this. What

[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 beyond which

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

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: with 2.6.24-rc3 I have the same problem. Ok, so here is the flow. First

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 [...] /* Allow ioperm/iopl access */ @@ -314,6 +314,10 @@ typedef

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, and

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't

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

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. Hallyn wrote: From 9ba95f1dbf88a512ffd423f6ccd627dc0460b052 Mon Sep 17 00:00:00 2001 From: Serge E

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 when -r is

[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 logic. So

Re: [PATCH] 64 bit capabilities

? Thanks Andrew Serge E. Hallyn wrote: Other than the one comment below, Acked-by: Serge Hallyn [EMAIL PROTECTED] - -static inline int cap_from_disk(__le32 *caps, struct linux_binprm *bprm, - - int size) +static inline int cap_from_disk(struct

Re: [PATCH] 64 bit capabilities

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 capability reading It seems that this patch has made it into 2.6.24-rc1

Re: [PATCH] 64 bit capabilities

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 capability reading It seems that this patch has made it into 2.6.24-rc1, but it is not present in 2.6.23

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 Posix

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.2.6

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 Subject: [PATCH 1/1] file

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 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 the

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:

[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_bug.cgi?id=9247

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 +2397,22 @@ static const char *selinux_inode_xattr_getsuffix(void

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 PROTECTED]): static int

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 PROTECTED]): static int

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 operations

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.

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 I was supposed to send last week I think

[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 type checking (v2) Since

[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_TYPECHECKS option

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() that supports 2 different

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 written this out, it seems pretty clear that capget64

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 seems fairly significant. I asusme that this patch won't break

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 Subject: [RFC] [PATCH 2/2

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 patch

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 Subject: [RFC] [PATCH 2/2

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

(__le32). Signed-off-by: Serge E. Hallyn [EMAIL PROTECTED] --- include/linux/capability.h |6 ++ security/commoncap.c | 23 +++ 2 files changed, 17 insertions(+), 12 deletions(-) diff --git a/include/linux/capability.h b/include/linux/capability.h index 7a8d7ad

  1   2   >