[refpolicy] container policy interface

[dwalsh@redhat.com (Daniel J Walsh)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Serge E. Hallyn wrote:
> Quoting Serge E. Hallyn (serue at us.ibm.com):
>> Hi,
>>
>> I've been playing a bit with creating LSM-protected containers.
>> Attached here are first stabs at an SELinux policy module (against
>> the refpolicy source with fedora 10) defining an interface
>> to create containers.  The .te and .fc files use the interface
>> to create two containers, under /vs1 and /vs2.  I've been
>> testing with liblxc (*1) creating debian-based containers
>> using debootstrap, on a fedora 10 host.  It should work
>> equally well for libvirt though.  Quite simply, $1_exec_t
>> is assigned to the container's /sbin/init, and used to
>> transition to the container's own type.  (So far I'm lazily
>> using the devices whitelist cgroup to protect against device
>> access)
>>
>> This interface is geared toward containers which have their
>> own private chroot.  Containers can also be made minimalist
>> sharing read-only bind mounts of most of the fs.  Such
>> containers should probably have their own interface, but
>> in any case I'm ignoring them for now.
>>
>> Perhaps for starters, I don't know if there is a precedent
>> for this kind of interface.  Would we want just the .if in
>> the base policy, with the user writing custom .te and .fc
>> files, based on the if, which they compile under /usr/share/selinux/?
>>
>> Anyway, I'm posting this to see how far we can go toward
>> making something actually useful for the refpolicy.
> 
> Well, no responses, but in any case here's a slightly updated
> .if file which is working for me atm.
> 
> thanks,
> -serge
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
Interesting idea, although I have never used containers.

Rather then specifying unconfined_t and staff_t I think it would be
better to define an attribute

container_userdomain

domain_auto_trans(container_userdomain,$1_exec_t,$1_t)
	allow unconfined_t $1_exec_t:file {read execute};
Not needed
	allow $1_t $1_exec_t:file {read execute entrypoint};
Replace with
can_exec($1_t, $1_exec_t)

	allow unconfined_t $1_t:dir create_dir_perms;
allow container_userdomain $1_t:dir create_dir_perms;
	neverallow unconfined_t $1_t:file execute;
Not sure what executing a /proc file means anyways.


allow $1_t unconfined_devpts_t:chr_file {setattr rw_term_perms};
	allow $1_t console_device_t:chr_file {setattr rw_chr_file_perms};
	allow $1_t staff_devpts_t:chr_file rw_chr_file_perms;

Just use the term_use interfaces.

	allow $1_t device_t:filesystem mount;
	allow $1_t device_t:dir { write setattr mounton add_name };
	allow $1_t device_t:fifo_file { create rw_fifo_file_perms };
This looks like a labeling problem, there should not be a file system
labeled device_t or fifo files

	allow $1_t clock_device_t:chr_file read_chr_file_perms;

Does this mean you confine domain can change the time?

	allow $1_t $1_file_t:file *;
	allow $1_t $1_file_t:lnk_file *;
	allow $1_t $1_file_t:chr_file *;
	allow $1_t $1_file_t:blk_file *;
	allow $1_t $1_file_t:sock_file *;
	allow $1_t $1_file_t:fifo_file *;
	allow $1_t $1_t:fifo_file *;
	allow $1_t $1_file_t:socket *;
	allow $1_t $1_file_t:dir *;

I would use the manage_*_perms rather then the *;

	allow $1_t $1_t:process ~{setcurrent};
	allow $1_t $1_t:capability ~{audit_write audit_control sys_module};

These are rather broad, not sure you need this much.
	dev_read_urand($1_t)

In there twice
	allow $1_t port_t:tcp_socket *;

THis allows you to use all non labeled ports to connect or bind.

	gen_require(`
		type proc_t;
		role system_r;
		role unconfined_r;
		type unconfined_t;
		type unconfined_devpts_t;
		type staff_t;
		type staff_devpts_t;
		type fs_t;
		type devpts_t;
		type sysfs_t;
		type inaddr_any_node_t;
		type clock_device_t;
		type tmpfs_t;
		type port_t;
	');

You should eliminate this entire section and use the appropriate
interfaces if the access is really needed.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkk/4owACgkQrlYvE4MpobNDSACg589AigXJ84igh3+roao12HYx
kNQAn00D5mN/nKFKSY3vSxNiN6Hb/kzM
=5Uh0
-----END PGP SIGNATURE-----