On 03/07/2015 05:10 PM, Christian Boltz wrote:
Hello,
Am Samstag, 7. März 2015 schrieb Lars Müller:
On Sat, Mar 07, 2015 at 08:04:43AM -0500, Patrick Shanahan wrote:
* Christian Boltz
[03-07-15 07:59]: [...] I'll submit an updated AppArmor package to factory in some days (I wouldn't be surprised if the bugreport gets another "oh, and it also needs access to $file" ;-)
I probably won't do an update for 13.1 only to support the combination 13.1 + latest samba, but nobody stops you from updating the profile yourself ;-) <aside> As 13.1 is designated as the next Evergreen, perhaps it would be good to continue updates there. </aside> Sorry if my statement wasn't clear enough ;-)
All I said/meant is that I won't do an update because the profiles don't work with latest samba from an _extra repo_ (but I'll probably include it if I do an update for another reason).
If something in the official 13.1 (update) repo needs a profile update, I'll of course deliver one ;-) and I also plan to do that in the Evergreen phase.
With plain openSUSE 13.1 and 13.2 I expect we'll stay quite some time with Samba 4.1
But we all don't know how things develop in the next three or six months. In other words: I'll include the updated profile in the security:apparmor 2.8 and 2.9 packages (which I use as base for updates), and you notifiy me early enough if you decide to update to Samba 4.2 on 13.1 or 13.2 ;-)
I second Patrick that if possible and it doesn't cause too much hazle and work to adapt the required changes to AppArmor also to openSUSE 13.1 and 13.2.
@Christian: Which type of help can the community offer you? Following your suggestions from the bug report to show which access permissions are required? Yes, detailed bugreports are always welcome - either with a profile patch or with the audit.log attached.
I'm also happy about added profiles (in the respective package or submitted to the AppArmor package) - but the profile should work for (nearly) everybody. This unfortunately means that it's very hard to deliver profiles for programs that have a "save as..." feature ;-) (well, maybe we can collect them in an apparmor-profiles-paranoid package ;-)
The most important point is to get feedback from people who actually use the AppArmor-protected programs, because those know best what is broken and also know some details, for example if allowing a specific file is enough or if a wildcard is the better choice.
Speaking of that - I recently noticed that the klogd, syslogd and syslog-ng profiles aren't applied anymore because of the /usr move. Before I release an update with those profiles re-enabled (aka "path fixed"), I'd like to have them tested ;-)
So if someone out there uses klogd, syslogd or syslog-ng and wants to test the updated profiles, please speak up ;-) (you'll also learn to read or at least grep audit.log because the changed profiles also uncovered a bug in aa-logprof [1] ;-)
Regards,
Christian Boltz
PS: Ubuntu ships quite some additional profiles, but most of them are "hidden" in several packages, so it's hard to collect them. Fortunately debconf is very close to me this year (Heidelberg, Germany), and some of the upstream developers will be there too, so I hope for a solution to this problem. When collecting those profiles work, I'll probably package them in a separate package.
[1] The problem looks easy - aa-logprof doesn't update profiles with a header line like profile foo /bar { because aa-logprof thinks the profile is named "foo /bar", but the log contains entries for "foo". Changing it to recognize only "foo" would be easy, but keeping the "/bar" is a bit ;-) harder. The result is that I wrote a series of ~20 patches that add tests to ensure I don't break anything, do some cleanup, fix some other bugs I noticed on the way [2] [3] and will finally add the handling for that style of profile headers ;-)
[2] maybe you know that WTF moment when you write a test + expected result for existing code, and then see the _real_ result...
[3] at least one of those bugs was quite entertaining ;-) - fortunately it happened only in very rare cases.
Would it be apparmor settings even if I am booting the machine with apparmor=0 on the kernel line in grub.cfg? From what I know my machine is not running apparmor (if apparmor is something that is run .. I am very unfamiliar with it and to the best of my knowledge do not use it!) -- --Moby They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org