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 <dnikis...@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 <dnikis...@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 < >> sbogat...@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 < >>> bpiotrow...@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 <ahec...@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 < >>>>> dnikis...@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-requ...@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-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 >>>> >>>> >>> >>> >>> __________________________________________________________________________ >>> 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 >>> >>> >> >> >> -- >> Dmitry Nikishov, >> Deployment Engineer, >> Mirantis, Inc. >> > > > > -- > Dmitry Nikishov, > Deployment Engineer, > Mirantis, Inc. > > __________________________________________________________________________ > 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