On 2/4/15, 10:24 AM, "Daniel P. Berrange" wrote:
>On Wed, Feb 04, 2015 at 09:10:06AM -0800, James E. Blair wrote:
>> Thierry Carrez writes:
>>
>> > You make a good point when you mention "traditional distro" here. I
>> > would argue that containers are slightly changing the rules of the
>> >
On Thu, 2015-02-05 at 08:27 -0500, Tristan Cacqueray wrote:
> Thus if we want to emulate OpenSSH design, the rpc call would also
> need to
> carry authentication data in order to prevent unwanted activity. And
> the
> rpc daemon would then need to enforce some kind of acl/policy.
Sounds a lot like
On 02/04/2015 01:13 PM, Clint Byrum wrote:
> Excerpts from Tristan Cacqueray's message of 2015-02-04 09:02:19 -0800:
>> On 02/04/2015 06:57 AM, Daniel P. Berrange wrote:
>>> (4) I think that ultimately we need to ditch rootwrap and provide a proper
>>> privilege separated, formal RPC mechanism for
Hi Daniel,
> > Yes, there's some semantic meaning at that level. But this level already
> > exists at the current rootwrap caller site, too - and if that one can be
> > tricked to do something against "image.img & rm -rf /", then the additional
> > layer can be tricked, too.
>
> No, that is re
On 5 February 2015 at 03:33, Monty Taylor wrote:
> On 02/04/2015 06:57 AM, Daniel P. Berrange wrote:
> to manage VMs on a laptop - you're going to use virtualbox or
> virt-manager. You're going to use nova-compute to manage compute hosts
> in a cloud - and in almost all circumstances the only
Excerpts from Daniel P. Berrange's message of 2015-02-04 03:57:53 -0800:
> On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote:
> > The first one is performance -- each call would spawn a Python
> > interpreter which would then call the system command. This was fine when
> > there were j
Excerpts from Tristan Cacqueray's message of 2015-02-04 09:02:19 -0800:
> On 02/04/2015 06:57 AM, Daniel P. Berrange wrote:
> > On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote:
> >> What solutions do we have ?
> >>
> >> (1) we could get our act together and audit and fix those filter
On Wed, Feb 04, 2015 at 09:10:06AM -0800, James E. Blair wrote:
> Thierry Carrez writes:
>
> > You make a good point when you mention "traditional distro" here. I
> > would argue that containers are slightly changing the rules of the
> > don't-run-as-root game.
> >
> > Solution (2) aligns pretty
On Wed, Feb 04, 2015 at 06:05:16PM +0100, Philipp Marek wrote:
> > > > (4) I think that ultimately we need to ditch rootwrap and provide a
> > > > proper
> > > > privilege separated, formal RPC mechanism for each project.
> > > ...
> > > > we should have a nova-compute-worker daemon running as ro
> > > (4) I think that ultimately we need to ditch rootwrap and provide a proper
> > > privilege separated, formal RPC mechanism for each project.
> > ...
> > > we should have a nova-compute-worker daemon running as root, that accepts
> > > an RPC command from nova-compute running unprivileged. eg
Thierry Carrez writes:
> You make a good point when you mention "traditional distro" here. I
> would argue that containers are slightly changing the rules of the
> don't-run-as-root game.
>
> Solution (2) aligns pretty well with container-powered OpenStack
> deployments -- running compute nodes a
On 02/04/2015 06:57 AM, Daniel P. Berrange wrote:
> On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote:
>> What solutions do we have ?
>>
>> (1) we could get our act together and audit and fix those filter
>> definitions. Remove superfluous usage of root rights, make use of
>> advanced
On Wed, Feb 04, 2015 at 05:52:12PM +0100, Philipp Marek wrote:
> Here are my 2¢.
>
> > > >> (1) we could get our act together and audit and fix those filter
> > > >> definitions. Remove superfluous usage of root rights, make use of
> > > >> advanced filters for where we actually need them. We have
Here are my 2¢.
> > >> (1) we could get our act together and audit and fix those filter
> > >> definitions. Remove superfluous usage of root rights, make use of
> > >> advanced filters for where we actually need them. We have been preaching
> > >> for that at many many design summits. This is a lo
On 2015-02-04 18:38:16 +0200 (+0200), Duncan Thomas wrote:
> If I'm reading that correctly, it does not help with the filtering issues at
> all, since it needs exactly the same kind of filter. Daniel explained the
> concept far better than I.
I didn't mean to imply that it does, merely that it fit
On Wed, Feb 04, 2015 at 06:38:16PM +0200, Duncan Thomas wrote:
> If I'm reading that correctly, it does not help with the filtering issues
> at all, since it needs exactly the same kind of filter. Daniel explained
> the concept far better than I.
Yep, the only thing rootwrap daemon mode does is to
On 2015-02-04 11:58:03 +0100 (+0100), Thierry Carrez wrote:
[...]
> The second problem is the quality of the filter definitions. Rootwrap is
> a framework to enable isolation. It's only as good as the filters each
> project defines. Most of them rely on CommandFilters that do not check
> any argume
If I'm reading that correctly, it does not help with the filtering issues
at all, since it needs exactly the same kind of filter. Daniel explained
the concept far better than I.
On 4 February 2015 at 18:33, Jeremy Stanley wrote:
> On 2015-02-04 13:40:29 +0200 (+0200), Duncan Thomas wrote:
> > 4)
On 2015-02-04 13:40:29 +0200 (+0200), Duncan Thomas wrote:
> 4) Write a small daemon that runs as root, accepting commands over
> a unix domain socket or similar. Easier to audit, less code
> running as root.
http://git.openstack.org/cgit/openstack/oslo.rootwrap/tree/oslo_rootwrap/daemon.py
--
J
Monty Taylor wrote:
>> On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote:
>>> (2) bite the bullet and accept that some types of nodes actually need
>>> root rights for so many different things, they should just run as root
>>> anyway. I know a few distributions which won't be very plea
I suppose that the security argument against running the whole of
nova-compute as root is that a remote exploit in the service is much better
constrained when the thing isn't running as root - e.g. some input
validation fails and allows arbitrary shell in some (currently none-root)
command via an e
On 02/04/2015 06:57 AM, Daniel P. Berrange wrote:
> On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote:
>> The first one is performance -- each call would spawn a Python
>> interpreter which would then call the system command. This was fine when
>> there were just a few calls here and t
On Wed, Feb 04, 2015 at 11:58:03AM +0100, Thierry Carrez wrote:
> The first one is performance -- each call would spawn a Python
> interpreter which would then call the system command. This was fine when
> there were just a few calls here and there, not so much when it's called
> a hundred times in
4) Write a small daemon that runs as root, accepting commands over a unix
domain socket or similar. Easier to audit, less code running as root.
On 4 February 2015 at 12:58, Thierry Carrez wrote:
> Hi,
>
> This is the follow-up of the discussion we started yesterday on rootwrap
> usage at the cro
Hi,
This is the follow-up of the discussion we started yesterday on rootwrap
usage at the cross-project meeting.
A bit of history to stage this story first. OpenStack nodes sometimes
need to run things with elevated privileges. Nova started out as calling
sudo shell commands to execute those, whi
25 matches
Mail list logo
