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

2015-12-04 Thread Serge E. Hallyn
y: Seth Forshee <seth.fors...@canonical.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> ... although i could see root on the host being upset that it can't assign a uid not valid in the mounter's ns. But it does seem safer. > --- > fs/attr.c | 11 +++ > 1 file

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

2015-12-04 Thread Serge E. Hallyn
ion checks where appropriate. > > Signed-off-by: Seth Forshee <seth.fors...@canonical.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > drivers/md/bcache/super.c | 2 +- > drivers/md/dm-table.c | 2 +- > drivers/mtd/mtdsuper.c| 2 +- >

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

2015-12-04 Thread Serge E. Hallyn
equivalent helper for gids, which is > currently unused. > > Signed-off-by: Seth Forshee <seth.fors...@canonical.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > fs/namei.c | 2 +- > include/linux/uidgid.h | 10 ++ > 2 files changed,

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

2015-12-04 Thread Serge E. Hallyn
onical.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > kernel/cred.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/cred.c b/kernel/cred.c > index 71179a09c1d6..ff8606f77d90 100644 > --- a/kernel/cred.c > +++

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

2015-12-04 Thread Serge E. Hallyn
> > Signed-off-by: Seth Forshee <seth.fors...@canonical.com> > Acked-by: James Morris <james.l.mor...@oracle.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > fs/namespace.c | 2 +- > include/linux/user_namespace.h

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

2015-12-04 Thread Serge E. Hallyn
gned-off-by: Andy Lutomirski <l...@amacapital.net> > Signed-off-by: Seth Forshee <seth.fors...@canonical.com> > Acked-by: James Morris <james.l.mor...@oracle.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > fs/exec.c| 2 +- >

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

2015-12-04 Thread Serge E. Hallyn
to the inode at the specified path. The check > will be skipped for CAP_SYS_ADMIN, so privileged mounts will > continue working as before. > > Signed-off-by: Seth Forshee <seth.fors...@canonical.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > fs/bl

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

2015-12-04 Thread Serge E. Hallyn
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

2015-12-04 Thread Serge E. Hallyn
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

2015-12-04 Thread Serge E. Hallyn
AIO for FIBMAP is pretty silly, given > that FIEMAP does not require privileges --- and in fact the preferred > interface. Why not just simply drop the requirement for privileges > for FIBMAP? > > (Seth, Serge, this isn't a real objection to your patch; but the fact > that FIB

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

2015-12-04 Thread Serge E. Hallyn
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

2015-12-04 Thread Serge E. Hallyn
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

2015-12-04 Thread Serge E. Hallyn
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

2015-12-04 Thread Serge E. Hallyn
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

2015-12-04 Thread Serge E. Hallyn
f-by: Seth Forshee <seth.fors...@canonical.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > fs/posix_acl.c | 67 > ++--- > fs/xattr.c | 19 +--- > include/linux/posix_acl_xa

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

2015-12-04 Thread Serge E. Hallyn
er namespace of the > inode's superblock. > > Signed-off-by: Seth Forshee <seth.fors...@canonical.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > fs/inode.c | 3 +++ > kernel/capability.c | 13 + > 2 files changed, 12 insertions(+), 4 d

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

2015-12-04 Thread Serge E. Hallyn
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 <seth.fors...@canonical.com> Acked-by: Serge Hallyn <serge.hal...@canoni

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

2015-12-04 Thread Serge E. Hallyn
espace which is privileged > towards the userns which originally mounted the filesystem. > > Signed-off-by: Seth Forshee <seth.fors...@canonical.com> > Acked-by: "Eric W. Biederman" <ebied...@xmission.com> > --- Acked-by: Serge Hallyn <serge.hal...@canonical.c

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

2015-12-04 Thread Serge E. Hallyn
Quoting Seth Forshee (seth.fors...@canonical.com): > Signed-off-by: Seth Forshee <seth.fors...@canonical.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > fs/ioctl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/f

[PATCH RFC] Introduce new security.nscapability xattr

2015-11-30 Thread Serge E. Hallyn
want to allow -1 uids to work in all namespaces. There certainly would be uses for this, but I'm a bit unsettled about the implications of allowing a program privilege in a container where there is no uid with privilege. This needs more thought. Signed-off-by: Serge Hallyn <serge.hal...@ubuntu.

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

2015-11-17 Thread Serge E. Hallyn
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 <baiyao...@cmss.chinamobile.com> Acked

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

2015-11-17 Thread Serge E. Hallyn
.chinamobile.com> Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > include/linux/capability.h | 16 > 1 file changed, 8 insertions(+), 8 deletions(-) > > diff --git a/include/linux/capability.h b/include/linux/capability.h > index b032003..f31427

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

2015-11-17 Thread Serge E. Hallyn
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 <geliangt...@163.com> Seems reasonable. Acked-by: Serge Hallyn <serge.hal...@canonical.co

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

2015-11-04 Thread Serge E. Hallyn
On Tue, Nov 03, 2015 at 03:42:17PM -0800, Andy Lutomirski wrote: > Reviewed-by: Kees Cook <keesc...@chromium.org> > Signed-off-by: Andy Lutomirski <l...@kernel.org> Looks good, thanks. Acked-by: Serge Hallyn <serge.hal...@canonical.com> > --- > > Changes fr

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

2015-10-17 Thread Serge E. Hallyn
ions for user namespaces was to finally allow unprivileged users to safely do things like manipulate their mounts tree without the risk of privileged (setuid) programs being tricked. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the b

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

2008-02-20 Thread Serge E. Hallyn
. Acked-by: Serge Hallyn [EMAIL PROTECTED] thanks, -serge Signed-off-by: Casey Schaufler [EMAIL PROTECTED] --- security/smack/smack_lsm.c | 87 +-- 1 file changed, 74 insertions(+), 13 deletions(-) diff -uprN -X linux-2.6.25-g0219-precap/Documentation/dontdiff

Re: Possible problem in linux file posix capabilities

2008-02-18 Thread Serge E. Hallyn
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)

