Cockpit as a privileged container?

Daniel J Walsh dwalsh at redhat.com
Wed Aug 6 13:37:26 UTC 2014


On 08/06/2014 04:57 AM, Trevor Jay wrote:
> On Tue, Aug 05, 2014 at 09:14:59AM -0400, Daniel J Walsh wrote:
>> Well /proc is not only being blocked by SELinux, but also you are still
>> entering a different PID namespace.
>>
> Fair enough, but with greater SELinux permissions /proc still gives you alot of process monitoring options.
>
>> On 08/04/2014 10:57 PM, Trevor Jay wrote:
>>> Speaking of that: you mentioned a "set" collection of
>>> namespaces/privileges to choose from at container launch time. How clear
>>> are those at this point? It would be good if we could whip up roughly
>>> equivalent types now so that the cockpit guys could begin seeing what
>>> they'd need to adjust.
>>>
>> Not really sure what you mean.  What exactly are you expecting, can you give
>> me an example?
>>
> Right now Docker containers run with either the svirt_lxc_net_t or docker_t types and we've provided pre-existing policies for those type. For example, we provide the svirt_sandbox_file_t type and policy scaffolding so that's it's easy to give Docker containers access to files.
>
> With --selinux-opt=type:X opening up the possibility of running containers as more types, I'm asking if we intend to for our standard policy to provide more "canned" types for users to use or do we expect users to always roll their own?
>
> _Trevor
>
Funny you should ask, since I just wrote an example of how you would do
this for apache.  For the pull request in question.

We could start adding alternate types, but it might be nicer to give
people some tooling to be able to write policy quickly for those new types.

The example I attached does not have all of the capabilities you might
need to run a container as apache.

 sesearch -A -s svirt_apache_t | grep cap
   allow svirt_apache_t svirt_apache_t : process { fork sigchld sigkill
sigstop signull signal getsched setsched getpgid setpgid getcap setcap
getattr setrlimit } ;
   allow svirt_apache_t svirt_apache_t : capability net_bind_service ;

I only give it net_bind_service,  But if the apache process starts as
root, and becomes non root it would probably need setuid and setgid. 

Not sure what else it would need.

If we had a group of examples, I think it would be a nice idea.

In sandbox -X we wrote a few examples, but in a server world this will
quickly expand.




-------------- next part --------------
policy_module(svirt_apache,1.0)
virt_sandbox_domain_template(svirt_apache)

allow svirt_apache_t self:tcp_socket create_stream_socket_perms;
allow svirt_apache_t self:udp_socket create_socket_perms;
corenet_tcp_bind_generic_node(svirt_apache_t)
corenet_udp_bind_generic_node(svirt_apache_t)
corenet_tcp_bind_http_port(svirt_apache_t)
corenet_udp_bind_http_port(svirt_apache_t)

sysnet_dns_name_resolve(svirt_apache_t)


More information about the cockpit-devel mailing list