On Fri Feb 13 2015 at 5:45:36 PM Eric Windisch <e...@windisch.us> wrote:
> ᐧ
>
>>
>> from neutron.agent.privileged.commands import ip_lib as priv_ip
>> def foo():
>> # Need to create a new veth interface pair - that usually
>> requires root/NET_ADMIN
>> priv_ip.CreateLink('veth', 'veth0', peer='veth1')
>>
>> Because we now have elevated privileges directly (on the privileged
>> daemon side) without having to shell out through sudo, we can do all sorts
>> of nicer things like just using netlink directly to configure networking.
>> This avoids the overhead of executing subcommands, the ugliness (and
>> danger) of generating command lines and regex parsing output, and make us
>> less reliant on specific versions of command line tools (since the kernel
>> API should be very stable).
>>
>
> One of the advantages of spawning a new process is being able to use flags
> to clone(2) and to set capabilities. This basically means to create
> containers, by some definition. Anything you have in a "privileged daemon"
> or privileged process ideally should reduce its privilege set for any
> operation it performs. That might mean it clones itself and executes
> Python, or it may execvp an executable, but either way, the new process
> would have less-than-full-privilege.
>
> For instance, writing a file might require root access, but does not need
> the ability to load kernel modules. Changing network interfaces does not
> need access to the filesystem, no more than changes to the filesystem needs
> access to the network. The capabilities and namespaces mechanisms resolve
> these security conundrums and simplify principle of least privilege.
>
Agreed wholeheartedly, and I'd appreciate your thoughts on how I'm using
capabilities in this change. The privsep daemon limits itself to a
particular set of capabilities (and drops root). The assumption is that
most OpenStack services commonly need the same small set of capabilities to
perform their duties (neutron -> net_admin+sys_admin for example), so it
makes sense to reuse the same privileged process.
If we have a single service that somehow needs to frequently use a broad
swathe of capabilities then we might want to break it up further somehow
between the different internal aspects (multiple privsep helpers?) - but is
there such a case? There's also no problems with mixing privsep for
frequent operations with the existing sudo/rootwrap approach for
rare/awkward cases.
- Gus
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
