New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 827347 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner: ----
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Sign in to add a comment

security_SandboxedServices test failure on stout due to root run dbus-monitor in rf-led-handler.conf

Project Member Reported by, Mar 29 2018

Issue description

Comment 1 by, Mar 29 2018

Components: -Infra>Client>ChromeOS OS>Systems
Labels: -M-66 Proj-stout
Status: Available (was: Untriaged)
Summary: security_SandboxedServices test failure on stout due to root run dbus-monitor in rf-led-handler.conf (was: security_SandboxedServices test failure on stout)
you need to dig a little further into the logs to find the actual failure reason beyond the summary

the last 4 failures in that log are due to:
03/27 22:54:47.732 ERROR|security_Sandboxed:0334| New services are not allowed to run as root, but these are: ['dbus-monitor']
03/27 22:54:47.738 ERROR|security_Sandboxed:0338| Failed sandboxing: ['dbus-monitor']
 1999  1935 dbus-monitor                     root             root             root             root             4026531839 4026531840 4026531957 4026531836 4026531837 4026531838 dbus-monitor --system type='signal',sender='org.chromium.flimflam',                interface='org.chromium.flimflam.Device' type='signal',                sender='org.bluez',interface='org.freedesktop.DBus.Properties'

this is due to the stout-specific init script:

which has been around forever:

i'm not sure there are good owners for this.  ideally the dbus-monitor call would not be run as root.

Comment 2 by, Apr 12 2018

Still happening today on cros-goldeneye/chromeos/healthmonitoring/buildDetails?builderName=stout-release&buildNumber=&id=&buildbucketId=&token=AIQH9qMAseiN4OyOBc0Qu8lccDXh%3A1523569989573

04/10 15:02:05.292 WARNI|security_Sandboxed:0323| New services: set(['btdispatch', 'dbus-monitor'])
04/10 15:02:05.296 ERROR|security_Sandboxed:0334| New services are not allowed to run as root, but these are: ['dbus-monitor']
04/10 15:02:05.300 ERROR|security_Sandboxed:0338| Failed sandboxing: ['dbus-monitor']

Comment 3 by, Apr 12 2018

Nigel, looking at GE, isn't this device supposed to be EOL now? I'll mark build as experimental for now.

Comment 4 by, Apr 16 2018

Labels: Hotlist-CrOS-Sheriffing

Comment 5 by, Apr 24 2018

no, stout is not yet EOL.  it's ivybridge, not sandybridge.  please do not mark it experimental.

Comment 6 by, Apr 24 2018

Stout started out on Sandbridge but got rev'd to Ivybridge.
Official AUE date for stout is June 2018

Comment 7 by, Apr 24 2018

On the actual issue, Stout had/has an LED on the b-panel which was supposed to be on when the device was online i think. 
As mentioned, this is very old, what is the lowest effort path to closing this?

Comment 8 by, Apr 25 2018

find a user that can talk to the bluez/shill dbus endpoints (prob those respective users?) and change to that account before running dbus-send/dbus-monitor.  we do this in a few conf files already like authpolicyd.conf via minijail.

Comment 9 by, Apr 25 2018

Passing to current deputy.
Whom is the right owner for this? We still have this error showing up on the 68 release.
tragedy of the commons
If we keep punting this out, the device will be AUEd before fixing it, maybe that is the most reasonable path for now.

It does not seem like it would really impact users and is more of an annoyance on the test dashboards. 

Comment 13 by, May 23 2018

Not sure if this is relevant but there's about 100K 28-day active users of Stout,
but i was never convinced that the LED feature was useful...

Nigel, this is assigned to you; can you find a product eng owner?
Adding Nick, anyone on you team that could take a look based on Mikes comments in #8?
Status: Assigned (was: Available)
This sounds like maybe some old services were caught up in an upstart security thing? See:!msg/chromeos-chatty-eng/ChDd3cvy-AE/SkXS3d-PAQAJ;context-place=forum/chromeos-chatty-eng

Assign to vapier@ to check if this is the case as he +2d the change referenced above and is familiar with upstart, so seems likely to be the right owner.
Reading further, it sounds like vapier@ may already have a fix in mind re #8 so he should just implement that if so.
Owner: ----
this issue has nothing to do with upstart/env exporting.  plus, that has only landed recently.

the security test has long been failing, it just hasn't failed on every build, so people have ignored it.  it's probably been failing ever since the conf file in question was added to the stout build.
Not sure. From the bug traffic above, vapier@ clearly seems to know the most about the issue.
it needs someone who has actual hardware, knows what this led script is supposed to do, and knows how to make sure it's still working

knowing why it's broken (which I explained above) doesn't help with the rest
Nobody has any of that. You have 1/4 which is the closest.
This error was observed on stout-release (see at HWTest stage.

security_SandboxedServices              [ FAILED ]
security_SandboxedServices                FAIL: One or more processes failed sandboxing: defaultdict(<type 'list'>, {'dbus-monitor': ['missing euser']})
security_SandboxedServices                retry_count: 2

Sign in to add a comment