Hello, Am Donnerstag, 5. November 2015 schrieb Johannes Meixner:
On Nov 4 23:45 Christian Boltz wrote (excerpt):
Am Mittwoch, 4. November 2015 schrieb Johannes Meixner:
Is it possible to have an AppArmor profile for rpm so that rpm cannot change already existing files? ... If you really want that, it might be possible to create a profile based on the rpm -qpl output, but that won't help much for %post scripts. Well, except if your goal is not to let %post change anything that is not related to the new package, ... ;-)
Yes, my goal is not to let %post change anything that is not related to the new package because otherwise anything evil could be done via RPM scriptlets.
For my personal use case see https://fate.opensuse.org/307745 (excerpt) ------------------------------------------------------------------ ... it downloads RPMs only from hardcoded URLs from OpenPrinting and inspects the downloaded RPM whether it overwrites already installed files on the system and if not, it installs it without running any RPM scripts because normal printer drivers do not need to run RPM scripts during installation. If the above conditions are not fulfilled it shows a very explicite warning text and does not install anything. ------------------------------------------------------------------
Normal printer driver software packages do not need to run RPM scriptlets.
That sounds like rpm -Uhv --noscripts printer-driver.rpm ;-) (and checking rpm -qpl printer-driver.rpm before actually installing it)
Perhaps also for installing normal application prgrams there is no real need to run RPM scriptlets.
The only exception is perhaps running /sbin/ldconfig in %post and %postun.
And fontconfig and update-desktop-files and ... ;-) As I showed yesterday, it is possible to create a profile for zypper or rpm, however it needs to be quite broad ("allow write access to everything except /home/**, and also allow to execute several things called in %post"). It should be possible to generate a profile based on rpm -qpl [1], and maybe even separate subprofiles for things typically called in %post (so that ldconfig can only write /etc/ld.so.cache), but I wonder if it's really worth the effort. The problem with such a profile is that it _will_ deny/break something sooner or later, so I'm afraid the chance that people actually use it is not too high... 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. Hmm, maybe I should really create an apparmor-profiles-paranoid package one day ;-)
But I wonder if this could be misused to do evil things, e.g. when third-party software provides its own version of a standard library with "special additional functionality" (a.k.a. backdoor).
If that backdoor is inside the third-party software, then checking things at installation time is useless (assuming it installs that backdoored library in a private directory, not in /usr/lib/). Instead, you might want to create a (strict [2]) AppArmor profile for this software ;-)
Speaking about printer drivers - do you think having a profile for cups would be possible?
I do not yet understand what you mean with "a profile for cups" i.e. what your intent behind such a profile should be.
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). This implicitely means to deny everything else. With such a profile, ideally even malicious printer drivers could "only" access the to-be-printed data, but not everything else. http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/wily/cups/wily/view/head... is probably a good starting point, however I didn't test it yet. The Ux (unconfined) rule used for third-party backends and some other Ux rules look too permissive to me - and that's where you would be able to help a lot because you know a lot about cups and possibly also know (or even can test) lots of third-party printer drivers. Needless to say that the footnote [2] about the strictness of the profile also applies to cups, and that's probably why Ubuntu chose to use those Ux rules.
In contrast when installing openSUSE maintenance updates such an AppArmor profile would have to be disabled before.
Obviously ;-)
BTW: aa-exec allows you to invoke a program with a specific profile. That's probably easier than switching profiles on and off.
Perhaps a more general feature request like https://fate.opensuse.org/307745 for "a general tool" (not necessarily a YaST module) that helps a normal user to install third-party software in a reasonably secure way (what "reasonably secure" is needs to be discussed and defined) makes sense?
See above - I'd call rpm -Uhv --noscripts reasonable secure ;-) Having an AppArmor profile based on rpm -qpl is something people using permissions.paranoid might want ;-)
A funny detail is that some %post script creates /dev/lp* - any idea why that might be needed? For bonus points, tell me which package does that, and why /dev/lp* are needed on a laptop that doesn't have a parallel port ;-)
See https://bugzilla.opensuse.org/show_bug.cgi?id=673845 for the full story.
That's a quite long story ;-) (short version: without /dev/lp*, parallel port printers can't be auto-detected)
You need to find out why you got the parallel-printer-support RPM installed on your computer. As far as I know installation of this RPM is not done in a hardware dependant way but by a RPM "recommends" (actually by a "Supplements: cups").
Right, parallel-printer-support has Supplements: cups. Now the obvious question is if we can change the installation of this package to a hardware-dependent way ;-) Regards, Christian Boltz [1] We already have a script that generates a sniplet for the samba profile based on smb.conf. Converting the rpm -qpl output to a profile sniplet is probably easier ;-) [2] "strict" is exactly the problem - a paranoid user might like a profile for his webbrowser that allows writing files only to ~/download and reading files only from ~/public, and another user will find this restriction extremely annoying ;-) -- "Der Unterschied zwischen einem Windows- und Linux-User ist der, daß ein Linux-User lesen kann!" [Frank Gerd Walzebuck in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org