Re: [PATCH 2/2] hijack: update task_alloc_security
It will give another easy way to locate selinux security structures inside
the kernel, will not?
Again, if you have a kernel vulnerability and this feature, someone will
easily disable selinux for the process, or just change the security concerns
for it ;).
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 <[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: update task_alloc_security
Data: 27/11/07 02:38
>
> Mark Nelson wrote:
> > Subject: [PATCH 2/2] hijack: update task_alloc_security
> >
> > Update task_alloc_security() to take the hijacked task as a second
> > argument.
> >
> > For the selinux version, refuse permission if hijack_src!=current,
> > since we have no idea what the proper behavior is. Even if we
> > assume that the resulting child should be in the hijacked task's
> > domain, depending on the policy that may not be enough information
> > since init_t executing /bin/bash could result in a different domain
> > than login_t executing /bin/bash.
> >
> >
> This means its basically not possible to hijack tasks with SELinux
> right? It would be a shame if this weren't useful to people running
SELinux.
>
> It seems to me (I may be wrong, I'm sure someone will let me know if I
> am) that the right way to handle this with SELinux is to check to see if
> the current task (caller of sys_hijack) has permission to ptrace (or
> some other permission deemed suitable, perhaps a new one) and if so copy
> the security blob pointer from the hijacked task to the new one (we
> don't want tranquility problems).
>
> From your paragraph above it seems like you were thinking there should
> be a transition at hijack time but we don't automatically transition
> anywhere except exec.
>
> Anyway, I just don't think you should completely disable this for
> SELinux users.
>
> > Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]>
> > Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
> > ---
> > include/linux/security.h | 12 +---
> > kernel/fork.c|2 +-
> > security/dummy.c |3 ++-
> > security/security.c |4 ++--
> > security/selinux/hooks.c |6 +-
> > 5 files changed, 19 insertions(+), 8 deletions(-)
> >
> > Index: upstream/include/linux/security.h
> > ===
> > --- upstream.orig/include/linux/security.h
> > +++ upstream/include/linux/security.h
> > @@ -545,9 +545,13 @@ struct request_sock;
> > * Return 0 if permission is granted.
> > * @task_alloc_security:
> > * @p contains the task_struct for child process.
> > + * @task contains the task_struct for process to be hijacked
> > * Allocate and attach a security structure to the p->security
field. The
> > * security field is initialized to NULL when the task structure is
> > * allocated.
> > + * @task will usually be current. If it is not equal to current,
then
> > + * a sys_hijack system call is going on, and current is asking for
> a
> > + * child to be created in the context of the hijack src, @task.
> > * Return 0 if operation was successful.
> > * @task_free_security:
> > * @p contains the task_struct for process.
> > @@ -1301,7 +1305,8 @@ struct security_operations {
> > int (*dentry_open) (struct file *file);
> >
> > int (*task_create) (unsigned long clone_flags);
> > -int (*task_alloc_security) (struct task_struct * p);
> > +int (*task_alloc_security) (struct task_struct *p,
> > +struct task_struct *task);
> > void (*task_free_security) (struct task_struct * p);
> > int (*task_setuid) (uid_t id0, uid_t id1, uid_t id2, int flags);
> > int (*task_post_setuid) (uid_t old_ruid /* or fsuid */ ,
> > @@ -1549,7 +1554,7 @@ int security_file_send_sigiotask(struct
> > int security_file_receive(struct file *file);
> > int security_dentry_open(struct file *file);
> > int security_task_create(unsigned long clone_flags);
> > -int security_task_alloc(struct task_struct *p);
> > +int security_task_alloc(struct task_struct *p, struct task_struct
*task);
> > void security_task_free(struct task_struct *p);
> > int security_task_setuid(uid_t id0, uid_t id1, uid_t id2, int
flags);
> > int security_task_post_setuid(uid_t old_ruid, uid_t old_euid,
> > @@ -2021,7 +2026,8 @@ static inline int security_task_create (
> > return 0;
> > }
> >
> > -static inline int security_task_alloc (struct task_struct *p)
> > +static inline int security_task_alloc(struct task_struct *p,
> > +
Path of task via LSM
Is there a way to retrieve the full path of the currently running task via a task_struct or similar structure from the view of the LSM? Currently, the work I am doing with LSM design requires hooking into bprm_alloc_security in order to read the linux_binprm structure which contains the path of the application as it was run. Is there a similar way to access the full path dynamically say if I'm checking a socket based LSM hook which does not receive the linux_binprm structure I have been unsuccessful in using dentry and vfsmnt from the current task_struct via the d_path() lookup function. - 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: [PATCH 2/2] hijack: update task_alloc_security
On Tue, 2007-11-27 at 00:52 -0500, Joshua Brindle wrote:
> Mark Nelson wrote:
> > Subject: [PATCH 2/2] hijack: update task_alloc_security
> >
> > Update task_alloc_security() to take the hijacked task as a second
> > argument.
> >
> > For the selinux version, refuse permission if hijack_src!=current,
> > since we have no idea what the proper behavior is. Even if we
> > assume that the resulting child should be in the hijacked task's
> > domain, depending on the policy that may not be enough information
> > since init_t executing /bin/bash could result in a different domain
> > than login_t executing /bin/bash.
> >
> >
> This means its basically not possible to hijack tasks with SELinux
> right? It would be a shame if this weren't useful to people running SELinux.
I agree with this part - we don't want people to have to choose between
using containers and using selinux, so if hijack is going to be a
requirement for effective use of containers, then we need to make them
work together.
> It seems to me (I may be wrong, I'm sure someone will let me know if I
> am) that the right way to handle this with SELinux is to check to see if
> the current task (caller of sys_hijack) has permission to ptrace (or
I think this may already happen in the first patch, by virtue of calling
the existing ptrace checks including the security hook. Right?
> some other permission deemed suitable, perhaps a new one) and if so copy
> the security blob pointer from the hijacked task to the new one (we
> don't want tranquility problems).
Just to clarify, we wouldn't be copying the pointer; here we are
allocating and populating a new task's security structure. We can
either continue to inherit the SIDs from current in all cases, or we
could set tsec1 = hijack_src->security; in selinux_task_alloc_security()
if we wanted to inherit from the hijacked task instead. The latter
would be similar to what you do in copy_hijackable_taskinfo() for uids
and capabilities IIUC. However, which behavior is right needs more
discussion I think, as the new task is a mixture of the caller's state
and the hijacked task's state. Which largely seems a recipe for
disaster.
> From your paragraph above it seems like you were thinking there should
> be a transition at hijack time but we don't automatically transition
> anywhere except exec.
>
> Anyway, I just don't think you should completely disable this for
> SELinux users.
>
> > Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]>
> > Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
> > ---
> > include/linux/security.h | 12 +---
> > kernel/fork.c|2 +-
> > security/dummy.c |3 ++-
> > security/security.c |4 ++--
> > security/selinux/hooks.c |6 +-
> > 5 files changed, 19 insertions(+), 8 deletions(-)
> >
> > Index: upstream/include/linux/security.h
> > ===
> > --- upstream.orig/include/linux/security.h
> > +++ upstream/include/linux/security.h
> > @@ -545,9 +545,13 @@ struct request_sock;
> > * Return 0 if permission is granted.
> > * @task_alloc_security:
> > * @p contains the task_struct for child process.
> > + * @task contains the task_struct for process to be hijacked
> > * Allocate and attach a security structure to the p->security field. The
> > * security field is initialized to NULL when the task structure is
> > * allocated.
> > + * @task will usually be current. If it is not equal to current, then
> > + * a sys_hijack system call is going on, and current is asking for a
> > + * child to be created in the context of the hijack src, @task.
> > * Return 0 if operation was successful.
> > * @task_free_security:
> > * @p contains the task_struct for process.
> > @@ -1301,7 +1305,8 @@ struct security_operations {
> > int (*dentry_open) (struct file *file);
> >
> > int (*task_create) (unsigned long clone_flags);
> > - int (*task_alloc_security) (struct task_struct * p);
> > + int (*task_alloc_security) (struct task_struct *p,
> > + struct task_struct *task);
> > void (*task_free_security) (struct task_struct * p);
> > int (*task_setuid) (uid_t id0, uid_t id1, uid_t id2, int flags);
> > int (*task_post_setuid) (uid_t old_ruid /* or fsuid */ ,
> > @@ -1549,7 +1554,7 @@ int security_file_send_sigiotask(struct
> > int security_file_receive(struct file *file);
> > int security_dentry_open(struct file *file);
> > int security_task_create(unsigned long clone_flags);
> > -int security_task_alloc(struct task_struct *p);
> > +int security_task_alloc(struct task_struct *p, struct task_struct *task);
> > void security_task_free(struct task_struct *p);
> > int security_task_setuid(uid_t id0, uid_t id1, uid_t id2, int flags);
> > int security_task_post_setuid(uid_t old_ruid, uid_t old_euid,
> > @@ -2021,7 +2026,8 @@ static inline int security_task_create (
> > return 0;
> > }
> >
> > -static in
Re: Path of task via LSM
On Tue, 2007-11-27 at 09:31 -0500, Andrew Blaich wrote: > Is there a way to retrieve the full path of the currently running task > via a task_struct or similar structure from the view of the LSM? > Currently, the work I am doing with LSM design requires hooking into > bprm_alloc_security in order to read the linux_binprm structure which > contains the path of the application as it was run. Is there a > similar way to access the full path dynamically say if I'm checking a > socket based LSM hook which does not receive the linux_binprm > structure > > I have been unsuccessful in using dentry and vfsmnt from the current > task_struct via the d_path() lookup function. audit_log_task_info() is an example. It isn't a perfect technique, but usually yields the expected answer. But I wouldn't recommend doing that on every LSM hook call. -- Stephen Smalley National Security Agency - 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: Path of task via LSM
Hello. Andrew Blaich wrote: > I have been unsuccessful in using dentry and vfsmnt from the current > task_struct via the d_path() lookup function. Can't you get it from current->mm->mmap? http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/security/tomoyo/common.c#L745 Try d_path() instead of tmy_realpath_dentry(). Regards. - 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: Path of task via LSM
In the mm struct you have the struct vm_area_struct (mmap entry)... this struct contains the struct file (vm_file entry) and then you can get the f_path and f_mnt. cya, Rodrigo (BSDaemon). -- http://www.kernelhacking.com/rodrigo Kernel Hacking: If i really know, i can hack GPG KeyID: 1FCEDEA1 - Mensagem Original De: Andrew Blaich <[EMAIL PROTECTED]> Para: linux-security-module@vger.kernel.org Assunto: Path of task via LSM Data: 27/11/07 11:19 > > Is there a way to retrieve the full path of the currently running task > via a task_struct or similar structure from the view of the LSM? > Currently, the work I am doing with LSM design requires hooking into > bprm_alloc_security in order to read the linux_binprm structure which > contains the path of the application as it was run. Is there a > similar way to access the full path dynamically say if I'm checking a > socket based LSM hook which does not receive the linux_binprm > structure > > I have been unsuccessful in using dentry and vfsmnt from the current > task_struct via the d_path() lookup function. > - > 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 > > > > > Message sent using UebiMiau 2.7.2 - 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: Path of task via LSM
Tetsuo's suggestion and looking at the tomoyo source code helped me narrow down and fix the issue I was having. Thank you very much everyone. On Nov 27, 2007 9:53 AM, Tetsuo Handa <[EMAIL PROTECTED]> wrote: > Hello. > > Andrew Blaich wrote: > > I have been unsuccessful in using dentry and vfsmnt from the current > > task_struct via the d_path() lookup function. > > Can't you get it from current->mm->mmap? > http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/security/tomoyo/common.c#L745 > Try d_path() instead of tmy_realpath_dentry(). > > Regards. > > - 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: [PATCH 2/2] hijack: update task_alloc_security
Quoting Stephen Smalley ([EMAIL PROTECTED]): > On Tue, 2007-11-27 at 00:52 -0500, Joshua Brindle wrote: > > Mark Nelson wrote: > > > Subject: [PATCH 2/2] hijack: update task_alloc_security > > > > > > Update task_alloc_security() to take the hijacked task as a second > > > argument. > > > > > > For the selinux version, refuse permission if hijack_src!=current, > > > since we have no idea what the proper behavior is. Even if we > > > assume that the resulting child should be in the hijacked task's > > > domain, depending on the policy that may not be enough information > > > since init_t executing /bin/bash could result in a different domain > > > than login_t executing /bin/bash. > > > > > > > > This means its basically not possible to hijack tasks with SELinux > > right? It would be a shame if this weren't useful to people running SELinux. > > I agree with this part - we don't want people to have to choose between > using containers and using selinux, so if hijack is going to be a > requirement for effective use of containers, then we need to make them > work together. Absolutely, we just need to decide how to properly make it work with selinux. Maybe we check for allow (current_domain):(hijacked_process_domain) hijack type_transition hijacked_process_domain \ vserver_enter_binary_t:process vserver1_hijack_admin_t; The reason I decided to punt on this altogether is that the decision of which type to use for the resulting process seems tricky and definately requires new policy. If we are using completely custom and simple policies for vservers, i.e. every process in a vserver is type vserver_3_t, then it's not so complicated. But if I hijack a process in 'container 3', and the resulting type is calculated in part based on the type of the hijacked process, then I'll end up with a different type based on whether I'm hijackign the init process, an ssh daemon, someone's shell, etc. Then I do some admin activity in that resulting process and end up labeling files in the vserver based on the process I had hijacked. > > It seems to me (I may be wrong, I'm sure someone will let me know if I > > am) that the right way to handle this with SELinux is to check to see if > > the current task (caller of sys_hijack) has permission to ptrace (or > > I think this may already happen in the first patch, by virtue of calling > the existing ptrace checks including the security hook. Right? Good point, I forgot about that. So that may suffice for a permissions check. Now we just need to decide how to determine a type for the resulting process. > > some other permission deemed suitable, perhaps a new one) and if so copy > > the security blob pointer from the hijacked task to the new one (we > > don't want tranquility problems). > > Just to clarify, we wouldn't be copying the pointer; here we are > allocating and populating a new task's security structure. We can > either continue to inherit the SIDs from current in all cases, or we > could set tsec1 = hijack_src->security; in selinux_task_alloc_security() > if we wanted to inherit from the hijacked task instead. The latter > would be similar to what you do in copy_hijackable_taskinfo() for uids > and capabilities IIUC. However, which behavior is right needs more > discussion I think, as the new task is a mixture of the caller's state > and the hijacked task's state. Which largely seems a recipe for > disaster. Yes, especially if we don't have a single type for all processes in a container. Maybe what's needed is a more general discussion about how selinux policy is to be used with containers, even without hijack. I have a vm set aside where I'm starting to write a container policy module. I just need to get a kernel lined up. Was hoping to start next week. In the meantime I still think it's prudent to punt on the selinux hijacking code for now. thanks, -serge > > > From your paragraph above it seems like you were thinking there should > > be a transition at hijack time but we don't automatically transition > > anywhere except exec. > > > > Anyway, I just don't think you should completely disable this for > > SELinux users. > > > > > Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]> > > > Signed-off-by: Mark Nelson <[EMAIL PROTECTED]> > > > --- > > > include/linux/security.h | 12 +--- > > > kernel/fork.c|2 +- > > > security/dummy.c |3 ++- > > > security/security.c |4 ++-- > > > security/selinux/hooks.c |6 +- > > > 5 files changed, 19 insertions(+), 8 deletions(-) > > > > > > Index: upstream/include/linux/security.h > > > === > > > --- upstream.orig/include/linux/security.h > > > +++ upstream/include/linux/security.h > > > @@ -545,9 +545,13 @@ struct request_sock; > > > * Return 0 if permission is granted. > > > * @task_alloc_security: > > > * @p contains the task_stru
Re: [PATCH 2/2] hijack: update task_alloc_security
Quoting Casey Schaufler ([EMAIL PROTECTED]): > > --- Mark Nelson <[EMAIL PROTECTED]> wrote: > > > Subject: [PATCH 2/2] hijack: update task_alloc_security > > > > Update task_alloc_security() to take the hijacked task as a second > > argument. > > 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, forcing it to fork, then having the child execute a file and continue as your child. It takes part of its state from the current process (stack etc), some from the hijacked process (namespaces, keys?), and an lsm can decide for itself whose ->security should be used for the child process. There are a few reasons to do this. One is to do an admin activity inside a private namespace, i.e. doing a new mount in a vserver in which only websphere is running. Paul has another use for it - basically (iiuc) wanting to be able to keep a set of namespaces around which he can always enter. For mounts namespaces that can be accomplished independent of hijack by setting up a private mount tree and pivot_root()ing into there. But for other namespaces that isn't an option. 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: [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 the privilege > required to "hijack" a process. Absolutely. We're definately still in RFC territory. Note that there are currently several proposed (but no upstream) ways to accomplish entering a namespace: 1. bind_ns() is a new pair of syscalls proposed by Cedric. An nsproxy is given an integer id. The id can be used to enter an nsproxy, basically a straight current->nsproxy = target_nsproxy; 2. I had previously posted a patchset on top of the nsproxy cgroup which allowed entering a nsproxy through the ns cgroup interface. There are objections to both those patchsets because simply switching a task's nsproxy using a syscall or file write in the middle of running a binary is quite unsafe. Eric Biederman had suggested using ptrace or something like it to accomplish the goal. Just using ptrace is however not safe either. You are inheriting *all* of the target's context, so it shouldn't be difficult for a nefarious container/vserver admin to trick the host admin into running something which gives the container/vserver admin full access to the host. That's where the hijack idea came from. Yes, I called it hijack to make sure alarm 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: introduce sys_hijack (v10) > > > > Move most of do_fork() into a new do_fork_task() which acts on > > a new argument, task, rather than on current. do_fork() becomes > > a call to do_fork_task(current, ...). > > > > Introduce sys_hijack (for i386 and s390 only so far). It is like > > clone, but in place of a stack pointer (which is assumed null) it > > accepts a pid. The process identified by that pid is the one > > which is actually cloned. Some state - including the file > > table, the signals and sighand (and hence tty), and the ->parent > > are taken from the calling process. > > > > A process to be hijacked may be identified by process id, in the > > case of HIJACK_PID. Alternatively, in the case of HIJACK_CG an > > open fd for a cgroup 'tasks' file may be specified. The first > > available task in that cgroup will then be hijacked. > > > > HIJACK_NS is implemented as a third hijack method. The main > > purpose is to allow entering an empty cgroup without having > > to keep a task alive in the target cgroup. When HIJACK_NS > > is called, only the cgroup and nsproxy are copied from the > > cgroup. Security, user, and rootfs info is not retained > > in the cgroups and so cannot be copied to the child task. > > > > In order to hijack a process, the calling process must be > > allowed to ptrace the target. > > > > Sending sigstop to the hijacked task can trick its parent shell > > (if it is a shell foreground task) into thinking it should retake > > its tty. > > > > So try not sending SIGSTOP, and instead hold the task_lock over > > the hijacked task throughout the do_fork_task() operation. > > This is really dangerous. I've fixed cgroup_fork() to not > > task_lock(task) in the hijack case, but there may well be other > > code called during fork which can under "some circumstances" > > task_lock(task). > > > > Still, this is working for me. > > > > The effect is a sort of namespace enter. The following program > > uses sys_hijack to 'enter' all namespaces of the specified task. > > For instance in one terminal, do > > > > mount -t cgroup -ons cgroup /cgroup > > hostname > > qemu > > ns_exec -u /bin/sh > > hostname serge > > echo $$ > > 1073 > > cat /proc/$$/cgroup > > ns:/node_1073 > > > > In another terminal then do > > > > hostname > > qemu > > cat /proc/$$/cgroup > > ns:/ > > hijack pid 1073 > > hostname > > serge > > cat /proc/$$/cgroup > > ns:/node_1073 > > hijack cgroup /cgroup/node_1073/tasks > > > > Changelog: > > Aug 23: send a stop signal to the hijacked process > > (like ptrace does). > > Oct 09: Update for 2.6.23-rc8-mm2 (mainly pidns) > > Don't take task_lock under rcu_read_lock > > Send hijacked process to cgroup_fork() as > > the first argument. > > Removed some unneeded task_locks. > > Oct 16: Fix bug introduced into alloc_pid. > > Oct 16: Add 'int which' argument to sys_hijack to > > allow later expansion to use cgroup in place > > of pid to specify what to hijack. > >
Re: [PATCH] file capabilities: don't prevent signaling setuid root programs.
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] ~]$ cat > test.c
> main()
> {
> printf("sleeping (%u)\n", getpid());
> sleep(100);
> printf("woke up\n");
> }
> [EMAIL PROTECTED] ~]$ cc -o test test.c
> [EMAIL PROTECTED] ~]$ chmod u+s ./test
> [EMAIL PROTECTED] ~]$ ls -ltr test
> - -rwsrwxr-x 1 morgan morgan 7090 Nov 26 20:01 test
> [EMAIL PROTECTED] ~]$ setcap cap_net_raw+ep ~/test
> [EMAIL PROTECTED] ~]$ getcap ~/test
> /home/morgan/test = cap_net_raw+ep
> [EMAIL PROTECTED] ~]$ su luser
> Password:
> [EMAIL PROTECTED] morgan]$ ./test
> sleeping (5935)
>
>
> [EMAIL PROTECTED] morgan]$ kill 5935
> bash: kill: (5935) - Operation not permitted
>
> Because of the euid=0 test, the piece of code you are adding will behave
> differently in this situation. Is the root-behavior deserving of less
> protection than this one?
I don't believe in entitlement :)
> To my eye they seem equivalent.
Not to mine. The one case is classic setuid root, the other exploits
the new file capabilities - even if they don't actually add any
privilege.
> Is there a compelling reason to include the euid==0 check?
Yes, because only setuid root fills your capability sets.
In fact I was wondering whether the check should be under a check
for !SECURE_NOROOT. I think it should, but it only matters after your
per-process securebits patch is reposted.
Would you prefer if the check were under a sysctl, so that those really
using file caps could tutn off the setuid root exception? It also
provies a more graceful path toward eventually getting 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 will not cause X to exit.
> >
> > thanks,
> > -serge
> >
> >>From 81a6d780ad570f9a326fc27912ec0e373f5fa14f 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 user. This is legacy behavior
> > needed for instance for xinit to kill X when the window manager
> > exits.
> >
> > When an unprivileged user runs a setuid root program in !SECURE_NOROOT
> > mode, fP, fI, and fE are set full on, so pP' and pE' are full on.
> > Then cap_task_kill() prevents the user from signaling the setuid root
> > task. This is a change in behavior compared to when
> > !CONFIG_SECURITY_FILE_CAPABILITIES.
> >
> > This patch introduces a special check into cap_task_kill() just
> > to check whether a non-root user is signaling a setuid root
> > program started by the same user. If so, then signal is allowed.
> >
> > Changelog:
> > Nov 26: move test up above CAP_KILL test as per Andrew
> > Morgan's suggestion.
> >
> > Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
> > ---
> > security/commoncap.c |9 +
> > 1 files changed, 9 insertions(+), 0 deletions(-)
> >
> > diff --git a/security/commoncap.c b/security/commoncap.c
> > index 302e8d0..5bc1895 100644
> > --- a/security/commoncap.c
> > +++ b/security/commoncap.c
> > @@ -526,6 +526,15 @@ int cap_task_kill(struct task_struct *p, struct
> > siginfo *info,
> > if (info != SEND_SIG_NOINFO && (is_si_special(info) ||
> > SI_FROMKERNEL(info)))
> > return 0;
> >
> > + /*
> > +* Running a setuid root program raises your capabilities.
> > +* Killing your own setuid root processes was previously
> > +* allowed.
> > +* We must preserve legacy signal behavior in this case.
> > +*/
> > + if (p->euid == 0 && p->uid == current->uid)
> > + return 0;
> > +
> > /* sigcont is permitted within same session */
> > if (sig == SIGCONT && (task_session_nr(current) == task_session_nr(p)))
> > return 0;
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFHS5m/QheEq9QabfIRAmouAJkBBB0kXH57s9mvlgdG3XZhC0pZMwCfZUW3
> L4vJUkR4tgAh33GTqEquIqw=
> =sKCy
> -END PGP SIGNATURE-
> -
> 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
-
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: [PATCH 2/2] hijack: update task_alloc_security
[ resending bc the headers were screwed up in previous email, so
two lists and one individual didn't get this. hopefully it was
a user or transient error and goes through this time ]
Quoting Rodrigo Rubira Branco (BSDaemon) ([EMAIL PROTECTED]):
> It will give another easy way to locate selinux security structures inside
> the kernel, will not?
By locate, you mean actually finding the structures in kernel memory to
overwrite them?
> Again, if you have a kernel vulnerability and this feature, someone will
> easily disable selinux for the process, or just change the security concerns
> 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 <[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: update task_alloc_security
> Data: 27/11/07 02:38
>
> >
> > Mark Nelson wrote:
> > > Subject: [PATCH 2/2] hijack: update task_alloc_security
> > >
> > > Update task_alloc_security() to take the hijacked task as a second
> > > argument.
> > >
> > > For the selinux version, refuse permission if hijack_src!=current,
> > > since we have no idea what the proper behavior is. Even if we
> > > assume that the resulting child should be in the hijacked task's
> > > domain, depending on the policy that may not be enough information
> > > since init_t executing /bin/bash could result in a different domain
> > > than login_t executing /bin/bash.
> > >
> > >
> > This means its basically not possible to hijack tasks with SELinux
> > right? It would be a shame if this weren't useful to people running
> SELinux.
> >
> > It seems to me (I may be wrong, I'm sure someone will let me know if I
> > am) that the right way to handle this with SELinux is to check to see if
> > the current task (caller of sys_hijack) has permission to ptrace (or
> > some other permission deemed suitable, perhaps a new one) and if so copy
> > the security blob pointer from the hijacked task to the new one (we
> > don't want tranquility problems).
> >
> > From your paragraph above it seems like you were thinking there should
> > be a transition at hijack time but we don't automatically transition
> > anywhere except exec.
> >
> > Anyway, I just don't think you should completely disable this for
> > SELinux users.
> >
> > > Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]>
> > > Signed-off-by: Mark Nelson <[EMAIL PROTECTED]>
> > > ---
> > > include/linux/security.h | 12 +---
> > > kernel/fork.c|2 +-
> > > security/dummy.c |3 ++-
> > > security/security.c |4 ++--
> > > security/selinux/hooks.c |6 +-
> > > 5 files changed, 19 insertions(+), 8 deletions(-)
> > >
> > > Index: upstream/include/linux/security.h
> > > ===
> > > --- upstream.orig/include/linux/security.h
> > > +++ upstream/include/linux/security.h
> > > @@ -545,9 +545,13 @@ struct request_sock;
> > > *Return 0 if permission is granted.
> > > * @task_alloc_security:
> > > *@p contains the task_struct for child process.
> > > + *@task contains the task_struct for process to be hijacked
> > > *Allocate and attach a security structure to the p->security
> field. The
> > > *security field is initialized to NULL when the task structure is
> > > *allocated.
> > > + *@task will usually be current. If it is not equal to current,
> then
> > > + *a sys_hijack system call is going on, and current is asking for
> > a
> > > + *child to be created in the context of the hijack src, @task.
> > > *Return 0 if operation was successful.
> > > * @task_free_security:
> > > *@p contains the task_struct for process.
> > > @@ -1301,7 +1305,8 @@ struct security_operations {
> > >int (*dentry_open) (struct file *file);
> > >
> > >int (*task_create) (unsigned long clone_flags);
> > > - int (*task_alloc_security) (struct task_struct * p);
> > > + int (*task_alloc_security) (struct task_struct *p,
> > > + struct task_struct *task);
> > >void (*task_free_security) (struct task_struct * p);
> > >int (*task_setuid) (uid_t id0, uid_t id1, uid_t id2, int flags);
> > >int (*task_post_setuid) (uid_t old_ruid /* or fsuid */ ,
> > > @@ -1549,7 +1554,7 @@ int security_file_send_sigiotask(struct
> > > int security_file_receive(struct file *file);
> > > int security_dentry_open(struct file *file);
> > > int security_task_create(unsigned long clone_flags);
Re: [PATCH 1/2] namespaces: introduce sys_hijack (v10)
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 is it for? > > Please see my response to Casey's email. > > > And I second Casey's concern about careful management of the privilege > > required to "hijack" a process. > > Absolutely. We're definately still in RFC territory. > > Note that there are currently several proposed (but no upstream) ways to > accomplish entering a namespace: > > 1. bind_ns() is a new pair of syscalls proposed by Cedric. An > nsproxy is given an integer id. The id can be used to enter > an nsproxy, basically a straight current->nsproxy = target_nsproxy; > > 2. I had previously posted a patchset on top of the nsproxy > cgroup which allowed entering a nsproxy through the ns cgroup > interface. > > There are objections to both those patchsets because simply switching a > task's nsproxy using a syscall or file write in the middle of running a > binary is quite unsafe. Eric Biederman had suggested using ptrace or > something like it to accomplish the goal. > > Just using ptrace is however not safe either. You are inheriting *all* > of the target's context, so it shouldn't be difficult for a nefarious > container/vserver admin to trick the host admin into running something > which gives the container/vserver admin full access to the host. I don't follow the above - with ptrace, you are controlling a process already within the container (hence in theory already limited to its container), and it continues to execute within that container. What's the issue there? > That's where the hijack idea came from. Yes, I called it hijack to make > sure alarm bells went off :) bc it's definately still worrisome. But at > this point I believe it is the safest solution suggested so far. -- Stephen Smalley National Security Agency - 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: [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.,
>
> #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 PROTECTED](none)>
Date: Tue, 27 Nov 2007 10:37:57 -0800
Subject: [PATCH 1/1] capabilities: fix CAP_LAST_CAP to CAP_MAC_ADMIN
A recent SMACK patch introduced two new capabilities. The capability
bounding set patch defined CAP_LAST_CAP erroneously relative to that
patch.
Signed-off-by: Serge Hallyn <[EMAIL PROTECTED]>
---
include/linux/capability.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/capability.h b/include/linux/capability.h
index 5fc3fea..7d50ff6 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -332,7 +332,7 @@ typedef struct kernel_cap_struct {
#define CAP_MAC_ADMIN33
-#define CAP_LAST_CAP CAP_SETFCAP
+#define CAP_LAST_CAP CAP_MAC_ADMIN
#define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
--
1.5.1
-
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: [PATCH] -mm (2.4.26-rc3-mm1) v2 Smack using capabilities 32 and 33
On Mon, 26 Nov 2007 12:38:56 -0800 Casey Schaufler <[EMAIL PROTECTED]> wrote: > 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 pair, one for overriding access control checks and > the other for changes to the MAC configuration. > > The two capabilities allocated should be obvious in their intent. > The comments in capability.h are intended to make it clear that > there is no intention that implementations of MAC LSM modules > be any more constrained by the presence of these capabilities > than an implementation of DAC LSM modules are by the analogous > DAC capabilities. > > > + !__capable(current, CAP_MAC_ADMIN)) > + !__capable(current, CAP_MAC_ADMIN)) Is there any reason for not using plain old capable() here? - 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: [PATCH] -mm (2.4.26-rc3-mm1) v2 Smack using capabilities 32 and 33
--- Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > + !__capable(current, CAP_MAC_ADMIN)) > > + !__capable(current, CAP_MAC_ADMIN)) > > Is there any reason for not using plain old capable() here? Nope. I'll clean that up. Thank you. Casey Schaufler [EMAIL PROTECTED] - 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: [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 is it for? > > > > Please see my response to Casey's email. > > > > > And I second Casey's concern about careful management of the privilege > > > required to "hijack" a process. > > > > Absolutely. We're definately still in RFC territory. > > > > Note that there are currently several proposed (but no upstream) ways to > > accomplish entering a namespace: > > > > 1. bind_ns() is a new pair of syscalls proposed by Cedric. An > > nsproxy is given an integer id. The id can be used to enter > > an nsproxy, basically a straight current->nsproxy = target_nsproxy; > > > > 2. I had previously posted a patchset on top of the nsproxy > > cgroup which allowed entering a nsproxy through the ns cgroup > > interface. > > > > There are objections to both those patchsets because simply switching a > > task's nsproxy using a syscall or file write in the middle of running a > > binary is quite unsafe. Eric Biederman had suggested using ptrace or > > something like it to accomplish the goal. > > > > Just using ptrace is however not safe either. You are inheriting *all* > > of the target's context, so it shouldn't be difficult for a nefarious > > container/vserver admin to trick the host admin into running something > > which gives the container/vserver admin full access to the host. > > I don't follow the above - with ptrace, you are controlling a process > already within the container (hence in theory already limited to its > container), and it continues to execute within that container. What's > the issue there? Hmm, yeah, I may have overspoken - I'm not good at making up exploits but while I see it possible to confuse the host admin by setting bogus environment, I guess there may not be an actual exploit. Still after the fork induced through ptrace, we'll have to execute a file out of the hijacked process' namespaces and path (unless we get *really* 'exotic'). With hijack, execution continues under the caller's control, which I do much prefer. The remaining advantages of hijack over ptrace (beside "using ptrace for that is crufty") are 1. not subject to pid wraparound (when doing hijack_cgroup or hijack_ns) 2. ability to enter a namespace which has no active processes These also highlight selinux issues. In the case of hijacking an empty cgroup, there is no security context (because there is no task) so the context of 'current' will be used. In the case of hijacking a populated cgroup, a task is chosen "at random" to be the hijack source. So there are two ways to look at deciding which context to use. Since control continues in the original acting process' context, we might want the child to continue in its context. However if the process creates any objects in the virtual server, we don't want them mislabeled, so we might want the task in the hijacked task's context. Sigh. So here's why I thought I'd punt on selinux at least until I had a working selinux-enforced container/vserver :) -serge PS: I'm certainly open to the suggestion that the kernel patch in the end us as crufty as using ptrace. > > That's where the hijack idea came from. Yes, I called it hijack to make > > sure alarm bells went off :) bc it's definately still worrisome. But at > > this point I believe it is the safest solution suggested so far. > > -- > Stephen Smalley > National Security Agency > > - > 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 - 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: [PATCH 1/2] namespaces: introduce sys_hijack (v10)
--- "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. > > > > > > > > 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 the privilege > > > > required to "hijack" a process. > > > > > > Absolutely. We're definately still in RFC territory. > > > > > > Note that there are currently several proposed (but no upstream) ways to > > > accomplish entering a namespace: > > > > > > 1. bind_ns() is a new pair of syscalls proposed by Cedric. An > > > nsproxy is given an integer id. The id can be used to enter > > > an nsproxy, basically a straight current->nsproxy = target_nsproxy; > > > > > > 2. I had previously posted a patchset on top of the nsproxy > > > cgroup which allowed entering a nsproxy through the ns cgroup > > > interface. > > > > > > There are objections to both those patchsets because simply switching a > > > task's nsproxy using a syscall or file write in the middle of running a > > > binary is quite unsafe. Eric Biederman had suggested using ptrace or > > > something like it to accomplish the goal. > > > > > > Just using ptrace is however not safe either. You are inheriting *all* > > > of the target's context, so it shouldn't be difficult for a nefarious > > > container/vserver admin to trick the host admin into running something > > > which gives the container/vserver admin full access to the host. > > > > I don't follow the above - with ptrace, you are controlling a process > > already within the container (hence in theory already limited to its > > container), and it continues to execute within that container. What's > > the issue there? > > Hmm, yeah, I may have overspoken - I'm not good at making up exploits > but while I see it possible to confuse the host admin by setting bogus > environment, I guess there may not be an actual exploit. > > Still after the fork induced through ptrace, we'll have to execute a > file out of the hijacked process' namespaces and path (unless we get > *really* 'exotic'). With hijack, execution continues under the caller's > control, which I do much prefer. > > The remaining advantages of hijack over ptrace (beside "using ptrace for > that is crufty") are > > 1. not subject to pid wraparound (when doing hijack_cgroup > or hijack_ns) > 2. ability to enter a namespace which has no active processes > > These also highlight selinux issues. In the case of hijacking an > empty cgroup, there is no security context (because there is no task) so > the context of 'current' will be used. In the case of hijacking a > populated cgroup, a task is chosen "at random" to be the hijack source. > > So there are two ways to look at deciding which context to use. Since > control continues in the original acting process' context, we might > want the child to continue in its context. However if the process > creates any objects in the virtual server, we don't want them > mislabeled, so we might want the task in the hijacked task's context. I wouldn't be surprised if you've been over this a dozen times already, but why hijack an existing process instead of injecting a new one with completely specified attributes? That way you don't distinguish between an empty cgroup and a propulated one and you're not at the mercy of the available hijackees. I know that I would be much less uncomfortable with that schenario. > Sigh. So here's why I thought I'd punt on selinux at least until I had > a working selinux-enforced container/vserver :) > > -serge > > PS: I'm certainly open to the suggestion that the kernel patch in the > end us as crufty as using ptrace. > > > > That's where the hijack idea came from. Yes, I called it hijack to make > > > sure alarm bells went off :) bc it's definately still worrisome. But at > > > this point I believe it is the safest solution suggested so far. > > > > -- > > Stephen Smalley > > National Security Agency > > > > - > > 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 > - > 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 > > > Casey Schaufler [EMAIL PROTECTED] - 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: [PATCH 2/2] hijack: update task_alloc_security
Serge E. Hallyn wrote: > Quoting Stephen Smalley ([EMAIL PROTECTED]): > >> I agree with this part - we don't want people to have to choose between >> using containers and using selinux, so if hijack is going to be a >> requirement for effective use of containers, then we need to make them >> work together. >> > Absolutely, we just need to decide how to properly make it work with > selinux. Maybe we check for > > allow (current_domain):(hijacked_process_domain) hijack > type_transition hijacked_process_domain \ > vserver_enter_binary_t:process vserver1_hijack_admin_t; > Is there to be an LSM hook, so that modules can decide on an arbitrary decision of whether to allow a hijack? So that this "do the right SELinux" thing can be generalized for all LSMs to do the right thing. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - 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: [PATCH 2/2] hijack: update task_alloc_security
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, forcing it to fork, then having > the child execute a file and continue as your child. It takes part of > its state from the current process (stack etc), some from the hijacked > process (namespaces, keys?), and an lsm can decide for itself whose ->security > should be used for the child process. > That just doesn't gob smack me with the obvious abstract intention of this API :) So it is like I want to run a process inside a name space, but I am not inside that name space, so I highjack one that is in there, force it to fork, and then give me its child. Ugh. Couldn't we just implement "put me in that namespace over there?" AFAIK namespaces don't actually have names, making it hard to implement "put me in namespace Foo", but I view that as a defect of namespaces that should be fixed, rather than hacked around. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - 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
