Open Stack

Dmitry, I just propose the way I think is right, because it's strange
enough - install package from *.deb file and then set any privileges to it
by third-party utility. Set permissions for app now mostly managed by
post-install scripts. Moreover - if it isn't - it should, cause if you set
capabilities by puppet there always will be a gap between installation and
setting permissions, so you will must bound package installation process
with setting permissions by puppet - other way you will have no way to use
your app.

Setting setuid bits on apps is not a good idea - it is why linux
capabilities were introduced.

On Fri, Nov 20, 2015 at 6:40 PM, Dmitry Nikishov <dnikishov at mirantis.com>
wrote:

> Stanislaw,
>
> In my opinion the whole feature shouldn't be in the separate package
> simply because it will actually affect the code of many, if not all,
> components of Fuel.
>
> The only services whose capabilities will have to be managed by puppet are
> those, which are installed from upstream packages (e.g. atop) -- not built
> from fuel-* repos.
>
> Supervisord doesn't seem to use Linux capabilities, id does setuid
> instead:
> https://github.com/Supervisor/supervisor/blob/master/supervisor/options.py#L1326
>
> On Fri, Nov 20, 2015 at 1:07 AM, Stanislaw Bogatkin <
> sbogatkin at mirantis.com> wrote:
>
>> Dmitry, I mean whole feature.
>> Btw, why do you want to grant capabilities via puppet? It should be done
>> by post-install package section, I believe.
>>
>> Also I doesn't know if supervisord can bound process capabilities like
>> systemd can - we could use this opportunity too.
>>
>> On Thu, Nov 19, 2015 at 7:44 PM, Dmitry Nikishov <dnikishov at mirantis.com>
>> wrote:
>>
>>> My main concern with using linux capabilities/acls on files is actually
>>> puppet support or, actually, the lack of it. ACLs are possible AFAIK, but
>>> we'd need to write a custom type/provider for capabilities. I suggest to
>>> wait with capabilities support till systemd support.
>>>
>>> On Tue, Nov 17, 2015 at 9:15 AM, Dmitry Nikishov <dnikishov at mirantis.com
>>> > wrote:
>>>
>>>> Stanislaw, do you mean the whole feature, or just a user? Since feature
>>>> would require actually changing puppet code.
>>>>
>>>> On Tue, Nov 17, 2015 at 5:08 AM, Stanislaw Bogatkin <
>>>> sbogatkin at mirantis.com> wrote:
>>>>
>>>>> Dmitry, I believe it should be done via package spec as a part of
>>>>> installation.
>>>>>
>>>>> On Mon, Nov 16, 2015 at 8:04 PM, Dmitry Nikishov <
>>>>> dnikishov at mirantis.com> wrote:
>>>>>
>>>>>> Hello folks,
>>>>>>
>>>>>> I have updated the spec, please review and share your thoughts on it:
>>>>>> https://review.openstack.org/#/c/243340/
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> On Thu, Nov 12, 2015 at 10:42 AM, Dmitry Nikishov <
>>>>>> dnikishov at mirantis.com> wrote:
>>>>>>
>>>>>>> Matthew,
>>>>>>>
>>>>>>> sorry, didn't mean to butcher your name :(
>>>>>>>
>>>>>>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov <
>>>>>>> dnikishov at mirantis.com> wrote:
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151120/c98b4337/attachment.html>