Open Stack

On 02/04/2015 01:13 PM, Clint Byrum wrote:
> Excerpts from Tristan Cacqueray's message of 2015-02-04 09:02:19 -0800:
>> On 02/04/2015 06:57 AM, Daniel P. Berrange wrote:
>>> (4) I think that ultimately we need to ditch rootwrap and provide a proper
>>> privilege separated, formal RPC mechanism for each project.
>>>
>>> eg instead of having a rootwrap command, or rootwrap server attempting
>>> to validate safety of
>>>
>>>     qemu-img create -f qcow2 /var/lib/nova/instances/instance00001/disk.qcow2
>>>
>>> we should have a  nova-compute-worker daemon running as root, that accepts
>>> an RPC command from nova-compute running unprivileged. eg
>>>
>>>     CreateImage("instane0001", "qcow2", "disk.qcow")
>>>
>>> This immediately makes it trivial to validate that we're not trying to
>>> trick qemu-img into overwriting some key system file.
>>>
>>> This is certainly alot more work than trying to patchup rootwrap, but
>>> it would provide a level of security that rootwrap can never achieve IMHO.
>>>
>>
>> This 4th idea sounds interesting, though we are assuming this new service
>> running as root would be exempt of bug, especially if it uses the same
>> libraries as non-root services... For example a major bug in python would
>> give attacker direct root access while the rootwrap solution would in
>> theory keep the intruder at the sudo level...
>>
> 
> I don't believe that anyone assumes the new service would be without
> bugs. 

I meant less bug than another solution. Such RPC service daemon will
eventually requires quite some code to be robust, which could lead to
more bugs.


> But just like the OpenSSH team saw years ago, privilege separation
> means that you can absolutely know what is running as root, and what is
> not. So when you decide to commit your resources to code audits, you
> _start_ with the things that run with elevated privileges.
> 

Not quite sure to follow here... OpenSSH is using privilege separation after
authentication, e.g. the root-based process is doing the authentication while
the external data processing is done through an unprivileged process.

If I understand correctly Daniel's solution (4), it's to have a semantic on the
privileged actions to avoid mis-usage (like inject command in a sudo call).

Thus if we want to emulate OpenSSH design, the rpc call would also need to
carry authentication data in order to prevent unwanted activity. And the
rpc daemon would then need to enforce some kind of acl/policy.

The amount of code to be audited could arguably be higher with such design.


>>
>> For completeness, I'd like to propose a more long-term solution:
>>
>> (5) Get ride of root! Seriously, OpenStack could support security mechanism
>> like SELinux or AppArmor in order to properly isolate service and let them
>> run what they need to run.
>>
>> For what it worth, the underlying issue here is having a single almighty super
>> user: root and thus we should, at least, consider solution that remove the
>> need of such powers (e.g. kernel module loading, ptrace or raw socket).
>>
> 
> We don't need a security module to drop all of those capabilities
> entirely and run as a hobbled root user. By my measure, this process for
> nova-compute would only need CAP_NET_ADMIN, CAP_SYS_ADMIN and CAP_KILL.
> These capabilities can be audited per-agent and even verified as needed
> simply by running integration tests without each one to see what breaks.
>
Capabilities might be a candidate as well, but they don't cover every cases
and lack granularity...

SECCOMP filters might be good enough too.


>> Beside, as long as sensitive process are not contained at the system level,
>> the attack surface for a non-root user is still very wide (e.g. system calls,
>> setuid binaries, ipc, ...)
>>
>>
>> While this might sounds impossible to implement upstream because it's too
>> vendor specific or just because of other technicals difficulties,
>> I guess it still deserves a mention in this thread.
>>
> 
> I think OpenStack can do its part by making privilege separation a
> reality for the security sensitive parts of OpenStack, and that will
> ease pressure to implement strong controls in any security modules the
> Linux distros ship with.
> 
That would be a great step forward indeed. Having some kind of privilege
separation would surely help a lot to properly configure security modules.

Regards,
Tristan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150205/0b2f1ced/attachment.pgp>