Hello, on Mittwoch, 17. August 2011, John Johansen wrote:
On 08/17/2011 01:21 AM, Sascha Peilicke wrote:
Christian Boltz wrote:
My policy is that (at least) everything that listens on a network port should have a profile - yes, that means (and is) server usage mostly. I also have some profiles on my workstations for various daemons, and even have profiles for some small applications (and even scripts) to prevent that I shoot myself in the foot ;-) Needless to say that the foot-protecting profiles are very special for my usecase and nothing that can or should be packaged.
Sounds very reasonable, how about submitting those profiles?
John and the other AppArmor developers can tell you that I _did_ submit my profiles upstream. Some of them are already in bzr, some others are still pending for review [1]. As I said, my "foot-protecting" profiles that I use for some very special cases are an exception - those profiles would be useless or even counter-productive for other people ;-)
Still this somehow supports my argument that it is very useful on servers, less so on end-user machines.
"less useful" != "useless". On end-user machines, at least some daemons that run by default (nscd, klogd, syslog*, ahavi-daemon) and some small binaries (for example ping and traceroute) are protected by default. I wouldn't call that useless ;-) But yes, on a server there are more applications that you can protect quite easy (compared to protecting firefox, which is difficult for the reasons I explained yesterday).
The best example is downloading files - if you want to make Firefox really secure, you can limit write access (which includes downloads) to /home/*/downloads/**. However I'm quite sure that you'll then get lots of complaints because of "I can't download files to ~/coolstuff/" ;-)
The alternative that will avoid this complaints is basically this rule: /** rw,
but this isn't really more secure than not having a profile at all. (In fact, someone already posted a modified firefox profile with such a rule in bugzilla - but I'm quite sure this will be rejected upstream.
Instead of /**, you could of course use /home/**, /tmp/**, /var/tmp/** as possible download locations - but that's already what the filesystem permissions make from the /** rule, so it isn't more secure. (A normal user doesn't have write permissions at other places, and if someone runs Firefox as root, well - I don't even want to think about that...)
owner @{HOME}/** rw,
would be even better
Yes, of course - but in practise it doesn't change too much. A normal user (hopefully) doesn't have write permissions in another user's home. And if you don't include /tmp/**, people will probably complain that they can't download a file to /tmp (which might be a valid location for "download, unpack and delete the zip/tarball" downloads). I know about owner restrictions etc. - but my point is that a firefox profile that makes everybody happy (by allowing storing downloads anywhere) does not really help security-wise. And a "secure" firefox profile (restricted to ~/downloads) will cause lots of complaints ;-)
Everyone that would complain about such a move is invited to fix the profiles we have or even create _and maintain_ new ones.
Sounds like I should blog more instead of silently doing the work ;-)
That's the spirit, seems like I reached the correct guy here.
;-)
That said: The best person to maintain a profile is a person who actually uses the profiled application. The reason for this is that nearly every application that does more than printing "hello world" has several config options that might influence which files are accessed. (I know AppArmor very well, but if you tell me "create a profile for $application" it will lack lots of rules if I'm not familiar with $application.)
its not just familiarity but because it doesn't fit your usage model. This really cries out for crowd sourcing,
Exactly!
Otherwise I proposing a grace period for people to step up and get rid of this for 12.1.
Does the above text count? ;-)
You don't demand that from our regular users? I mean I only got some insights into writing profiles recently, as I'm forced to do it (you know, policy @work). Still I'm having a hard time confining a daemon running in a Java servlet container (no, not tomcat) with many plugins, auto-update and that polls stuff in the interwebs.
Sounds interesting, but not impossible. For comparison: I have a working profile for Apache with lots of vHosts, which includes Typo3 and many more "big" applications that are quite funny to profile. You won't get a complete profile for such a setup in an hour (because you'll always miss something). The solution is: switch the profile to complain mode for some days, run logprof from time to time and finally switch the profile to enforce mode.
The only thing I learned so far that this isn't childsplay :-)
IMHO using aa-genprof or aa-logprof isn't really hard. The only precondition is that you know what the permission flags mean. Some of them are obvious (like r and w), and you can learn the other ones in 30 minutes. Yes, I'm sure about the 30 minutes because I did a talk about AppArmor at LinuxTag 2009 which took less than 30 minutes ;-) If I find some free time at the conference (might be difficult because I probably can only come on sunday), I can provide you (and of course everybody else who is interested) with a short AppArmor workshop.
nope, though feel free to ask for help on the apparmor ml or irc (#apparmor@irc.oftc.net).
But the most important point is: it would be a loss for openSUSE if AppArmor would be disabled by default.
It's merely about opt-in or opt-out and thus, which is more reasonable. Given the current state of our AppArmor integration and the huge community demand, I doubt that. But that's what this thread should be about.
The question is what is worse: a) hindering a user by a too strict AppArmor profile (which is a rare event IMHO) b) an exploit in one of the confined daemons (nscd, syslog* etc.), while AppArmor would have prevented the exploit. That's hopefully also a rare event, but if it happens, it can have big consequences. Call me paranoid, but I clearly prefer being hindered by a too strict profile ;-) BTW: AFAIK there will be an AppArmor 2.7 beta release soon (mostly bugfixes compared to 2.6.x) - most probably early enough for inclusion in 12.1. Regards, Christian Boltz [1] for those who aren't involved with upstream AppArmor: There is a policy that all changes have to be reviewed (by sending a patch) before they are allowed to be commited to bzr. --
[wikibot] jfyi: we have an internal ruby script that works with iChain. we used it for the SDB migration (did you really expect we uploaded 2000pages manually?;) Considering you have nothing else to do, yes. ;-) [Marcus Rueckert and houghi in opensuse-wiki] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org