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 really not
On 2/4/15, 10:24 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Feb 04, 2015 at 09:10:06AM -0800, James E. Blair wrote:
Thierry Carrez thie...@openstack.org writes:
You make a good point when you mention traditional distro here. I
would argue that containers are slightly
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 each
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 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
--
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 fits
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 filters
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 been
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 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 root, that
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 argument,
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 lot of work
Thierry Carrez thie...@openstack.org 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
On Wed, Feb 04, 2015 at 09:10:06AM -0800, James E. Blair wrote:
Thierry Carrez thie...@openstack.org 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
(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
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 fu...@yuggoth.org wrote:
On 2015-02-04 13:40:29 +0200 (+0200), Duncan
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
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 just a
On 5 February 2015 at 03:33, Monty Taylor mord...@inaugust.com 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
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 a
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
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 pleased by
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,
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 there,
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 thie...@openstack.org wrote:
Hi,
This is the follow-up of the discussion we started yesterday on rootwrap
25 matches
Mail list logo
