Hello, Am Freitag, 6. November 2015 schrieb Johannes Meixner:
becomes now probably too much off-topic because now it is mainly about printer drivers and CUPS.
This thread already got quite some off-topic discussions, therefore I don't see a real problem. However, I'll update the subject ;-)
On Nov 6 01:02 Christian Boltz wrote (excerpt):
Normal printer driver software packages do not need to run RPM scriptlets.
That sounds like rpm -Uhv --noscripts printer-driver.rpm
Of course - except running /sbin/ldconfig if needed.
The only exception is perhaps running /sbin/ldconfig in %post and %postun.
And fontconfig and update-desktop-files and ... ;-)
Here I was talking about printer driver software packages not about arbitrary third party RPMs.
I already see someone requesting a sandbox for installing font packages, so we should not limit this to "just printer drivers". (I know there are more third-party printer driver RPMs than font RPMs, but still.)
Having a basic rpm profile ("allow everything outside of /home") might be an option, but even that could break something if someone invents a a new creative way to use %post.
But when the intent is to "forbid changing anything in /home/" then it must break installing RPMs that would change something in /home/ - or what do I misunderstand here?
No misunderstanding. In the previous mails you said that RPMs should *never* touch anything inside /home/. Therefore I'd call that restriction "enforcing a policy", not "breaking something" ;-)
I'm thinking about an AppArmor profile that allows cups to do only what it is supposed to do (take print data from an application, convert it to a format the printer understands, and send it to the printer).
As far as I know the cupsd implements already some limitations what filters and backends can do.
Furthermore normally installed filters and backends run as user "lp" which means they are already sufficiently restricted by traditional Unix file permission settings.
I know at least one exception - cups-pdf writes the resulting PDF files to each user's homedir, so it can't run as user 'lp'.
Regarding the cupsd itself: It runs intentionally as root because - only root can switch user to lp so that this way the filters and backends cannot compromise the cupsd itself (e.g. its config files).
I'd argue that it could run as "lp" from the beginning - that would be (at least) equally secure and wouldn't even need to switch users. (I'm sure there are reasons why it's running as root - but "can switch to 'lp'" is not a real reason.)
- the cupsd does more than what you described.
I know that I provided a very quick (and possibly incomplete) summary, but basically it describes what most users see and know about CUPS.
In general we have this discussion every now and then again and again and again and again and again and again...
And the result is always the same: The current defaults are the currently best possible balance between reasonable default security and reasonable user-friendly default behaviour.
Any attempt to make CUPS more secure by default causes complaints that then this or that functionality doe no longer work out of the box and any attempt to make CUPS more user-friendly by default makes it unacceptable less secure by default.
Agreed, there is always the balance between security and being user- friendly. (See also permissions.{easy,secure,paranoid}.) And ideally an AppArmor profile would allow everything that CUPS usually does, so it won't change anything from the user's POV.
With such a profile, ideally even malicious printer drivers could "only" access the to-be-printed data, but not everything else.
First and foremost you would need to describe how a program that runs as "lp" could do "everything else" or what exactly you mean with "everything else".
For example, it could read files from the home directory if the unix permissions allow this (755), and could then send those files to an attacker. The point is: Even if running as 'lp', it can access data that it shouldn't be able to - and that's where an AppArmor profile could be helpful.
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cups/wily/v iew/head:/debian/local/apparmor-profile I wonder why they need an Apparmor profile for CUPS. With "why" I mean their reasoning behind. I wonder what might be wrong in CUPS itself that is not discussed on the CUPS upstream development list and cannot be fixed in CUPS itself so that the only way out for them is to use an AppArmor profile?
The answer is probably https://startpage.com/do/search?q=cups+exploit and especially the things that are not yet listed there (in other words: unknown security flaws in CUPS). I know that nobody intentionally writes buggy code, but it's a fact that all software has bugs [1], and some of them can be exploited. AppArmor can at least prevent exploits that access files which are not allowed in the profile and therefore reduce the possible damage. (It can also deny other things like network access / "sending out files", but we probably have to allow network usage for CUPS to support network printers.)
I think I will ask Martin Pitt and Till Kamppeter about their reasoning behind.
Please do that, I'm also interested in the answer ;-) (I wouldn't be surprised if the answer is "additional security".) Regards, Christian Boltz [1] well, a simple hello_world.py is probably bug-free [2] ;-) but anything bigger than that has a good chance to contain bugs. [2] even that could be incompatible with python 3.x ;-) -- liegt es vielleicht an den lauschigen 34°, die der Prozessor oder sowas nicht mitmacht? -> Soll ich mit dem Rechner jetzt zum Baggersee rausfah- ren und ihm ne Abkühlung verpassen... [Sebastian Schulze in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org