[openstack-dev] [kolla] the user in container should NOT have write permission for configuration file

Steven Dake (stdake) stdake at cisco.com
Mon Sep 26 15:40:34 UTC 2016


Sam is correct here.  This is the why behind the how ☺

Regards
-steve

From: Sam Yaple <samuel at yaple.net>
Reply-To: "sam at yaple.net" <sam at yaple.net>, "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Date: Monday, September 26, 2016 at 7:43 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [kolla] the user in container should NOT have write permission for configuration file

On Mon, Sep 26, 2016 at 1:18 PM, Jeffrey Zhang <zhang.lei.fly at gmail.com<mailto: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<mailto: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.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Regards,
Jeffrey Zhang
Blog: http://xcodest.me<http://xcodest.me/>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160926/505c6e28/attachment.html>


More information about the OpenStack-dev mailing list