Open Stack

Matther,

I totally agree that each daemon should have it's own user which should be
created during installation of the relevant package. Probably I didn't
state this clear enough in the spec.

However, there are security requirements in place that root should not be
used at all. This means that there should be a some kind of maintenance or
system user ('fueladmin'), which would have enough privileges to configure
and manage Fuel node (e.g. run "sudo puppet apply" without password, create
mirrors etc). This also means that certain fuel- packages would be required
to have their files accessible to that user. That's the idea behind having
a package which would create 'fueladmin' user and including it into other
fuel- packages requirements lists.

So this part of the feature comes down to having a non-root user with sudo
privileges and passwordless sudo for certain commands (like 'puppet apply
<path-to-host-only.pp>') for scripting.

On Thu, Nov 12, 2015 at 9:52 AM, Matthew Mosesohn <mmosesohn at mirantis.com>
wrote:

> Dmitry,
>
> We really shouldn't put "user" creation into a single package and then
> depend on it for daemons. If we want nailgun service to run as nailgun
> user, it should be created in the fuel-nailgun package.
> I think it makes the most sense to create multiple users, one for each
> service.
>
> Lastly, it makes a lot of sense to tie a "fuel" CLI user to
> python-fuelclient package.
>
> On Thu, Nov 12, 2015 at 6:42 PM, Dmitry Nikishov <dnikishov at mirantis.com>
> wrote:
>
>> Stanislaw,
>>
>> I agree that this approch would work well. However, does Puppet allow
>> managing capabilities and/or file ACLs? Or can they be easily set up when
>> installing RPM package? (is there a way to specify capabilities/ACLs in the
>> RPM spec file?) This doesn't seem to be supported out of the box.
>>
>> I'm going to research if it is possible to manage capabilities and  ACLs
>> with what we have out of the box (RPM, Puppet).
>>
>> On Wed, Nov 11, 2015 at 4:29 AM, Stanislaw Bogatkin <
>> sbogatkin at mirantis.com> wrote:
>>
>>> Dmitry, I propose to give needed linux capabilities
>>> (like CAP_NET_BIND_SERVICE) to processes (services) which needs them and
>>> then start these processes from non-privileged user. It will give you
>>> ability to run each process without 'sudo' at all with well fine-grained
>>> permissions.
>>>
>>> On Tue, Nov 10, 2015 at 11:06 PM, Dmitry Nikishov <
>>> dnikishov at mirantis.com> wrote:
>>>
>>>> Stanislaw,
>>>>
>>>> I've been experimenting with 'capsh' on the 6.1 master node and it
>>>> doesn't seem to preserve any capabilities when setting SECURE_NOROOT bit,
>>>> even if explicitely told to do so (via either --keep=1 or
>>>> "SECURE_KEEP_CAPS" bit).
>>>>
>>>> On Tue, Nov 10, 2015 at 11:20 AM, Dmitry Nikishov <
>>>> dnikishov at mirantis.com> wrote:
>>>>
>>>>> Bartolomiej, Adam,
>>>>> Stanislaw is correct. And this is going to be ported to master. The
>>>>> goal currently is to reach an agreement on the implementation so that
>>>>> there's going to be a some kinf of compatibility during upgrades.
>>>>>
>>>>> Stanislaw,
>>>>> Do I understand correctly that you propose using something like sucap
>>>>> to launch from root, switch to a different user and then drop capabilities
>>>>> which are not required?
>>>>>
>>>>> On Tue, Nov 10, 2015 at 3:11 AM, Stanislaw Bogatkin <
>>>>> sbogatkin at mirantis.com> wrote:
>>>>>
>>>>>> Bartolomiej, it's customer-related patches, they, I think, have to be
>>>>>> done for 6.1 prior to 8+ release.
>>>>>>
>>>>>> Dmitry, it's nice to hear about it. Did you consider to use linux
>>>>>> capabilities on fuel-related processes instead of just using non-extended
>>>>>> POSIX privileged/non-privileged permission checks?
>>>>>>
>>>>>> On Tue, Nov 10, 2015 at 10:11 AM, Bartlomiej Piotrowski <
>>>>>> bpiotrowski at mirantis.com> wrote:
>>>>>>
>>>>>>> We don't develop features for already released versions… It should
>>>>>>> be done for master instead.
>>>>>>>
>>>>>>> BP
>>>>>>>
>>>>>>> On Tue, Nov 10, 2015 at 7:02 AM, Adam Heczko <aheczko at mirantis.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Dmitry,
>>>>>>>> +1
>>>>>>>>
>>>>>>>> Do you plan to port your patchset to future Fuel releases?
>>>>>>>>
>>>>>>>> A.
>>>>>>>>
>>>>>>>> On Tue, Nov 10, 2015 at 12:14 AM, Dmitry Nikishov <
>>>>>>>> dnikishov at mirantis.com> wrote:
>>>>>>>>
>>>>>>>>> Hey guys.
>>>>>>>>>
>>>>>>>>> I've been working on making Fuel not to rely on superuser
>>>>>>>>> privileges
>>>>>>>>> at least for day-to-day operations. These include:
>>>>>>>>> a) running Fuel services (nailgun, astute etc)
>>>>>>>>> b) user operations (create env, deploy, update, log in)
>>>>>>>>>
>>>>>>>>> The reason for this is that many security policies simply do not
>>>>>>>>> allow root access (especially remote) to servers/environments.
>>>>>>>>>
>>>>>>>>> This feature/enhancement means that anything that currently is
>>>>>>>>> being
>>>>>>>>> run under root, will be evaluated and, if possible, put under a
>>>>>>>>> non-privileged
>>>>>>>>> user. This also means that remote root access will be disabled.
>>>>>>>>> Instead, users will have to log in with "fueladmin" user.
>>>>>>>>>
>>>>>>>>> Together with Omar <gomarivera> we've put together a blueprint[0]
>>>>>>>>> and a
>>>>>>>>> spec[1] for this feature. I've been developing this for Fuel 6.1,
>>>>>>>>> so there
>>>>>>>>> are two patches into fuel-main[2] and fuel-library[3] that can
>>>>>>>>> give you an
>>>>>>>>> impression of current approach.
>>>>>>>>>
>>>>>>>>> These patches do following:
>>>>>>>>> - Add fuel-admin-user package, which creates 'fueladmin'
>>>>>>>>> - Make all other fuel-* packages depend on fuel-admin-user
>>>>>>>>> - Put supervisord under 'fueladmin' user.
>>>>>>>>>
>>>>>>>>> Please review the spec/patches and let's have a discussion on the
>>>>>>>>> approach to
>>>>>>>>> this feature.
>>>>>>>>>
>>>>>>>>> Thank you.
>>>>>>>>>
>>>>>>>>> [0] https://blueprints.launchpad.net/fuel/+spec/fuel-nonsuperuser
>>>>>>>>> [1] https://review.openstack.org/243340
>>>>>>>>> [2] https://review.openstack.org/243337
>>>>>>>>> [3] https://review.openstack.org/243313
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Dmitry Nikishov,
>>>>>>>>> Deployment Engineer,
>>>>>>>>> Mirantis, Inc.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> __________________________________________________________________________
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Adam Heczko
>>>>>>>> Security Engineer @ Mirantis Inc.
>>>>>>>>
>>>>>>>>
>>>>>>>> __________________________________________________________________________
>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> __________________________________________________________________________
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> __________________________________________________________________________
>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dmitry Nikishov,
>>>>> Deployment Engineer,
>>>>> Mirantis, Inc.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Dmitry Nikishov,
>>>> Deployment Engineer,
>>>> Mirantis, Inc.
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>>
>>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>> Dmitry Nikishov,
>> Deployment Engineer,
>> Mirantis, Inc.
>>
>> __________________________________________________________________________
>> 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
>>
>>
>
> __________________________________________________________________________
> 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
>
>


-- 
Dmitry Nikishov,
Deployment Engineer,
Mirantis, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151112/ca86e5fe/attachment.html>