2008-02-18 Thread Serge E. Hallyn
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

2008-02-17 Thread Serge E. Hallyn
to work around it. I suppose in a security sense that's the superior way :) But it also seems likely to lead to most people choosing option 2 above and not bothering to fix the problem. thanks, -serge - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body

Re: Possible problem in linux file posix capabilities

2008-02-17 Thread Serge E. Hallyn
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)

2008-02-15 Thread Serge E. Hallyn
exports its name, the symbolic node exports its code. Please consider to put this patch on the queue of 2.6.25. Looks good, except don't you need to put the code in commoncap.c under a #ifdef SYSFS? thanks, -serge Thanks, === [EMAIL PROTECTED

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

2008-02-12 Thread Serge E. Hallyn
/ directories, and we can use them to lookup capability code or name non-sequentially. In the previous version, we had to scan whole of entries to lookup capability name by its code. (required by Andrew Morgan) - I added an assertion when mkcapname.sh works incorrectly. (required by Serge

Re: if (2.6.24.1 capset bind9) bug()

2008-02-11 Thread serge
Quoting Nick 'Zaf' Clifford ([EMAIL PROTECTED]): Please CC me on any/all replies After trying to upgrade to deal with the most recent security issue, I Judging by the 2.6.24.2 changelog I don't think the 2.6.24.1 kernel you grabbed has the fix you're looking for... have encountered what has

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

2008-02-05 Thread Serge E. Hallyn
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

2008-02-01 Thread serge
. -serge From feac61b47be8375e25b0f6ee876cf096c8b1b9cc Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn [EMAIL PROTECTED] Date: Fri, 1 Feb 2008 14:13:29 + Subject: [PATCH 1/1] per-process securebits: security_task_prctl takes a long Fix a mismatch between prototypes and callers for the updated

Re: [PATCH] per-process securebits

2008-01-31 Thread Serge E. Hallyn
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

2008-01-31 Thread Serge E. Hallyn
CONFIG_SECURITY_FILE_CAPABILITIES is yes. I've also arranged for all of the relevant support code to be inside an LSM. However, I'll do as you say - extend the comment and fix the thinko pointed out by Serge, and resubmit to more than the LSM list. Cool, I'd certainly say it's ready, and please feel free to add

Re: [RFC PATCH] per-process securebits

2008-01-30 Thread Serge E. Hallyn
= ~issecure_mask(SECURE_KEEP_CAPS); | would be much easier to read... I agree. Both that -EPERM is a better error for the locked case, and the subsequent if / else. So, I'll use that. thanks, -serge - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message

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

2008-01-28 Thread Serge E. Hallyn
it in f_modown(). jan 28: fix sigio_userns_check_ok nsproxy access. Signed-off-by: Serge Hallyn [EMAIL PROTECTED] --- fs/fcntl.c | 67 +++ include/linux/fs.h |2 +- 2 files changed, 62 insertions(+), 7 deletions(-) diff --git a/fs

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

2008-01-28 Thread Serge E. Hallyn
. If the signaling task is exiting, then current-nsproxy is NULL. Since we are only notifying a parent of our death, we permit the signal. If the target task is exiting, our signal doesn't matter anyway. Signed-off-by: Serge Hallyn [EMAIL PROTECTED] --- kernel/signal.c | 23

[PATCH 2/4] containers: add CAP_NS_OVERRIDE capability

2008-01-28 Thread Serge E. Hallyn
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

2008-01-27 Thread serge
Quoting Andrew G. Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is my latest per-process secure-bits patch. Hey Andrew, looks really good. Two comments inline. Cheers Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux)

