Bug 619756 - Avoid unnecessary use of DBus by Ricci
Avoid unnecessary use of DBus by Ricci
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ricci (Show other bugs)
6.1
All Linux
medium Severity medium
: rc
: ---
Assigned To: Chris Feist
Cluster QE
:
Depends On:
Blocks: 756082 840699
  Show dependency treegraph
 
Reported: 2010-07-30 09:01 EDT by Andrew Beekhof
Modified: 2014-02-13 14:23 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-13 14:23:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch which bypasses dbus for selected ricci modules (5.04 KB, patch)
2010-07-30 09:01 EDT, Andrew Beekhof
no flags Details | Diff

  None (edit)
Description Andrew Beekhof 2010-07-30 09:01:57 EDT
Created attachment 435547 [details]
Patch which bypasses dbus for selected ricci modules

Description of problem:

DBus is used in Ricci to avoid having the ricci daemon run as root.
Unfortunately this makes the architecture quite complicated and hard to debug.

Additionally things like bug #617310 make Ricci (and by extension Luci) impossibly slow on virtualized hardware.

The proposed patch bypasses DBus and executes the worker binaries directly.

After consultation with #0day, the ricci daemon will still call setuid() to permanently give up root privileges but the worker binaries will be packaged with the S_ISUID bit set such that the mode is 04550.  The workers will be continue to be owned by the root user and group.  

This use of S_ISUID binaries is not considered to introduce any additional opportunities for privilege escalation beyond what exists today.  Attackers would already need to have compromised the system to have obtained membership of the root group - which is what an attacker would have if Ricci was compromised today - in order to exploit a theoretical bug in one of the SUID workers.

Additional info:

The following patch packages the worker binaries with the mode needed for the above patch to work.
modcluster would need something similar.


diff -u -r1.14 ricci.spec
--- ricci.spec	9 Jul 2010 19:25:07 -0000	1.14
+++ ricci.spec	30 Jul 2010 12:51:18 -0000
@@ -83,27 +88,27 @@
 # modrpm
 %config(noreplace)	%{_sysconfdir}/oddjobd.conf.d/ricci-modrpm.oddjob.conf
 %config(noreplace)	%{_sysconfdir}/dbus-1/system.d/ricci-modrpm.systembus.conf
-			%{_libexecdir}/ricci-modrpm
+%attr(04550,root,ricci)	%{_libexecdir}/ricci-modrpm
 
 # modstorage
 %config(noreplace)	%{_sysconfdir}/oddjobd.conf.d/ricci-modstorage.oddjob.conf
 %config(noreplace)	%{_sysconfdir}/dbus-1/system.d/ricci-modstorage.systembus.conf
-			%{_libexecdir}/ricci-modstorage
+%attr(04550,root,ricci)	%{_libexecdir}/ricci-modstorage
 
 # modservice
 %config(noreplace)	%{_sysconfdir}/oddjobd.conf.d/ricci-modservice.oddjob.conf
 %config(noreplace)	%{_sysconfdir}/dbus-1/system.d/ricci-modservice.systembus.conf
-			%{_libexecdir}/ricci-modservice
+%attr(04550,root,ricci)	%{_libexecdir}/ricci-modservice
 
 # modlog
 %config(noreplace)	%{_sysconfdir}/oddjobd.conf.d/ricci-modlog.oddjob.conf
 %config(noreplace)	%{_sysconfdir}/dbus-1/system.d/ricci-modlog.systembus.conf
-			%{_libexecdir}/ricci-modlog
+%attr(04550,root,ricci)	%{_libexecdir}/ricci-modlog
 
 # modvirt
 %config(noreplace)	%{_sysconfdir}/oddjobd.conf.d/ricci-modvirt.oddjob.conf
 %config(noreplace)	%{_sysconfdir}/dbus-1/system.d/ricci-modvirt.systembus.conf
-			%{_libexecdir}/ricci-modvirt
+%attr(04550,root,ricci)	%{_libexecdir}/ricci-modvirt
 
 %pre
 /usr/sbin/groupadd -g 140 ricci 2> /dev/null
Comment 1 Bill Nottingham 2010-07-30 12:26:30 EDT
How much of ricci runs as user 'ricci'? Wouldn't this expose any compromise of that code to more serious concerns?
Comment 2 Andrew Beekhof 2010-08-02 11:07:18 EDT
(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.
Comment 3 Bill Nottingham 2010-08-02 12:41:56 EDT
(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?
Comment 4 Andrew Beekhof 2010-08-03 03:53:00 EDT
(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.
Comment 5 Bill Nottingham 2010-08-03 10:49:02 EDT
> 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. :)
Comment 6 Andrew Beekhof 2010-08-03 12:27:52 EDT
(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.
Comment 7 Perry Myers 2010-11-27 13:02:55 EST
@abeekhof: Do we still want to make this modification to ricci?
Comment 17 RHEL Product and Program Management 2012-07-10 02:56:02 EDT
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.
Comment 18 RHEL Product and Program Management 2012-07-10 21:51:37 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.