In fact, we have
class CommandFilter(object):
"""Command filter only checking that the 1st argument matches exec_path"""
def __init__(self, exec_path, run_as, *args):
self.exec_path = exec_path
self.run_as = run_as
self.args = args
def match(self, userargs):
"""Only check that the first argument (command) matches exec_path"""
return os.path.basename(self.exec_path) == userargs[0]
The match method will check if the wanted command required by our quantum code has the same base name of one defined in filter file.
But most of the sub classes redefined this method and has no such check at all.
So if we add the check into the filters, this bug also will not occur.
By not checking the basename of wanted commands with the one defined in filter files, filter files can point to any other command that is actually executed.
Thanks
Yong Sheng Gong
-----Dan Wendlandt <[email protected]> wrote: -----
To: Yong Sheng Gong/China/IBM@IBMCN
From: Dan Wendlandt <[email protected]>
Date: 09/25/2012 08:42AM
Cc: [email protected], quantum-core <[email protected]>
Subject: Re: About Bug #1055384 : dnsmasq - Stderr: 'Option "-no-hosts" is unknown, try "ip -help
From: Dan Wendlandt <[email protected]>
Date: 09/25/2012 08:42AM
Cc: [email protected], quantum-core <[email protected]>
Subject: Re: About Bug #1055384 : dnsmasq - Stderr: 'Option "-no-hosts" is unknown, try "ip -help
Hi Yong,
Does gary's patch address your concern:
https://review.openstack.org/#/c/13572/4 ?
It seems like the introduction of the DnsmasqNetnsFilter properly
enforces that the only command run within the netns is dnsmasq, unless
i'm misunderstanding the patch.
dan
On Mon, Sep 24, 2012 at 4:03 PM, Yong Sheng Gong <[email protected]> wrote:
>
> Hi Dan, Garyk,
> I think the root cause is:
> ip_exec_dnsmasq: DnsmasqFilter, /sbin/ip, root
> dnsmasq: DnsmasqFilter, /sbin/dnsmasq, root
> dnsmasq_usr: DnsmasqFilter, /usr/sbin/dnsmasq, root
>
> most of our filters do not match the needed command with the command defined
> in rootwrapper filter files.
>
> For this bug, because DnsmasqFilter does not try to match the wanted dnsmasq
> with the /sbin/ip defined in dhcp.filters file, we select the first rule.
>
> It seems we will allow the user to specify any command to run in rootwrapper
> filter files. For example, I can define ip_exec_dnsmasq: DnsmasqFilter,
> /path/to/anyprogramtorun, root although our quantum is trying to run
> dnsmasq, but we will match and change to run anyprogramtorun.
>
> security concern?
> Yong Sheng Gong
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Does gary's patch address your concern:
https://review.openstack.org/#/c/13572/4 ?
It seems like the introduction of the DnsmasqNetnsFilter properly
enforces that the only command run within the netns is dnsmasq, unless
i'm misunderstanding the patch.
dan
On Mon, Sep 24, 2012 at 4:03 PM, Yong Sheng Gong <[email protected]> wrote:
>
> Hi Dan, Garyk,
> I think the root cause is:
> ip_exec_dnsmasq: DnsmasqFilter, /sbin/ip, root
> dnsmasq: DnsmasqFilter, /sbin/dnsmasq, root
> dnsmasq_usr: DnsmasqFilter, /usr/sbin/dnsmasq, root
>
> most of our filters do not match the needed command with the command defined
> in rootwrapper filter files.
>
> For this bug, because DnsmasqFilter does not try to match the wanted dnsmasq
> with the /sbin/ip defined in dhcp.filters file, we select the first rule.
>
> It seems we will allow the user to specify any command to run in rootwrapper
> filter files. For example, I can define ip_exec_dnsmasq: DnsmasqFilter,
> /path/to/anyprogramtorun, root although our quantum is trying to run
> dnsmasq, but we will match and change to run anyprogramtorun.
>
> security concern?
> Yong Sheng Gong
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
