On 04/17/2012 01:00 PM, Seth Arnold wrote: > I'd like to voice my opposition for putting this style of tool in any > automatic position -- it feels as dirty as SELinux's relabeling daemon to me, > to give some idea of how much I dislike it -- by putting policy in > application configuration files we lose the ability to confine incorrect > configuration or even open the policy up to further exploitation if the > config files are writable by something horrible like cpanel or open swat or > worse. > > I'm fine with their use as part of a human-driven profile generator, such as > aa-genprof or the newfangled simpleprof, but at boot feels very wrong. To > abuse an analogy, it feels like setting one's suspenders to expand or > contract to match the belt.
I don't know that it feels wrong, but it does feel like something that should be configurable. One problem policy has is that it is brittle to configuration changes, and having to make changes in two places is always problematic. I will raise the argument that Crispin always made, imperfect security is better than it being turned off because its too hard/much of a burden. The reality is yes this could be exploited but that a exploit is still less likely if applications are confined. What I would like to see is a toggle for each of these type plugins, update/set a variable automatically, raise a warning/log when the config changes to allow an admin to review and update, do nothing. And yes it should also be tied into a new fangled genprof but in such away that it knows where the old value came from etc so that we aren't just adding new values but intelligently authoring and updating policy > -----Original Message----- > From: Christian Boltz <[email protected]> > Sender: [email protected] > Date: Tue, 17 Apr 2012 21:51:52 > To: <[email protected]> > Subject: Re: [apparmor] [patch] make tftp server for dnsmasq working > > Hello, > > Am Montag, 16. April 2012 schrieb Steve Beattie: >> The ideal solution would be something integrated into the dnsmasq init >> script process that parses out the dnsmasq config enough to determine >> the tftproot and sets a variable in an included file for the profile >> before loading both the profile and starting dnsmasq. >> >> Since that's not going to happen, > > Never say never ;-) > > For example, the Samba package in openSUSE >= 12.1 has a script that > creates a profile sniplet at startup for all shares. (Guess who wrote > it... ;-) > > Doing something similar for dnsmasq shouldn't be too hard. (But I won't > do it.) > >> and while I'm not particularly keen on having multiple default >> directories, > > The alternative would be to maintain per-distribution patches forever, > which doesn't sound better to me. > >> I don't have a strong objection to it going in. > > You are too late anyway - it's commited ;-) > > > Regards, > > Christian Boltz -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
