Matthew, sorry, didn't mean to butcher your name :(
On Thu, Nov 12, 2015 at 10:41 AM, Dmitry Nikishov <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 < >>>>>>> [email protected]> 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 <[email protected]> >>>>>>>> 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 < >>>>>>>>> [email protected]> 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: >>>>>>>>>> [email protected]?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: >>>>>>>>> [email protected]?subject:unsubscribe >>>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> __________________________________________________________________________ >>>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>>> Unsubscribe: >>>>>>>> [email protected]?subject:unsubscribe >>>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> __________________________________________________________________________ >>>>>>> OpenStack Development Mailing List (not for usage questions) >>>>>>> Unsubscribe: >>>>>>> [email protected]?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: >>>>> [email protected]?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?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: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> [email protected]?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