Re: [RFC PATCH] per-process securebits

2008-01-25 Thread Serge E. Hallyn
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

2008-01-22 Thread Serge E. Hallyn
checkforlibcap.sh returns 'no', but I'm not sure of the best way to do that. thanks, -serge - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [LTP] file capabilities ltp test

2008-01-22 Thread Serge E. Hallyn
there then the tests can't be compiled, whereas if it's the kernel missing a feature then compilation can succeed, the tests simply shouldn't run.) thanks, -serge diff -Nrup ltp-full-20071231/runltp ltp-full-20071231-filecaps/runltp --- ltp-full-20071231/runltp2008-01-01 06:44:38.0 -0500 +++ ltp-full

file capabilities ltp test

2008-01-21 Thread Serge E. Hallyn
, the myoutput file shows example output on a s390 with a good kernel. If libcap is not installed the filecaps tests won't compile, and capabilities or file capabilities are not compiled into the kernel, they will compile but not run. thanks, -serge diff -Nrup ltp-full-20071231/runltp ltp-full-20071231

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

2008-01-15 Thread Serge E. Hallyn
the intended users. It seems to me you're both being held up by this piece, and getting another full posting of either tomoyo or apparmor isn't going to help, so hopefully you can combine your efforts to get this solved. thanks, -serge Quoting Kentaro Takeda ([EMAIL PROTECTED]): This patch allows VFS

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

2008-01-09 Thread Serge E. Hallyn
; This is just a nitpick, and making sure I understand it correctly, but there's really no sense setting *rc_p here or in dummy_task_prctl(), right? Anyway, this looks fine to me. Signed-off-by: Serge Hallyn [EMAIL PROTECTED] thanks, -serge return 0; } diff --git a/kernel/sys.c b/kernel/sys.c

Re: TOMOYO Linux Security Goal

2007-12-31 Thread Serge E. Hallyn
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

2007-12-31 Thread Serge E. Hallyn
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

2007-12-27 Thread Serge E. Hallyn
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

2007-12-27 Thread Serge E. Hallyn
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

2007-12-27 Thread Serge E. Hallyn
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

2007-12-27 Thread Serge E. Hallyn
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

Re: TOMOYO Linux Security Goal

