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

2016-09-26 Thread Sam Yaple 
On Mon, Sep 26, 2016 at 4:32 PM, Jeffrey Zhang 
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  wrote:
>
>> On Mon, Sep 26, 2016 at 1:18 PM, Jeffrey Zhang 
>> 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

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

2016-09-26 Thread Sam Yaple 
On Mon, Sep 26, 2016 at 3:03 PM, Christian Berendt <
bere...@betacloud-solutions.de> wrote:

> > On 26 Sep 2016, at 16:43, Sam Yaple  wrote:
> >
> > 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.
>
> Confirmed. Please do not make configuration files world readable.
>
> We use volumes for the configuration file directories. Why do we not
> simply use read only volumes? This way we do not have to touch the current
> implementation (files are owned by the service user with 0600 permissions)
> and can make the configuration files read only.
>

This is already done. When I first setup the config bind mounting we did
make sure it was read only. See [1]. The way configs work in Kolla is the
files from that readonly bind mount are copied into the appropriate
directory in the container on container startup.

[1]
https://github.com/openstack/kolla/blob/b1f986c3492faa2d5386fc7baabbd6d8e370554a/ansible/roles/nova/tasks/start_compute.yml#L11

>
> Christian.
>
> __
> 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
>
>
__
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

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

2016-09-26 Thread Jeffrey Zhang 
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  wrote:

> On Mon, Sep 26, 2016 at 1:18 PM, Jeffrey Zhang 
> 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

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

2016-09-26 Thread Jeffrey Zhang 
On Mon, Sep 26, 2016 at 11:03 PM, Christian Berendt <
bere...@betacloud-solutions.de> wrote:

> Confirmed. Please do not make configuration files world readable.
>
> We use volumes for the configuration file directories. Why do we not
> simply use read only volumes? This way we do not have to touch the current
> implementation (files are owned by the service user with 0600 permissions)
> and can make the configuration files read only.
>

​what do you mean here?

use /var/lib/kolla/config_file/nova.conf file directly rathen then copy it
to /etc/nova/nova.conf
or mount the nova.conf to /etc/nova.conf in container directly?

​



-- 
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

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

2016-09-26 Thread Steven Dake (stdake) 
Sam is correct here.  This is the why behind the how ☺

Regards
-steve

From: Sam Yaple 
Reply-To: "s...@yaple.net" , "OpenStack Development Mailing 
List (not for usage questions)" 
Date: Monday, September 26, 2016 at 7:43 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

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 
> 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.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

__
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

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

2016-09-26 Thread Christian Berendt 
> On 26 Sep 2016, at 16:43, Sam Yaple  wrote:
> 
> 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.

Confirmed. Please do not make configuration files world readable.

We use volumes for the configuration file directories. Why do we not simply use 
read only volumes? This way we do not have to touch the current implementation 
(files are owned by the service user with 0600 permissions) and can make the 
configuration files read only.

Christian.


signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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

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

2016-09-26 Thread Sam Yaple 
On Mon, Sep 26, 2016 at 1:18 PM, Jeffrey Zhang 
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.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
>
>
__
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

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

2016-09-26 Thread Jeffrey Zhang 
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

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.

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.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