Open Stack

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/

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.openstack.org?subject:unsubscrib
>> e
>> 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:unsubscribe
> 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/20160927/97130f5c/attachment.html>