Bug 619756

How much of ricci runs as user 'ricci'? Wouldn't this expose any compromise of that code to more serious concerns?

(In reply to comment #1)
> How much of ricci runs as user 'ricci'? Wouldn't this expose any compromise of
> that code to more serious concerns?    

I dont understand the question.
How could making the workers suid and calling them directly make the daemon any less secure?

The existing daemon code is no less secure than it is today. 
In fact it could reasonably be considered more so because any dbus issues are no longer in play.

(In reply to comment #2)
> (In reply to comment #1)
> > How much of ricci runs as user 'ricci'? Wouldn't this expose any compromise of
> > that code to more serious concerns?    
> 
> I dont understand the question.
> How could making the workers suid and calling them directly make the daemon any
> less secure?

Before:

ricci interface is compromised as user 'ricci' - dbus method calls are made, which execute workers as root in a controlled environment, controlled command line arguments, stdin, etc.

Now:

ricci interface is compromised as user 'ricci' - workers are now run setuid root in an arbitrary environment, arbitrary command line arguments, stdin, etc.

> The existing daemon code is no less secure than it is today. 
> In fact it could reasonably be considered more so because any dbus issues are
> no longer in play.    

What security issues are you seeing with dbus? Have they been communicated to the dbus team?

(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > How much of ricci runs as user 'ricci'? Wouldn't this expose any compromise of
> > > that code to more serious concerns?    
> > 
> > I dont understand the question.
> > How could making the workers suid and calling them directly make the daemon any
> > less secure?
> 
> Before:
> 
> ricci interface is compromised as user 'ricci' - dbus method calls are made,
> which execute workers as root in a controlled environment, controlled command
> line arguments, stdin, etc.

There are no command line arguments to speak of - everything is done via messages passed via stdin.
So I'm not convinced dbus is offering much here, particularly since an attacker already needs to be root or a member of the root group in order to begin looking for an exploit in the workers (check the permissions on the workers).

> 
> Now:
> 
> ricci interface is compromised as user 'ricci' - workers are now run setuid
> root in an arbitrary environment, arbitrary command line arguments, stdin, etc.

That still doesn't make the daemon any less secure and the involvement of dbus doesn't prevent a compromised daemon from sending specially crafted inputs to search for or trigger exploits in workers running as root - just as they theoretically could from the command line.

> 
> > The existing daemon code is no less secure than it is today. 
> > In fact it could reasonably be considered more so because any dbus issues are
> > no longer in play.    
> 
> What security issues are you seeing with dbus? Have they been communicated to
> the dbus team?    

I'm not seeing any, but all non-trivial code has bugs so it stands to reason that there must be some in dbus.

This is all a red herring though, a compromised ricci daemon can already cause major disruption.  There's little reason to bother looking for additional exploits in the workers.

And, as the initial report said, we discussed this on #0day and they were satisfied there were no additional attack vectors being introduced.

> There are no command line arguments to speak of - everything is done via
> messages passed via stdin.
> So I'm not convinced dbus is offering much here, particularly since an attacker
> already needs to be root or a member of the root group in order to begin
> looking for an exploit in the workers (check the permissions on the workers).

0450, root, ricci - it means they only need to be running as ricci/ricci. Unless the spec patch was wrong?

> > What security issues are you seeing with dbus? Have they been communicated to
> > the dbus team?    
> 
> I'm not seeing any, but all non-trivial code has bugs so it stands to reason
> that there must be some in dbus.

That's not really a useful argument... anyone could turn around and make the same claim that the cluster suite, or bash, or whatever 'must' have security issues. d-bus has had a bit of a history of people claiming "I'm not going to use that, it has security issues" without said people actually being able to substantiate anything, and I'd like to stick to non-FUD concerns.

> This is all a red herring though, a compromised ricci daemon can already cause
> major disruption.  There's little reason to bother looking for additional
> exploits in the workers.

OK. Carry on, then. :)

(In reply to comment #5)
> 0450, root, ricci - it means they only need to be running as ricci/ricci.
> Unless the spec patch was wrong?

Right, the spec patch is wrong (or at least out of date).
The correct attributes should be:

   %attr(04550,root,root)

compared to the current (implied) attributes:

   %attr(0555,root,root)

Originally I thought we needed/wanted the group to be ricci, but that turned out to be wrong.
Looks like I forgot to update the patch. 

> 
> > > What security issues are you seeing with dbus? Have they been communicated to
> > > the dbus team?    
> > 
> > I'm not seeing any, but all non-trivial code has bugs so it stands to reason
> > that there must be some in dbus.
> 
> That's not really a useful argument... anyone could turn around and make the
> same claim that the cluster suite, 

Oh I'm sure Pacemaker (my cluster project) has issues that haven't been found yet.
I use tools like coverity to catch as many as possible, but nothing is perfect.

> or bash, or whatever 'must' have security
> issues. d-bus has had a bit of a history of people claiming "I'm not going to
> use that, it has security issues" without said people actually being able to
> substantiate anything, and I'd like to stick to non-FUD concerns.

Sorry, no FUD intended.  I'd certainly not try to claim that dbus is inherently insecure.

I guess I was trying to say that IMHO dbus is providing way more capabilities than we need in this instance and that its easier to verify a 100-200 line replacement than it is for the 100k lines (or so) of dbus.

@abeekhof: Do we still want to make this modification to ricci?

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.