RFC: jail functionality

RFC: jail functionality

[serue]

[-- Attachment #1: Type: text/plain, Size: 2596 bytes --]

Hi,

I'd still like to see bsdjail/vserver/zone functionality in linux.  It
seems to me the following pieces are needed:

	filesystem namespaces (mostly there, probably want shared
					subtrees)
	read-only bind mounts (not there yet)
	task separation (ie ptrace, etc: can be done by selinux)
	task-hiding ability (see attached patches)
	network jails (see below)
	hostname/domainname per jail?  (is this necessary?)
	resource management - can be done by selinux, ckrm, etc
	filesystem controls - can be done by selinux, using a simple
			policy (attached) provided jails get their own
			(loopback is fine) filesystem;  else read-only
			bind mounts would also help.
	more?
	Some intuitive script(s) to use all of the above.

Attached are the old task_lookup patch which was used by the bsdjail lsm,
a patch for selinux to utilize this hook, and a sample jail policy and
.fc, which presumably would eventually be changed to a jail_domain()
policy macro.  Does this seem at all useful by itself, or should this
wait until it were actually needed for a complete linux jails
implementation?  (Note that access_vectors.diff patches
/etc/selinux/targeted/src/policy/flask/access_vectors, jail2.fc can go
in /etc/selinux/targeted/src/policy/file_contexts/misc/, and jail2.te
can go into /etc/selinux/targeted/src/policy/domains/misc/)

It seems to me the greatest challenge is network jails.  I don't think
this can be done right with selinux.  I believe you can restrict a
domain's access to remote addresses by IP, but not to local addresses
during bind.  Am I wrong in assuming jails would be useless without
this?  (I suppose they could at least be useful for sandboxes of some
sort)  Does anyone have ideas on a good way to implement these?

Some time ago I sent out an RFC for network namespaces, which allowed a
process to essentially give up its access to a network device.  The
patch only allowed a process to give up access to real network devices,
not ip aliases (ie eth0:0).  But this seems much less useful for
allowing admins to provide multiple jails.

The linux-vserver team is working on virtual networking which (IIUC)
creates a virtual network device which is then associated with a
virtual address, a real network device, and a jail.  This appears to
be a way to make the simple version of network namespaces I describe
in the paragraph above more useful, since we would not need to deal
with ip aliases.

Is there any interest in seeing the virtual network devices and
network namespaces pushed upstream?

Read-only bind mounts?

The attached task-lookup patches?

thanks,
-serge

[-- Attachment #2: access_vectors.diff --]
[-- Type: text/plain, Size: 207 bytes --]

--- access_vectors	2005-06-29 15:28:23.000000000 -0500
+++ access_vectors.new	2005-06-29 15:28:20.000000000 -0500
@@ -245,6 +245,7 @@ class process
 	dyntransition
 	setcurrent
 	execmem
+	tasklookup
 }
 
 

[-- Attachment #3: jail2.fc --]
[-- Type: text/plain, Size: 128 bytes --]

/mnt/jail2 -d user_u:object_r:jail2_file_t
/mnt/jail2/.* user_u:object_r:jail2_file_t
/bin/chroot_ns user_u:object_r:chrootns_t

[-- Attachment #4: jail2.te --]
[-- Type: text/plain, Size: 1735 bytes --]

type jail2_file_t, file_type;
type jail2_t, domain;
type chrootns_t, file_type;
role user_r types jail2_t;
role system_r types jail2_t;

domain_auto_trans(unconfined_t,jail2_file_t,jail2_t);

#rw_dir_create_file(jail2_t,jail2_file_t);
file_type_auto_trans(jail2_t,jail2_file_t,jail2_file_t)

allow jail2_t jail2_file_t:{ fd blk_file chr_file lnk_file fifo_file sock_file file dir } *;

allow jail2_t jail2_file_t:{ socket tcp_socket udp_socket rawip_socket node netif netlink_socket packet_socket } *;

allow jail2_t devpts_t:chr_file *;
allow jail2_t tty_device_t:chr_file *;
can_create_pty(jail2, `, userpty_type, user_tty_type')

allow jail2_t jail2_t:dir { read getattr lock search ioctl };
allow jail2_t jail2_t:{file fifo_file} { ioctl read getattr lock write append };

r_dir_file(jail2_t,proc_t);

allow jail2_t netif_eth1_t:netif *;

allow jail2_t jail2_t:{ socket udp_socket tcp_socket rawip_socket packet_socket } *;
allow jail2_t jail2_t:{netlink_socket key_socket unix_stream_socket unix_dgram_socket } *;

allow jail2_t jail2_t:{ sem msg msgq shm ipc } *;

allow jail2_t netif_lo_t:netif *;
allow jail2_t node_lo_t:node *;
allow jail2_t node_t:node *;

#allow jail2_t jail2_t:security { };
allow jail2_t jail2_t:process ~{ setsched setexec setfscreate dyntransition setcurrent setrlimit rlimitinh };
#allow jail2_t jail2_t:system { };
#allow jail2_t jail2_t:capability ~{ sys_module sys_chroot sys_resource sys_time mknod net_admin };
allow jail2_t jail2_t:capability ~{ sys_module sys_resource sys_time mknod net_admin };

allow jail2_t dns_port_t:udp_socket { send_msg recv_msg };
allow jail2_t reserved_port_t:tcp_socket ~{ relabelfrom relabelto };
allow jail2_t reserved_port_t:udp_socket ~{ relabelfrom relabelto };

[-- Attachment #5: tasklookup.diff --]
[-- Type: text/plain, Size: 3233 bytes --]

Index: linux-2.6.12-jail/fs/proc/base.c
===================================================================
--- linux-2.6.12-jail.orig/fs/proc/base.c	2005-06-29 15:33:50.000000000 -0500
+++ linux-2.6.12-jail/fs/proc/base.c	2005-06-29 15:34:17.000000000 -0500
@@ -1911,6 +1911,8 @@ static int get_tgid_list(int index, unsi
 		int tgid = p->pid;
 		if (!pid_alive(p))
 			continue;
+		if (security_task_lookup(p))
+			continue;
 		if (--index >= 0)
 			continue;
 		tgids[nr_tgids] = tgid;
Index: linux-2.6.12-jail/include/linux/security.h
===================================================================
--- linux-2.6.12-jail.orig/include/linux/security.h	2005-06-29 15:33:51.000000000 -0500
+++ linux-2.6.12-jail/include/linux/security.h	2005-06-29 15:34:17.000000000 -0500
@@ -632,6 +632,11 @@ struct swap_info_struct;
  * 	Set the security attributes in @p->security for a kernel thread that
  * 	is being reparented to the init task.
  *	@p contains the task_struct for the kernel thread.
+ * @task_lookup:
+ *	Check permission to see the /proc/<pid> entry for process @p.
+ *	@p contains the task_struct for task <pid> which is being looked
+ *	up under /proc
+ *	return 0 if permission is granted.
  * @task_to_inode:
  * 	Set the security attributes for an inode based on an associated task's
  * 	security attributes, e.g. for /proc/pid inodes.
@@ -1167,6 +1172,7 @@ struct security_operations {
 			   unsigned long arg3, unsigned long arg4,
 			   unsigned long arg5);
 	void (*task_reparent_to_init) (struct task_struct * p);
+	int (*task_lookup)(struct task_struct *p);
 	void (*task_to_inode)(struct task_struct *p, struct inode *inode);
 
 	int (*ipc_permission) (struct kern_ipc_perm * ipcp, short flag);
@@ -1840,6 +1846,11 @@ static inline void security_task_reparen
 	security_ops->task_reparent_to_init (p);
 }
 
+static inline int security_task_lookup(struct task_struct *p)
+{
+	return security_ops->task_lookup(p);
+}
+
 static inline void security_task_to_inode(struct task_struct *p, struct inode *inode)
 {
 	security_ops->task_to_inode(p, inode);
@@ -2489,6 +2500,11 @@ static inline void security_task_reparen
 	cap_task_reparent_to_init (p);
 }
 
+static inline int security_task_lookup(struct task_struct *p)
+{
+	return 0;
+}
+
 static inline void security_task_to_inode(struct task_struct *p, struct inode *inode)
 { }
 
Index: linux-2.6.12-jail/security/dummy.c
===================================================================
--- linux-2.6.12-jail.orig/security/dummy.c	2005-06-29 15:33:52.000000000 -0500
+++ linux-2.6.12-jail/security/dummy.c	2005-06-29 15:34:17.000000000 -0500
@@ -582,6 +582,11 @@ static void dummy_task_reparent_to_init 
 	return;
 }
 
+static int dummy_task_lookup(struct task_struct *p)
+{
+	return 0;
+}
+
 static void dummy_task_to_inode(struct task_struct *p, struct inode *inode)
 { }
 
@@ -943,6 +948,7 @@ void security_fixup_ops (struct security
 	set_to_dummy_if_null(ops, task_kill);
 	set_to_dummy_if_null(ops, task_prctl);
 	set_to_dummy_if_null(ops, task_reparent_to_init);
+ 	set_to_dummy_if_null(ops, task_lookup);
  	set_to_dummy_if_null(ops, task_to_inode);
 	set_to_dummy_if_null(ops, ipc_permission);
 	set_to_dummy_if_null(ops, msg_msg_alloc_security);

[-- Attachment #6: selinux-tasklookup.diff --]
[-- Type: text/plain, Size: 2369 bytes --]

Index: linux-2.6.12-jail/security/selinux/include/av_perm_to_string.h
===================================================================
--- linux-2.6.12-jail.orig/security/selinux/include/av_perm_to_string.h	2005-06-29 15:34:29.000000000 -0500
+++ linux-2.6.12-jail/security/selinux/include/av_perm_to_string.h	2005-06-29 15:34:34.000000000 -0500
@@ -70,6 +70,7 @@
    S_(SECCLASS_PROCESS, PROCESS__DYNTRANSITION, "dyntransition")
    S_(SECCLASS_PROCESS, PROCESS__SETCURRENT, "setcurrent")
    S_(SECCLASS_PROCESS, PROCESS__EXECMEM, "execmem")
+   S_(SECCLASS_PROCESS, PROCESS__TASKLOOKUP, "tasklookup")
    S_(SECCLASS_MSGQ, MSGQ__ENQUEUE, "enqueue")
    S_(SECCLASS_MSG, MSG__SEND, "send")
    S_(SECCLASS_MSG, MSG__RECEIVE, "receive")
Index: linux-2.6.12-jail/security/selinux/hooks.c
===================================================================
--- linux-2.6.12-jail.orig/security/selinux/hooks.c	2005-06-29 15:34:29.000000000 -0500
+++ linux-2.6.12-jail/security/selinux/hooks.c	2005-06-29 15:34:34.000000000 -0500
@@ -2774,6 +2774,11 @@ static void selinux_task_to_inode(struct
 	return;
 }
 
+static int selinux_task_lookup(struct task_struct *p)
+{
+	return task_has_perm(current, p, PROCESS__TASKLOOKUP);
+}
+
 #ifdef CONFIG_SECURITY_NETWORK
 
 /* Returns error only if unable to parse addresses */
@@ -4334,6 +4339,7 @@ static struct security_operations selinu
 	.task_prctl =			selinux_task_prctl,
 	.task_reparent_to_init =	selinux_task_reparent_to_init,
 	.task_to_inode =                selinux_task_to_inode,
+	.task_lookup =			selinux_task_lookup,
 
 	.ipc_permission =		selinux_ipc_permission,
 
Index: linux-2.6.12-jail/security/selinux/include/av_permissions.h
===================================================================
--- linux-2.6.12-jail.orig/security/selinux/include/av_permissions.h	2005-06-29 15:34:29.000000000 -0500
+++ linux-2.6.12-jail/security/selinux/include/av_permissions.h	2005-06-29 15:34:34.000000000 -0500
@@ -465,6 +465,7 @@
 #define PROCESS__DYNTRANSITION                    0x00800000UL
 #define PROCESS__SETCURRENT                       0x01000000UL
 #define PROCESS__EXECMEM                          0x02000000UL
+#define PROCESS__TASKLOOKUP                       0x04000000UL
 
 #define IPC__CREATE                               0x00000001UL
 #define IPC__DESTROY                              0x00000002UL

Re: RFC: jail functionality

[Stephen Smalley]

On Wed, 2005-06-29 at 11:14 -0500, serue@us.ibm.com wrote:
> Attached are the old task_lookup patch which was used by the bsdjail lsm,
> a patch for selinux to utilize this hook, and a sample jail policy and
> .fc, which presumably would eventually be changed to a jail_domain()
> policy macro.  Does this seem at all useful by itself, or should this
> wait until it were actually needed for a complete linux jails
> implementation?

What's the real benefit of "hiding" tasks in this manner?  SELinux can
already prevent processes from accessing anything under /proc/pid for a
process in another domain, and procps already conveniently omits entries
for any such inaccessible /proc/pid directories, so the typical user
experience is the same (i.e. users won't see processes that are
inaccessible in ps output) and at most, only the pids are exposed
in /proc.  

> It seems to me the greatest challenge is network jails.  I don't think
> this can be done right with selinux.  I believe you can restrict a
> domain's access to remote addresses by IP, but not to local addresses
> during bind.  Am I wrong in assuming jails would be useless without
> this?  (I suppose they could at least be useful for sandboxes of some
> sort)  Does anyone have ideas on a good way to implement these?

SELinux has a node_bind check applied upon bind(2) that is based on the
address, similar to the name_bind check based on port.  However, this
doesn't address auto-binding of sockets by the kernel (e.g. when
connecting/sending on an unbound socket), and it doesn't make address
selection transparent for userspace.  

> Some time ago I sent out an RFC for network namespaces, which allowed a
> process to essentially give up its access to a network device.  The
> patch only allowed a process to give up access to real network devices,
> not ip aliases (ie eth0:0).  But this seems much less useful for
> allowing admins to provide multiple jails.
> 
> The linux-vserver team is working on virtual networking which (IIUC)
> creates a virtual network device which is then associated with a
> virtual address, a real network device, and a jail.  This appears to
> be a way to make the simple version of network namespaces I describe
> in the paragraph above more useful, since we would not need to deal
> with ip aliases.
> 
> Is there any interest in seeing the virtual network devices and
> network namespaces pushed upstream?

Yes, although I can't say that I've looked at their approach.

> Read-only bind mounts?

Not sure what happened to earlier discussions and patches related to
that issue on lkml.

> The attached task-lookup patches?

Not sure it provides much value.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: jail functionality

[James Morris]

On Wed, 29 Jun 2005, Stephen Smalley wrote:

> > The attached task-lookup patches?
> 
> Not sure it provides much value.

If yoy need this, why not look at proper isolation via Xen?

LSM is about access control, not virtualization.


- James
-- 
James Morris
<jmorris@redhat.com>



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: jail functionality

[serue]

Quoting James Morris (jmorris@redhat.com):
> On Wed, 29 Jun 2005, Stephen Smalley wrote:
> 
> > > The attached task-lookup patches?
> > 
> > Not sure it provides much value.
> 
> If yoy need this, why not look at proper isolation via Xen?

Xen may be overkill for some cases, as you need (almost) a whole OS
for each jail.  Zones and bsd jails (I believe) should easily be
able to run hundreds of jails - provided of course they don't all
peak at once.

Don't get me wrong, I'm a big fan of virtualization, and while I
don't get to right now, IBM is putting a lot of effort into Xen.

> LSM is about access control, not virtualization.

And jails require some amount of access control.  I don't want to
introduce a new LSM for this, but just put together the various
existing (and not-yet-existing) pieces into an easy to use package.

thanks,
-serge

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: jail functionality

[Colin Walters]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On Wed, 2005-06-29 at 13:42 -0500, serue@us.ibm.com wrote:
> Quoting James Morris (jmorris@redhat.com):
> > On Wed, 29 Jun 2005, Stephen Smalley wrote:
> > 
> > > > The attached task-lookup patches?
> > > 
> > > Not sure it provides much value.
> > 
> > If yoy need this, why not look at proper isolation via Xen?
> 
> Xen may be overkill for some cases, as you need (almost) a whole OS
> for each jail.  Zones and bsd jails (I believe) should easily be
> able to run hundreds of jails - provided of course they don't all
> peak at once.

What you are saying is: Xen is a heavyweight virtualization solution
that doesn't scale well when the user wants many instances of the exact
same OS, as opposed to potentially different OSes.

However, solving this (or at least drastically reducing the overhead) is
on the Xen roadmap:

http://www.cl.cam.ac.uk/Research/SRG/netos/xen/roadmap.html

(Shared buffer-cache and VM 'forks')

> And jails require some amount of access control.  I don't want to
> introduce a new LSM for this, but just put together the various
> existing (and not-yet-existing) pieces into an easy to use package.

I think this is useful, actually.  For some uses like build system
chroots, all the user really wants is some integrity protection against
accidental damage from poorly-written code, they don't need resource
management or any strong guarantees of integrity in the face of
malicious code.  

But you should be aware that for a lot of the zone use cases, resource
management is very important, and SELinux doesn't provide that.  You
mention CKRM, but that's a whole other kernel patch.  Xen definitely
seems to be the approach that's winning here.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: RFC: jail functionality

[Stephen Smalley]

On Thu, 2005-06-30 at 09:19 -0400, Colin Walters wrote:
> But you should be aware that for a lot of the zone use cases, resource
> management is very important, and SELinux doesn't provide that.  You
> mention CKRM, but that's a whole other kernel patch.  Xen definitely
> seems to be the approach that's winning here.

IMHO, CKRM should be integrated with SELinux to allow policy control
over resource management.

For strict isolation (which does seem to be the theme of jail) as well
as complete transparency of that isolation, virtualization make sense.
But for controlled sharing, you will ultimately need OS-level controls.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: jail functionality

[serue]

Quoting Stephen Smalley (sds@tycho.nsa.gov):
> On Wed, 2005-06-29 at 11:14 -0500, serue@us.ibm.com wrote:
> > Attached are the old task_lookup patch which was used by the bsdjail lsm,
> > a patch for selinux to utilize this hook, and a sample jail policy and
> > .fc, which presumably would eventually be changed to a jail_domain()
> > policy macro.  Does this seem at all useful by itself, or should this
> > wait until it were actually needed for a complete linux jails
> > implementation?
> 
> What's the real benefit of "hiding" tasks in this manner?

In terms of security, I'd say none, except perhaps a hard-to-exploit
covert channel.  IMO, it would only be for user convenience.

> SELinux can
> already prevent processes from accessing anything under /proc/pid for a
> process in another domain, and procps already conveniently omits entries
> for any such inaccessible /proc/pid directories, so the typical user
> experience is the same (i.e. users won't see processes that are
> inaccessible in ps output) and at most, only the pids are exposed
> in /proc.  

I didn't think procps did that.  In that case, I guess tasklookup can
be taken off the list of jail requisites.

> > Is there any interest in seeing the virtual network devices and
> > network namespaces pushed upstream?
> 
> Yes, although I can't say that I've looked at their approach.

Ok - so long as there is interest, I will try to take some time to
write a standalone patch for it.  Then hopefully if their approach
or my port of it is not acceptable, someone else will code up an
acceptable version :)

> > Read-only bind mounts?
> 
> Not sure what happened to earlier discussions and patches related to
> that issue on lkml.

Christoph Hellwig said he wants it, but wanted a different
implementation, but hasn't had a chance to write up his own.  The author
of the existing patches feels there's not enough support/interest and
too much opposition, so has not resubmitted (after I believe his 6th
version).

> > The attached task-lookup patches?
> 
> Not sure it provides much value.

Sounds good.

thanks,
-serge

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: jail functionality

[Greg KH]

On Wed, Jun 29, 2005 at 11:14:09AM -0500, serue@us.ibm.com wrote:
> Hi,
> 
> I'd still like to see bsdjail/vserver/zone functionality in linux.  It
> seems to me the following pieces are needed:
> 
> 	more?

/sbin/hotplug and/or kevents.

I spent a few hours with one of the authors of the bsd jail code talking
about this and in the end, he just laughed and said "good luck."  He
also admitted that this was one of the reasons bsd wouldn't get such an
event notifier subsystem, so I figured it was a fair trade off.

Oh, and devfs in a jail is a pain in the ass, but if you solve the
hotplug/kevent issue, you can just use udev to handle that.

Good luck,

greg k-h

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: RFC: jail functionality

[serue]

Quoting Greg KH (greg@kroah.com):
> On Wed, Jun 29, 2005 at 11:14:09AM -0500, serue@us.ibm.com wrote:
> > Hi,
> > 
> > I'd still like to see bsdjail/vserver/zone functionality in linux.  It
> > seems to me the following pieces are needed:
> > 
> > 	more?
> 
> /sbin/hotplug and/or kevents.

Thanks - I can't even imagine what the issues would be.  I'll need to
look at their architectures in more detail.

> I spent a few hours with one of the authors of the bsd jail code talking
> about this and in the end, he just laughed and said "good luck."  He
> also admitted that this was one of the reasons bsd wouldn't get such an
> event notifier subsystem, so I figured it was a fair trade off.

I wonder how/whether it's working under linux-vserver.

I'll have to look into these.

thanks,
-serge

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.