[ovs-discuss] [ovs-dev] Somebody making --user and dpdk compatible again?

Wed Jan 27 05:12:01 UTC 2016

On 26 January 2016 at 11:06, Aaron Conole <aconole at redhat.com> wrote:

> I should be on the discuss mailing list. Let me just state a big _YES_ I
> am working on this problem from multiple facets.

> Ansis Atteka <aatteka at vmware.com> writes:
> > Hi,
> >
> >
> > In fact I think we should remove any Discretionary Access Control
> > (--user) and ?implement proper Mandatory Access Control (SELinux and
> > Apparmor) support. Unless anyone can bring up a good case to keep
> > and/or extend DAC feature in OVS.
>
> There was a reason to implement it in the first place, yes? I don't know

I am considering to abandon the outstanding patch where --user flag would
be automatically passed from init.d (deb) and systemd (rpm) when starting
ovs-* daemons.

However, this does not necessarily imply that --user flag should be removed
from ovs-* processes themselves. However, I would like to know how you
would be using this --user flag if debian and rpm packaging patch will be
abandoned?

if NetBSD has MAC, but it is still listed as a supported platform. I
> know there's some kind of MAC in FreeBSD, but I don't know much else
> from that perspective.
>

Sorry, if I wasn't specific enough. With "Open vSwitch DAC support" I meant
a feature where ovs-* processes downgrade themselves from "root" to
"openvswitch" user. Basically Open vSwitch self-confines itself.

However, I believe in this thread "Open vSwitch DAC support" is meant as a
feature where *other processes that are confined under too restricted user*
could still connect to Open vSwitch Unix Domain Sockets?

I would suggest to look on these two as separate features. And, yes, first
feature partially solves second if you can/dare to put your daemon's user
into "openvswitch" group.

> > The link you posted seems to mention Apparmor as the root cause for
> > Permission Denied issue and not File Access bits - however this
> > contradicts wit the fact that chown helped you to get rid of the
> > error.
>
> I have a bug open to resolve this from my side, and posted patches to
> get by the first hurdle
> (http://openvswitch.org/pipermail/dev/2015-December/063565.html and
> http://openvswitch.org/pipermail/dev/2015-December/063567.html) - but
> having DPDK initialize once and then drop privileges is my ultimate goal.
>

I have thought about DAC a lot lately and will share my thoughts. Overall I
see three DAC models:
1. start process as restricted user from the beginning
2. start process as root and then downgrade to a restricted user
3. start process as root and then spawn another process that runs under
restricted user and makes requests to root process

First DAC model is simple. However, it is not feasible for Open vSwitch,
because Open vSwitch needs access to privileged resources (e.g Open vSwitch
needs to open NetLink socket). This model works really well for simple web
servers that run on ports >1024.

Second DAC model starts to get more complex (this is in fact what current
--user flag does). However, if Open vSwitch after user-downgrade needs
again access to privileged resources then it means that ovs-vswitchd needs
to be restarted on certain configuration changes. This model works better
for processes that can anticipate at the beginning all the privileged
resources that it needs for its whole life time, for example, DHCP server.

Third DAC model is even more complex, because it requires some sort of IPC
between the root and non-root process to delegate privileged work. And it
is less secure than the second model, because it still runs some code as
root. I think OVS falls under this model.

The problem here is that DAC requires us to mix Access Control related code
with Domain Logic (in the same C files). MAC is nicer that all the Access
Control policy is decoupled from the Domain Logic. Where I am going with
this is that perhaps second and third DAC model gets so complicated that we
have reached tipping point where benefits of MAC outweigh those of DAC?

However, I do see other side of the story:
1. DAC (Linux User:Group + Linux capabilities) are more uniform between
Unix-type distributions.
2. SELinux requires special file system that supports SELinux labels.
However, this does not apply to Apparmor.
3. DAC has been around for way longer so there are people who understand it
better. However, RHEL, CentOS and Fedora is embracing SELinux forcing
everyone to use it. Perhaps we should too?
4. MAC support for Open vSwitch has been quite poor so far and I understand
skepticism when I say "Let's make SELinux to work". However, I imagined
that we might get better chance of fixing this, if we would have our own
SELinux policy in the Open vSwitch GIT repository that users can use right
away. I sent initial patch (
http://comments.gmane.org/gmane.network.openvswitch.devel/57860). It does
not solve all the "Permission Denied" issues yet though and there might be
unforeseen issue also with this approach.
5. Am I missing anything else?

Also, there is "middle path" to have DAC and MAC support for OVS.

>
> > To verify this can you do:
> >
> > 1. ps -Af for both processes that create and connect to the sokcet.
> >
> > 2. ls -la for the socket that is getting permission denied?
> >
> >
> > Thanks,
> >
> > Ansis
> >
> > ________________________________
> > From: discuss <discuss-bounces at openvswitch.org> on behalf of Christian
> > Ehrhardt <christian.ehrhardt at canonical.com>
> > Sent: Monday, January 25, 2016 10:32 PM
> > To: dev at openvswitch.org; discuss at openvswitch.org
> > Subject: [ovs-discuss] Somebody making --user and dpdk compatible again?
> >
> > Hi,
> > to avoid missing another work already been done (and google didn't
> > find me anything).
> > Is there already work going on to get --user and dpdk working together?
> > (see http://openvswitch.org/pipermail/dev/2015-September/060382.html)
>
> I haven't posted anything yet for the initialization piece, but I am
> working on this. The problem is, DPDK wants to do things, but we may
> have already dropped privileges (among other issues).
>
> > Background:
> > While setting up a vhost_user based ovs-dpdk setup I'm struggling to
> > get access to the vhost user sockets from qemu/kvm due to permission
> > issues.
> > Various mailing list posts like
> > (http://openvswitch.org/pipermail/discuss/2015-August/018553.html)
> > indicate to change the user running OVS, since the sockets are
> > defaulting to process user/group.
> > To run OVS as different user --user seems to be the preferred way.
> > But as linked above, --user has other issues with DPDK and therefore
> > is mutually exclusive for now.
> >
> > I was able to fix the permission issue with some chown/chmod, but I
> > wonder if there would be cleaner way to do so at some point. Maybe
> > eventually the approach is totally different anyway (like only
> > specifying :group for the sockets to be created). But I wondered if
> > that old mail thread is still worked on by somebody atm.
>
> See the patches I linked earlier. This is my first step - get vhostuser
> configurable so that a flexible permissions system can be used (ie: why
> not have a :vhost group on the system to which ovs and qemu belong).
>
> I'll be reposting them once I hear back on the dpdk intialization series.
>
> > Christian Ehrhardt
> > Software Engineer, Ubuntu Server
> > Canonical Ltd
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/dev
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20160126/8dac8ff4/attachment-0002.html>