2007-12-26 Thread Serge E. Hallyn
and detected. This gives a precise (though perhaps wrong as I'm guessing :) picture of what TOMOYO can do and how it fits in with SMACK, apparmor, capabilities, and SELinux. thanks, -serge 3. Our Approach To meet the above goal, TOMOYO Linux attempts to make the system where everything

Re: POSIX file capabilities for directories

2007-12-26 Thread Serge E. Hallyn
or maybe not ? If it's intended, what is the benefit of this? I'm assuming it's unintended - or rather it's harmless but has no use - but will let Andrew respond since he may have some cool idea i haven't thought of. -serge - To unsubscribe from this list: send the line unsubscribe linux

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

2007-12-26 Thread Serge E. Hallyn
SECURE_NOROOT patch. My question is - when did it ever behave differently?? -serge - To unsubscribe from this list: send the line unsubscribe linux-security-module in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

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

2007-12-26 Thread Serge E. Hallyn
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: libcap-1.10-29.fscaps.28 is working, but libcap-2.02 gives an error on 2.6.24-rc5/6

2007-12-23 Thread serge
as no capabilities above 31 need to be set, just to avoid gratuitous headaches until 2.6.25. Andrew, what do you think? -serge Quoting Chris Friedhoff ([EMAIL PROTECTED]): Hello, I'm (still) updating my documentation on http://www.friedhoff.org/fscaps.html. I just learned, that KaiGai has taken his

Re: [PATCH] 64 bit capabilities

2007-12-12 Thread serge
Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E. Hallyn wrote: I defined CAP_NS_UNSHARE as bit 32 as an experiment, and had to do some finagling/combination of both of your trees to do so... Though that aside I'm pleased to say it all

Re: [PATCH] 64 bit capabilities

2007-12-12 Thread serge
Sigh, sorry, ignore me. Wrong kernel branch! icouldasworn... -serge Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge E

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

2007-12-07 Thread Serge E. Hallyn
mailboxes, so I don't think I accidentally deleted it :) Could you resend patch 6? thanks, -serge Signed-off-by: David Howells [EMAIL PROTECTED] --- arch/ia64/kernel/perfmon.c|4 ++-- arch/powerpc/platforms/cell/spufs/inode.c |4 ++-- drivers/isdn/capi/capifs.c

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

2007-12-04 Thread serge
Quoting KaiGai Kohei ([EMAIL PROTECTED]): Andrew Morgan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 KaiGai Kohei wrote: Serge, Please tell me the meanings of the following condition. diff --git a/security/commoncap.c b/security/commoncap.c index 3a95990..cb71bb0 100644

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

2007-12-03 Thread Serge E. Hallyn
(don't retain any other than these) b: drop exactly these (leave the others untouched) Simple is good, especially for something like this. It'd also be very nice to have a little wrapper test program like test_pamcap serge which simply reports the resulting inheritable and cap_bound sets

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

2007-11-30 Thread serge
Quoting KaiGai Kohei ([EMAIL PROTECTED]): Serge E. Hallyn wrote: The capability bounding set is a set beyond which capabilities cannot grow. Currently cap_bset is per-system. It can be manipulated through sysctl, but only init can add capabilities. Root can remove capabilities

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

2007-11-28 Thread Serge E. Hallyn
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

2007-11-28 Thread Serge E. Hallyn
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)

2007-11-28 Thread Serge E. Hallyn
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

2007-11-28 Thread Serge E. Hallyn
. Signed-off-by: Casey Schaufler [EMAIL PROTECTED] Signed-off-by: Serge Hallyn [EMAIL PROTECTED] --- include/linux/capability.h |8 1 file changed, 4 insertions(+), 4 deletions(-) diff -uprN -X linux-2.6.24-rc3-mm2-base/Documentation/dontdiff linux-2.6.24-rc3-mm2

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

2007-11-27 Thread Serge E. Hallyn
bells went off :) bc it's definately still worrisome. But at this point I believe it is the safest solution suggested so far. -serge Crispin Mark Nelson wrote: Here's the latest version of sys_hijack. Apologies for its lateness. Thanks! Mark. Subject: [PATCH 1/2] namespaces

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

2007-11-27 Thread Serge E. Hallyn
Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge, I still feel a bit uneasy about this. Looking ahead, with filesystem capabilities, one can simulate this same situation with a setuid 'non-root' program as follows: [EMAIL PROTECTED

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

2007-11-27 Thread Serge E. Hallyn
for it ;). Maybe hijack should go under a kernel config for security reasons. thanks, -serge cya, Rodrigo (BSDaemon). -- http://www.kernelhacking.com/rodrigo Kernel Hacking: If i really know, i can hack GPG KeyID: 1FCEDEA1 - Mensagem Original De: Joshua Brindle

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

2007-11-27 Thread Serge E. Hallyn
., #define CAP_LAST_CAP CAP_MAC_ADMIN ]. Signed-off-by: Andrew G. Morgan [EMAIL PROTECTED] Thanks, Andrew. Yes, the following patch will be needed on top of the previous one: -serge From 97ee046e8075a21b356fb93db0769d440437ef51 Mon Sep 17 00:00:00 2001 From: [EMAIL PROTECTED] [EMAIL

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

2007-11-27 Thread Serge E. Hallyn
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)

2007-11-26 Thread Serge E. Hallyn
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

2007-11-20 Thread Serge E. Hallyn
erroneously fail. So for now to use this cd ltp/testcases/kernel/security/filecaps make noltp_check thanks, -serge diff -Nrup ltp-full-20070430/runltp ltp-full-20070430-filecaps/runltp --- ltp-full-20070430/runltp2007-04-26 13:02:48.0 +0200 +++ ltp-full-20070430-filecaps

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

2007-11-20 Thread Serge E. Hallyn
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)

2007-11-20 Thread Serge E. Hallyn
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

2007-11-19 Thread Serge E. Hallyn
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

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

