Cockpit as a privileged container?

Stef Walter stefw at redhat.com
Fri Aug 8 15:57:03 UTC 2014


On 06.08.2014 15:37, Daniel J Walsh wrote:
> 
> 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.

So to summarize this... Do you know of anyone who's tried this stuff out
with Cockpit? Interested in the results in any case, and open to patches
that help make it work.

Stef



More information about the cockpit-devel mailing list