Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151111/67ab5fc6/attachment.html>