[compsciphd]

or just sandbox cups. There's no reason cups needs to write anything beyond its "configuration" and its "print spool". And hence, shouldn't have access to anything beyond what it needs to configure itself and print.

thing like cups should be easy to sandbox, especially if we allow dbus like APIs as a means to cross sandbox boundaries (i.e. RPC mechanism).

and by sandbox, I dont mean simply use apparmor type rules (though that can work), but a cups that lives within its own file system and nothing else is even visible.

i.e. programs will always be buggy, even if we get rid of all language oriented bugs, there will still be logic bugs that will result in security holes. We just need to make it easy to isolate programs (and services) into their own sandboxes while retaining the ability for them to interact (as otherwise, lose much of the value of modern systems).

In practice, I would argue, a lot of modern systems do this already (ala ios/android). The apps run sandboxed and only have restricted abilities to interact with each other.

[jabl]

That's sort-of the direction they're going with CUPS 3. The 'local server', which is what most people will need, runs as a normal user, not root, doesn't listen on the internet, and talks only the IPP everywhere protocol. For supporting legacy printers, there will be separate sandboxed 'printer applications' which read in IPP Everywhere, run the driver code, and communicate with the backend printer using an appropriate protocol.

For enterprise users there will be a separate 'sharing server'.

https://ftp.pwg.org/pub/pwg/liaison/openprinting/presentatio...