[Bug 1166407] New: AppArmor profiles should be sub-packages of the application they protect
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407 Bug ID: 1166407 Summary: AppArmor profiles should be sub-packages of the application they protect Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: All OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: AppArmor Assignee: suse-beta@cboltz.de Reporter: philippe.andersson@iba-group.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- All default AppArmor profiles are currently provided as part of package 'apparmor-profiles'. That's all well and good as long as only official SUSE-provided packages are installed for the applications protected by AppArmor. When you start installing 3rd-party packages for the same application, that system breaks down, because the 3rd-party build of the application may not have the exact same requirements, meaning its startup may get blocked by AppArmor. The workaround we put in place was to use the mechanism of include files (in '/etc/apparmor.d/local/') to cover the extra access rights needed. But it would be much cleaner if the 3rd-party vendor could provide their own AppArmor profiles as a sub-package of their application. In the current situation, that's not possible, as they would need to overwrite a (set of) file(s) provided by another package. Case in point: the Samba 4 packages built by SerNet GmbH. Their daemons are prevented from starting by the following (default OpenSUSE) profiles: - /etc/apparmor.d/usr.sbin.nmbd - /etc/apparmor.d/usr.sbin.smbd - /etc/apparmor.d/usr.sbin.smbldap-useradd - /etc/apparmor.d/usr.sbin.winbindd I guess a possible alternative solution (through perhaps less flexible) would be to remove local include files "placeholders" from '/etc/apparmor.d/local/' (while keeping the '#include' directive in the master file). This way, 3rd-party vendors could safely package files destined to land below 'local/' (but the drawback, if I understand correctly, is that permissions granted in the master file could not easily be revoked by the included file if needed). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407#c1
--- Comment #1 from Christian Boltz
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407
Bjoern Jacke
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407
Bjoern Jacke
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407#c2
--- Comment #2 from Philippe Andersson
While I somewhat understand why you'd like to see sub-packages, let me ask a completely different question:
What exactly do you need to add to the samba profiles?
For 'usr.sbin.smbd': /dev/urandom rw, For 'usr.sbin.winbindd': /dev/urandom rw, /var/cache/samba/ rw, /var/cache/samba/smb_krb5/ rw, /var/cache/samba/smb_krb5/* rwk, /var/cache/samba/smb_tmp_krb5.* rwk, /var/cache/samba/msg.lock/ rw, /var/cache/samba/msg.lock/* rwk, (For 'usr.sbin.nmbd', all the changes I needed have since been introduced by on-line updates or upgrades since 15.0). Some of these extra requirements may be due to the fact that SerNet uses different default locations during the build environment configuration phase, or enables some options at that time that are not active in the SUSE builds (personal hypothesis). Also, please note that the above extra AppArmor profile contents has been determined based on the DENIED "audit.log" entries found on a domain client (i.e. on a client PC joined to the domain). I still need to check whether further changes may be required to cover: - a domain member server - a domain controller I expect to find out over the coming weeks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407
James McDonough
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407#c3
--- Comment #3 from Christian Boltz
For 'usr.sbin.smbd': /dev/urandom rw,
For 'usr.sbin.winbindd': /dev/urandom rw,
I'm a bit surprised why you need write permissions to /dev/urandom. Do smbd and winbindd really write to it? (According to man urandom this is technically possible, but IMHO still surprising.)
/var/cache/samba/ rw,
The write (mkdir) is already allowed in abstractions/samba. That means we'll only need to add read permissions (directory listing). Shouldn't be a serious problem, but I'm still slightly surprised that you need them - AFAIK you are the first one with that requirement. (Wild guess: maybe related to the smb_tmp_krb5.* files in that directory?)
/var/cache/samba/smb_krb5/ rw, /var/cache/samba/smb_krb5/* rwk, /var/cache/samba/smb_tmp_krb5.* rwk,
Looks like everybody uses a different location for the krb5 files, so let's add one more location ;-)
/var/cache/samba/msg.lock/ rw, /var/cache/samba/msg.lock/* rwk,
These two are (mostly) covered in abstractions/samba already: /var/cache/samba/msg.lock/ rwk, /var/cache/samba/msg.lock/[0-9]* rwk, Note that the second rule has [0-9]* instead of * - does this work for you, or do you see filenames not starting with a digit?
(For 'usr.sbin.nmbd', all the changes I needed have since been introduced by on-line updates or upgrades since 15.0).
:-)
Some of these extra requirements may be due to the fact that SerNet uses different default locations during the build environment configuration phase, or enables some options at that time that are not active in the SUSE builds (personal hypothesis).
Yes, possibly - but even if I asked some questions about your profile additions, I'm quite sure that I can get them merged upstream.
Also, please note that the above extra AppArmor profile contents has been determined based on the DENIED "audit.log" entries found on a domain client (i.e. on a client PC joined to the domain). I still need to check whether further changes may be required to cover: - a domain member server - a domain controller
I expect to find out over the coming weeks.
I'm looking forward for your feedback! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407#c4
--- Comment #4 from Philippe Andersson
I'm a bit surprised why you need write permissions to /dev/urandom. Do smbd and winbindd really write to it? (According to man urandom this is technically possible, but IMHO still surprising.) I was just as surprised as you. I also checked whether it made any sense at all, and since it /could/ be used, I allowed it (I tried just 'r', but AppArmor still issued a DENIED).
As to the reason for the RW access, that's a question for SerNet -- I've not delved into the Samba code.
/var/cache/samba/ rw,
The write (mkdir) is already allowed in abstractions/samba. Good to know -- I missed that.
That means we'll only need to add read permissions (directory listing). Shouldn't be a serious problem, but I'm still slightly surprised that you need them - AFAIK you are the first one with that requirement. (Wild guess: maybe related to the smb_tmp_krb5.* files in that directory?) Most likely, yes. But to be fair, I've not tested the behaviour only allowing 'w'.
/var/cache/samba/smb_krb5/ rw, /var/cache/samba/smb_krb5/* rwk, /var/cache/samba/smb_tmp_krb5.* rwk,
Looks like everybody uses a different location for the krb5 files, so let's add one more location ;-) In this case, perhaps a bit of coordination with SerNet could reduce the level of entropy. If you can tell me the preferred location for those files under OpenSUSE and SLES, I'll contact them and pass the message.
/var/cache/samba/msg.lock/ rw, /var/cache/samba/msg.lock/* rwk,
These two are (mostly) covered in abstractions/samba already: /var/cache/samba/msg.lock/ rwk, /var/cache/samba/msg.lock/[0-9]* rwk,
Note that the second rule has [0-9]* instead of * - does this work for you, or do you see filenames not starting with a digit? No, that should work. At present, all filenames present in that folder on our test workstation follow the very simple pattern [0-9]{5}.
Some of these extra requirements may be due to the fact that SerNet uses different default locations during the build environment configuration phase, or enables some options at that time that are not active in the SUSE builds (personal hypothesis).
Yes, possibly - but even if I asked some questions about your profile additions, I'm quite sure that I can get them merged upstream. That's great news!
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407#c5
--- Comment #5 from Bjoern Jacke
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407#c6
--- Comment #6 from Philippe Andersson
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407#c7
--- Comment #7 from Philippe Andersson
participants (1)
-
bugzilla_noreply@novell.com