On Mon, Sep 26, 2016 at 4:32 PM, Jeffrey Zhang <zhang.lei....@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 <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.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-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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