user-settable chrome flags for oobe/login?

[Andrew de los Reyes]

Hi folks, is there a way on a normal image for users to set chrome flags that apply to boot/oobe/login? Lutz (cc'd) is looking to enable extra logging outside of a user session.

Thanks,

-adlr

[Mike Frysinger]

i don't think so by design.  the login screen is meant to be independent of user sessions so that persistent attacks can't affect them.

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Daniel Erat]

If you go to dev mode, you can edit /etc/chrome_dev.conf. But yeah, this is intentionally not possible to do outside of dev mode.

[Lutz Justen]

Let me describe the use case. Details are in crbug.com/732339 (internal).

Authpolicyd periodically calls Samba net, smbclient and kinit. In case something goes wrong, we'd like to have a simple way to debug the problem. Samba's debug logs (we use -d 10) are very verbose and for several reasons we don't want to keep them always on. So how can a user enable them?

Authpolicyd reads a debug flag file at /etc/authpolicyd_flags, so going to dev mode would work, but it seems too complicated for an average user. Correct me if I'm wrong. Is this something we actually ask users to do?

Our current solution is to enable logs in dev/canary only. We simply ask users to go to the dev channel, repro the problem and send us the logs. Problem is, these logs are always on in those channels. It would be preferred if not.

I found ff_debug, chaps_debug etc. in crosh today, which seems to be exactly what we're looking for. Would that work?

Thanks,

- Lutz

[Daniel Erat]

Thanks for the background. Yes, it sounds like a non-persistent crosh setting to enable the extra logging may be your best bet here. I'm saying this because it sounds like the logging that you want to enable lives outside of Chrome. If you instead want to get different behavior from Chrome, you could add a flag to chrome://flags. As far as I know, these flags will be applied at the login screen when they're set by the device owner.

[Lutz Justen]

Would it be OK to persist log settings in /tmp? We're restarting authpolicyd on the login screen to prevent data leaking from one user session into another. If log settings are wiped between authpolicyd runs, it's probably going to be a hassle to get all logs we need.

[Mike Frysinger]

/tmp is never the place for anything other than tmp files/dirs a program itself creates during runtime (and then cleans up).

i dislike chaps_debug because it stuffs random dotfiles in /home/chronos/.  i want us to get away from that monkey business.

authpolicyd already has a stateful directory in /var/lib/authpolicyd/, and it has a dbus endpoint.  so my recommendation would be to add a method there which would write some file in your stateful dir, and then add a callback in crosh to send a dbus message.  something like org.chromium.AuthPolicy.SetLogLevel which takes an integer, and then the crosh code would run `dbus-send` and pass the user arg along.  then your crosh interface would be:

  authpolicy_debug 5

  authpolicy_debug 0

authpolicyd at startup would check/read that debug file and change its behavior as appropriate.

obviously the exact details are up for bikeshedding, but i think you get the idea.

-mike

[Lutz Justen]

I was under the impression that it's a security concern that log settings are permanently persisted in /var/lib/authpolicyd. Is that not the case?

[Mike Frysinger]

i don't see why security would care about verbose logging.  are you writing out passwords or something ?  certainly PII would factor in if you start slurping things.  if you're referring to increased attack surface due to parsing files, then that's always a concern, but you should be sanitizing all your inputs already right ? ;)

your other option would be to create a /run/authpolicyd/ directory in your upstart init script like you do with /var/lib/authpolicyd/.  that'd guarantee the setting is thrown away as soon as you reboot.

-mike

[Lutz Justen]

Yes, we're writing out passwords, but they're encrypted with ROT-13. j/k, we're anonymizing logs at best effort and logging shouldn't increase attack surface significantly. Main concern is not catching every PII, so not logging unnecessarily seems to be the safest approach.

/run/authpolicyd sounds like the way to go. Thanks everyone!