[ovs-dev] [PATCHv2 branch2-4] rhel: provide our own SELinux custom policy package

Ansis Atteka aatteka at nicira.com
Mon Jan 25 00:22:14 UTC 2016


On Thu, Jan 21, 2016 at 2:09 PM, Russell Bryant <russell at ovn.org> wrote:
> On 01/20/2016 05:59 PM, Ansis Atteka wrote:
>> CentOS, RHEL and Fedora distributions ship with their own Open vSwitch
>> SELinux policy that is too strict and prevents Open vSwitch to work
>> normally out of the box.
>>
>> As a solution, this patch introduces a new package which will "loosen"
>> up "openvswitch_t" SELinux domain so that Open vSwitch could operate
>> normally.
>>
>> Intended use-cases of this package are:
>> 1. to allow users to install newer Open vSwitch on already released Fedora,
>> RHEL and CentOS distributions where the default Open vSwitch SELinux policy
>> that shipped with the corresponding Linux distribution is not up to date
>> and did not anticipate that a newer Open vSwitch version might need to
>> invoke new system calls or need to access certain system resources that
>> it did not before; And
>> 2. to provide alternative means through which Open vSwitch developers
>> can proactively fix SELinux related policy issues without waiting for
>> corresponding Linux distribution maintainers to update their central
>> Open vSwitch SELinux policy.
>>
>> This patch was tested on Fedora 23 and CentOS 7. I verified that now
>> on Fedora 23 Open vSwitch can create a NetLink socket; and that I did
>> not see following error messages:
>>
>> vlog|INFO|opened log file /var/log/openvswitch/ovs-vswitchd.log
>> ovs_numa|INFO|Discovered 2 CPU cores on NUMA node 0
>> ovs_numa|INFO|Discovered 1 NUMA nodes and 2 CPU cores
>> reconnect|INFO|unix:/var/run/openvswitch/db.sock: connecting...
>> reconnect|INFO|unix:/var/run/openvswitch/db.sock: connected
>> netlink_socket|ERR|fcntl: Permission denied
>> dpif_netlink|ERR|Generic Netlink family 'ovs_datapath' does not exist.
>>                  The Open vSwitch kernel module is p robably not loaded.
>> dpif|WARN|failed to enumerate system datapaths: Permission denied
>> dpif|WARN|failed to create datapath ovs-system: Permission denied
>>
>> I did not test all Open vSwitch features so there still could be some
>> OVS configuration that would get "Permission denied" errors.
>>
>> Since, Open vSwitch daemons on Ubuntu 15.10 by default run under "unconfined"
>> SELinux domain, then there is no need to create a similar debian package
>> for Ubuntu, because it works on default Ubuntu installation.
>>
>> Signed-Off-By: Ansis Atteka <aatteka at nicira.com>
>
> It's certainly unfortunate that this is necessary, but I understand the
> practical motivation behind it.
>
> One way to look at this could be that it's a fork from distro-provided
> systemd policy.  I'd really like to see something that makes me feel
> good that we're trying our hardest to minimize divergence as much as
> possible.  For every policy addition, it would be nice to see something
> like:

I completely agree that we should upstream our Open vSwitch SELinux
policy changes to
https://github.com/TresysTechnology/refpolicy-contrib.git. I will send
them an introduction email to see what kind of work-flow they would
suggest for us so that our policy would not not diverge from theirs.


>
> 1) A link to a distro bug report (or reports) that show that this policy
> addition is needed locally until the distro applies a policy update.
>
> 2) If it's a policy included in newer versions of a distro, and this is
> only needed on older versions of the distro where the changes won't get
> applied, it'd be nice to have that documented somehow.

Good points, I believe this should be mentioned in INSTALL.SELinux.md
"Contributing SELinux policy patches" section. We should also mention
what kind of SELinux policy changes we would not accept in OVS
repository, because they would anyway be most likely rejected in the
upstream refpolicy-contrib.git repository.

>
> Honestly, this stuff isn't easy to get right, and I'd really rather

I agree that Mandatory Access Control (SELinux and Apparmor) is not
easy to get right. However, the same thing applies to Discretionary
Access Control (i.e. Linux Users:Groups + Linux capabilities). This
opens a question - whether we should provide any Access Control
solution to our users in the first place or put this burden completely
on sysadmin's shoulders?

I will name few cons of Discretionary Access Control (Linux user:group):
1. it is hard to audit DAC because DAC policy is mixed with the actual
program's code (e.g. setreuid, chown, chmod and other calls are inside
the program itself).
2. it becomes very hard to interact with other daemons that still run
as root (e.g. Open vSwitch can't create a configuration file for
strongSwan/raccoon that still runs as root).
3. if process has to run even for a brief moment as a root then this
piece of code needs to be very carefully audited, because it can
loosen up DAC policy (e.g. dnsmasq --user nobody
--log-facility=/etc/yum.repos.d/nobody.repo would create a file owned
by "nobody" with garbage in a place where only root was supposed to
create files. To exploit this further you would just need another
process that runs as nobody to change contents of this file to
something meaningful.)
4. for DAC to work together with MAC/SELinux the SELinux policy anyway
needs to be loosened up to allow chown, chmod and other calls.

Where I am going with this is that I see SELinux as superior solution
to DAC. Perhaps DAC has been around for longer and that is the reason
why people find it easier to use?


> leave it to the systemd policy experts as much as possible.  Seeing that
> systemd policy maintainers have acked the changes in some way would make
> me feel better.

I would argue the opposite - since it is not easy to get this stuff
right and it is not working properly on major Linux distributions out
of the box, then we should actually provide alternative SELinux policy
to Open vSwitch users so that they would not be inclined to disable
SELinux.

Here is a thought experiment - imagine that Open vSwitch does not work
out of the box on RHEL, Fedora or CentOS. This means that Open vSwitch
users currently have following choices:
1. Disable whole SELinux on their system.
2. Disable SELinux policy only for the Open vSwitch.
3. Let the sysadmin set up Open vSwitch SELinux policy manually on the
localhost.
4. Let the sysadmin just deal with the fact that certain (or all) Open
vSwitch functionality does not work.

Even if for the Open vSwitch project we would write the worst possible
SELinux policy we could not do worse than solution #1. We could do
worse than solution #2, only if openvswitch policy "unconfines"
non-ovs related things. #3 assumes that sysadmin has to come up with
his own SELinux policy - this solution would be safer only if sysadmin
really knows how SELinux needs to be configured for Open vSwitch.
Option #4 most likely would drive away Open vSwitch users.

P.S.
I have been looking into SELinux only for the last 2 months so it
could be that I am oversimplifying some things. This is the reason why
I thought to pack this SELinux policy into another optional package.



More information about the dev mailing list