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 <sam...@yaple.net> wrote: > On Mon, Sep 26, 2016 at 1:18 PM, Jeffrey Zhang <zhang.lei....@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 <1392607...@qq.com> wrote: >> >>> configuration file owner and permission in container >>> >>> -- >>> Regrad, >>> zhubingbing >>> >>> ____________________________________________________________ >>> ______________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev