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

Issue metadata

Status: Assigned
Owner: ----
Cc:
Components:
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 mkarkada@chromium.org, Mar 29

Issue description

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:
  src/overlays/overlay-stout/chromeos-base/chromeos-bsp-stout/files/rf-led-handler.conf

which has been around forever:
  https://chrome-internal-review.googlesource.com/31883

i'm not sure there are good owners for this.  ideally the dbus-monitor call would not be run as root.
Cc: dianwa@chromium.org pbe...@chromium.org jkop@chromium.org
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']

https://00e9e64bac88ed6f60d2e076da52b5fdf99d7883cdb706263b-apidata.googleusercontent.com/download/storage/v1/b/chromeos-autotest-results/o/191067824-chromeos-test%2Fchromeos6-row2-rack5-host13%2Fdebug%2Fclient.0.DEBUG?qk=AD5uMEvOR_MLCH1TP4gcfznj5c1DBj__eDZvmbSinWpAhY4kJjx_iTMwQ9NAbTUdK6_lHIkJxJkRJ35kZxO7r3PMde5ErQwfWkUQL84DeeANQmcuwSwYekZh-5qwzM3Aw9GLCQIDyfHkg71Kl9-AEk3yb4snIi8eN8A7YBXWsujYoNx4z3UqUhuwnrlTRg06P8R4N7_cQU_I3aN9Y2xFuxHPDwjJmt5arvlUtGat373vLl5fWztEJ-LkiupOb_1KQcN9RCp0PsNacb0VynPPp1I9JZpk5XUBgcKVsnJoQ7PnfXLPif9USym6u5pnF74hbZNSHw8zKJsV-vV2aO5GdRWBcxM6ls4i6O-WTzDHCxOOn6p3dMmXBH-PC-VfTcjwg8mEksvp4J7kilH2ojyOg_K3cAqHxjhw4U-rDP8KYEqVngNKdQ9TbfcYwr8pCWlSQd9qnhRZ4bcQ-04TNovDgEq5gDpbVNv0tqb4_ngY2XDSJlBeJ7FgYr-jDp1H3TRFy4wb8RJ2fzybsazLyVb-PUAibG6DoFoz2y8n1dRZx662LcWfLf9fzCxxA2HeQG-_eyF3zC_TJwrJYxiWINqsY7Ud69S2LFhjuGyrHcoTJDlRA9pXjPzRTMcM4ag96SAJMDkimWPFRxBgpRERjt-pkHRCr8Xja9nD2gjGRfJQFZXbKX7odDzHOF1kKhZsqqfkxOVFmJ-a0BlcclxsDW8BzaZ7pbE6ylp1rjeF6IUN_P6opB9qg6gfMW7L9gjgK5Q-FlnQ63ei1heoOWezCXC2V1kBHtZbBgpgH-TKih_WiRPs3TBKKJsqt2DRUbZvCwTKUA_vle44Tvr4tycyrr-wob9pRjZ2a1ox7A
Owner: nsale@chromium.org
Nigel, looking at GE, isn't this device supposed to be EOL now? I'll mark build as experimental for now.
Labels: Hotlist-CrOS-Sheriffing
no, stout is not yet EOL.  it's ivybridge, not sandybridge.  please do not mark it experimental.
Stout started out on Sandbridge but got rev'd to Ivybridge.
Official AUE date for stout is June 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?
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.
Cc: -jkop@chromium.org gu...@chromium.org
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. 
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?
Cc: jclinton@chromium.org
Cc: nsanders@chromium.org
Adding Nick, anyone on you team that could take a look based on Mikes comments in #8?
Cc: mnissler@chromium.org nsale@chromium.org
Owner: vapier@chromium.org
Status: Assigned (was: Available)
This sounds like maybe some old services were caught up in an upstart security thing? See:
https://groups.google.com/a/google.com/forum/?utm_medium=email&utm_source=footer#!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 https://uberchromegw.corp.google.com/i/chromeos/builders/stout-release/builds/5131) 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