2007-11-19 Thread Serge E. Hallyn
be introduced along with new features. So legacy applications shouldn't misbehave due to ignorance or absence (after capget+capset) of them. Signed-off-by: Andrew G. Morgan [EMAIL PROTECTED] Acked-by: Serge Hallyn [EMAIL PROTECTED] thanks, -serge --- kernel/capability.c | 27

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

2007-11-16 Thread Serge E. Hallyn
Quoting Andrew Morgan ([EMAIL PROTECTED]): Serge, I've been thinking a lot about this one. As an alternative implementation, have you considered changing one bounding capability bit per system call? Something like this: prctl(PR_CAPBSET_READ, CAPVERSION, CAP_NET_RAW); returns

Re: [PATCH] 64 bit capabilities

2007-11-15 Thread Serge E. Hallyn
of setfcaps.c and getfcaps.c at all. I defined CAP_NS_UNSHARE as bit 32 as an experiment, and had to do some finagling/combination of both of your trees to do so... Though that aside I'm pleased to say it all worked perfectly. -serge - To unsubscribe from this list: send the line unsubscribe linux

[RFC PATCH 1/2] capabilities: define CONFIG_COMMONCAP

2007-11-15 Thread Serge E. Hallyn
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

2007-11-10 Thread Serge E. Hallyn
Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Serge, I guess I'm not sure what to do about this. In the caller there is an explicit check for negative rc in which case the modifed function is not called. Yeah, and it's only used to compare

Re: [PATCH] 64 bit capabilities

2007-11-09 Thread Serge E. Hallyn
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

2007-11-09 Thread Serge E. Hallyn
Quoting Andrew Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew, Serge The attached patch (e3d27bcb07485a6c8927c8e4f5483d35a99680c3) adds 64-bit capability support to the kernel. This version of the patch is designed to apply against the 2.6.23-mm1 tree

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

2007-11-05 Thread Serge E. Hallyn
recently to provide at least some way to avoid fault of SUID of course it could [...] So, yes, IBM (Serge) deserve full credit for starting over, and getting it merged... There are still pieces to line up. Note that Andrew Morgan is working on a patch to make the securebits per-process

Re: [RFC PATCH] 64-bit-capabilities

2007-11-05 Thread Serge E. Hallyn
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 (GNU

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

2007-11-01 Thread Serge E. Hallyn
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

2007-11-01 Thread Serge E. Hallyn
. The conversion is similar to the one performed by Al Viro for the security_getprocattr hook. Signed-off-by: David P. Quigley [EMAIL PROTECTED] Looks good. Looks like it's already hit -mm, but anyway Acked-by: Serge Hallyn [EMAIL PROTECTED] thanks, -serge --- fs/xattr.c | 30

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

2007-11-01 Thread Serge E. Hallyn
it returns EOPNOTSUPP. Signed-off-by: David P. Quigley [EMAIL PROTECTED] No change from last time, so again Acked-by: Serge Hallyn [EMAIL PROTECTED] thanks, -serge --- fs/xattr.c | 15 --- 1 files changed, 8 insertions(+), 7 deletions(-) diff --git a/fs/xattr.c b/fs/xattr.c

Re: [PATCH] 2.6.23: Filesystem capabilities 0.17

2007-10-31 Thread Serge E. Hallyn
? Should we consider switching it out for yours? If we stick with the current upstream file capabilities patch, should we port your SECURE_HACK to it? I actually thought that fixing bprm_secure_exec() sufficed? thanks, -serge +config LIBC_ENABLE_SECURE_HACK + bool Disable LD_PRELOAD

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

2007-10-31 Thread Serge E. Hallyn
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

2007-10-26 Thread Serge E. Hallyn
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

2007-10-26 Thread Serge E. Hallyn
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

2007-10-26 Thread Serge E. Hallyn
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

2007-10-25 Thread Serge E. Hallyn
operation. In the event that both are inaccessible it returns EOPNOTSUPP. Signed-off-by: David P. Quigley [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] (not that it matters much, esp with selinux being the only current user, but) Acked-by: Serge Hallyn [EMAIL PROTECTED] Makes

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

2007-10-25 Thread Serge E. Hallyn
seen as any major performance impact? thanks, -serge + if (error) + return error; + error = size; + return error; } static int selinux_inode_setsecurity(struct inode *inode, const char *name, - To unsubscribe from this list: send the line unsubscribe linux

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

2007-10-25 Thread Serge E. Hallyn
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

2007-10-19 Thread Serge E. Hallyn
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

  1   2   >