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 <dnikis...@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 < > sbogat...@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 <dnikis...@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 < >>> dnikis...@mirantis.com> wrote: >>> >>>> Matthew, >>>> >>>> sorry, didn't mean to butcher your name :( >>>> >>>> On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov < >>>> dnikis...@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 < >>>>> mmoses...@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 < >>>>>> dnikis...@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 < >>>>>>> sbogat...@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 < >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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-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