Open Stack

On Mon, Sep 26, 2016 at 4:32 PM, Jeffrey Zhang <zhang.lei.fly at gmail.com>
wrote:

> Hey Sam,
>
> Yes. world readable is bad. But writable for current running service is
> also bad.
>
> But in nova.conf, the rootwrap_config is configurable. It can be changed
> to a custom file to gain root permission.
>
> # nova.conf
> rootwrap_config = /tmp/rootrwap.conf
>
> # /tmp/rootwrap.conf
> [DEFAULT]
> filters_path = /tmp/rootwrap.conf.d/
>

Sorry Jeffrey, you are mistaken about this. Just because you change the
filters_path means nothing. The filters_path is hardcoded in the
/etc/sudoers.d/nova file. Sudo will not work with any arbitary path you
specify. If you want to make the service config files nova:nova 0400 you
can. Though there is no added benefit in doing this in my opinion. It is
not a bad precaution I suppose, though it may affect some peoples
development cycle with Kolla. I remember I personally changed the config
from inside the running docker container once or twice while testing.

SamYaple


> so, for the file should be
>
> 0640 root:nova nova.conf
>
>
> On Mon, Sep 26, 2016 at 10:43 PM, Sam Yaple <samuel at yaple.net> wrote:
>
>> On Mon, Sep 26, 2016 at 1:18 PM, Jeffrey Zhang <zhang.lei.fly at gmail.com>
>> wrote:
>>
>>> Using the same user for running service and the configuration files is
>>> a danger. i.e. the service running user shouldn't change the
>>> configuration files.
>>>
>>> a simple attack like:
>>> * a hacker hacked into nova-api container with nova user
>>> * he can change the /etc/nova/rootwrap.conf file and
>>> /etc/nova/rootwrap.d file, which he can get much greater authority
>>> with sudo
>>> * he also can change the /etc/nova/nova.conf file to use another
>>> privsep_command.helper_command to get greater authority
>>>     [privsep_entrypoint]
>>>     helper_command=sudo nova-rootwrap /etc/nova/rootwrap.conf
>>> privsep-helper --config-file /etc/nova/nova.conf
>>>
>>> This is not true. The helper command required /etc/sudoers.d/*
>> configuration files to work. So just because it was changed to something
>> else, doesn't mean an attacker could actually do anything to adjust that,
>> considering /etc/nova/rootwrap* is already owned by root. This was fixed
>> early on in the Kolla lifecycle, pre-liberty.
>>
>> Feel free to adjust /etc/nova/nova.conf to root:root, but you won't be
>> gaining any security advantage in doing so, you will be making it worse
>> (see below). I don't know of a need for it to be owned by the service user,
>> other than that is how all openstack things are packaged and those are the
>> permissions in the repo and other deploy tools.
>>
>>
>>> So right rule should be: do not let the service running user have
>>> write permission to configuration files,
>>>
>>> about for the nova.conf file, i think root:root with 644 permission
>>> is enough
>>> for the directory file, root:root with 755 is enough.
>>>
>>
>> So this actually makes it _less_ secure. The 0600 permissions were chosen
>> for a reason.  The nova.conf file has passwords to the DB and rabbitmq. If
>> the configuration files are world readable then those passwords could leak
>> to an unprivileged user on the host.
>>
>>
>>> A related BP[0] and PS[1] is created
>>>
>>> [0] https://blueprints.launchpad.net/kolla/+spec/config-readonly
>>> [1] https://review.openstack.org/376465
>>>
>>> On Sat, Sep 24, 2016 at 11:08 PM, 1392607554 <1392607554 at qq.com> wrote:
>>>
>>>> configuration file owner and permission in container
>>>>
>>>> --
>>>> Regrad,
>>>> zhubingbing
>>>>
>>>> ____________________________________________________________
>>>> ______________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>> enstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Jeffrey Zhang
>>> Blog: http://xcodest.me
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Regards,
> Jeffrey Zhang
> Blog: http://xcodest.me
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160926/1ff32922/attachment-0001.html>