Hello, Am Freitag, 15. Februar 2013 schrieb Sascha Peilicke:
On 02/15/2013 02:44 PM, Christian Boltz wrote:
Am Freitag, 15. Februar 2013 schrieb Sascha Peilicke: [...] For example, I have a working profile for acroread, but it comes with some restrictions. The most important one is: it allows to read *.pdf files from any location, but _doesn't allow any write access_ except its own config (hint: this breaks File - save a copy and File - save as text, but for my personal use, I don't need them). The advantage of this profile is: even if acroread goes crazy, it can't destroy anything ;-)
I could allow write for *.pdf, *.txt and *.ps (for "print to file") - that would make the profile working for most people, but would also make it less secure.
If you look at reported security incidents, actually it's much more important to correctly confine acroread
As I already said: It's possible to add a profile for acroread (basically my profile + allowing write access for *.pdf *.ps *.txt) I'll happily add this profile, and I'm sure it works for >90% of the users. But: I'm also sure there will be some corners in acroread that _won't work_ with this profile. For example, I just noticed acroread can open files attached to a PDF with the associated program - allowing this (or "just" storing the attached files with random extension in random locations) will make the profile too loose, which translates to "nearly useless" (in other words: the profile won't allow it). So the question is: Will you accept a profile for acroread that makes it much more secure, but _breaks/blocks some less used features_ like storing or opening files attached to a PDF? Yes, I'm serious with that question, and I'd like to have an answer. Now to the more funny part:
than sendmail, which has a profile AFAIR (sorry).
IIRC sendmail has a quite interesting security history. Fortunately most people use postfix nowadays ;-)
Right, sorry for beeing inexact. Same like confining tomcat, makes no sense w/o knowing the served application. Trust me, I had to do an AppArmor profile for the Jenkins behind ci.opensuse.org. I was lost without Darix and even he (insisting on it first) acknowledged that it is a) hard to get right, b) pretty useless as permissions have to be quite broad (net access, write half of the filesystem, you name it).
I don't know Jenkins, but web applications always tend to be interesting[tm]. Especially if they can automatically download and install extensions or update themself (which means to have _all_ files wwwrun-writeable). Yes, I have some experience on this - I'm running several servers with Typo3, Joomla (don't even think about restricting write access), Serendipity, Wordpress (not my favorite software security-wise...), PostfixAdmin and some more. BTW: Sometimes deny rules help a lot to improve security if you need write permissions in general: deny owner /web/app/**.php rw, # deny past exploits deny /web/app/**.php w, # deny new exploits but if your application can update itsself or download and install extensions, you won't be able to use this.
We chose to disable apparmor by default because of the little benefit it has in practice as of today and because of the annoyance it causes once some lower-level system daemon breaks.
Hmm, the breakage seems to be very low if I judge by the number of bugreports ;-)
Well thank our carefully selected sane defaults we provide to our(selves) fellow users.
It might disappoint you, but this "careful selection" is basically based on what upstream contains, what some package maintainers add to their own package, and sometimes just on what I'm using (and profiling) anyway ;-) Some exceptions might apply - for example, I added a profile for Samba's winbindd (I submitted the profile upstream in the meantime) - according to bugzilla, nobody noticed it ;-) BTW: I do _not_ use Samba ;-)
Of course you could argue that non-working daemons are always the most secure ones but that shouldn't be our goal ;-)
Well, I prefer non-working daemons over exploited daemons ;-) (non-working is easier to detect and easier to fix)
Well, shutdown your server to be totally un-exploitable. Non-running is even easier to detect. Can't be DoS'ed, needs no maintenance, uses no power and let's you enjoy the sun.
You forgot "unplug all cables, dig a deep hole in your garden, put the server in and fill the hole with concrete" ;-) Seriously: My policy for the servers I maintain is: if something opens a port towards the internet, then it has to have a profile. Needless to say that there are alternative ways to break a daemon, for example old/outdated config files, syntax errors in the config etc. As long as I can notice them at startup, I wouldn't call this a real problem. (If they cause the daemon to fail after running $many hours, it's another topic.)
You are comparing your car's brakes (AppArmor) with your insurance (security updates) ;-) [1]
The insurance helps especially when you don't have brakes :-)
*lol* Unfortunately there a risk: While crashing, you could also hurt or even kill yourself. Do you still like this car without brakes? ;-)
All that said: As usual, security is (unfortunately) not boolean true / false ;-) and it needs several parts to make the system as secure as possible.
Fully ack'ed, so let's spend our precious resources on those parts that provide the biggest gains.
Yes. I hope this includes an answer if you would accept an acroread profile as described above ;-) Regards, Christian Boltz -- "Der wahrscheinlich ärgerlichste Aspekt eines Computerprogrammes ist die Art und Weise, in der es auf Ihre Fehler reagiert" [L. Lamport, LaTeX-Handbuch] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org