> why does this daemon need to run as root? It's a system activated daemon, just the same as upowerd and packagekitd. Architecturally, it's root as it needs to be accessed from different user sessions, and even in environments like a login manager and other system daemons like CUPS.
If you're asking why it couldn't be made to run in a more restricted group set, that's probably a good question. In Fedora and OpenSUSE there's no requirement to choose a private group and user for the daemon, and I'm also not sure what other groups colord would have to be made a member of. If that's really what you want, I can add some options to configure like --with-daemon-username and --with-daemon-group although I would much prefer a patch as I'm not really familiar with all the security and functional implications of running not as root. >- org.freedesktop.color-manager.modify-profile appears to read any file on the filesystem. org.freedesktop.color-manager.modify-profile is just the PolicyKit authorization action-id, I'm not sure what you mean there. The only time that authorization is used when the user does SetProperty on the org.freedesktop.ColorManager.Profile interface, and that's not actally reading or writing any files. >It reads the entire file (e.g. DoS with /dev/zero), and might do something via lcms parsing Well, in the usual case where the session is passing files to colord, the session just opens the file and passes a file descriptor over dbus to colord. If the session isn't capable of doing that, then the filename is indeed sent, although this breaks security frameworks like selinux pretty hard as then you've got a daemon reading the users files. I'm open for ideas about whether I need futher checks for the /dev/null case. By handcrafting a malicious CreateProfile with a filename of /dev/null and not passing the FD, I get the following output in colord: (colord:14986): Cd-WARNING **: LCMS error 1: Read error. Got 0 bytes, block should be of 128 bytes By using /dev/urandom I basically DoS the daemon (which is expected) and there's not an awful lot that can be done about that as the results would be the same if I just fed a huge ICC profile (a multi-megabyte valid blob) for the daemon to parse. Of course, if there was a parsing bug in the lcms code it's theoretically possible to crash the daemon. Once you've got malicious code running in the session you've got bigger problems than crashing a color daemon, especially if it's going to get auto-restarted on the next use. > by default, SearchVolumes is true in the /etc conf file Right, and that's the kind of thing we could add a configure switch for if required. We actually are pretty strict about checking the volume to read profiles, although you could easily crash the daemon if you found a weakness in lcms2, and then created a HFS+ volume with a Library/ColorSync/Profiles/Displays/ path and an hand-crafted color profile. At the end of the day, autoloading the OSX and Windows profiles is a cute trick, but if you think that's at the detriment to security then we can easily turn it off. Richard. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/823185 Title: [MIR] colord To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/colord/+bug/823185/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
