[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 <suse-beta@cboltz.de> --- These profiles are not really "SUSE" or "openSUSE" profiles. They are maintained in upstream AppArmor - of course with a big influence from the openSUSE side, but also from other distros. The goal for these profiles is to make sure that they work everywhere. 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? If your additions aren't too exotic ;-) there's a good chance that I can get the needed rules included upstream so that you can simply use the official profiles. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407 Bjoern Jacke <bjacke@samba.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jmcdonough@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1166407 Bjoern Jacke <bjacke@samba.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bjacke@samba.org -- 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#c2 --- Comment #2 from Philippe Andersson <philippe.andersson@iba-group.com> --- (In reply to Christian Boltz from comment #1)
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 <jmcdonough@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |samba-maintainers@SuSE.de -- 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#c3 --- Comment #3 from Christian Boltz <suse-beta@cboltz.de> --- (In reply to Philippe Andersson from comment #2)
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 <philippe.andersson@iba-group.com> --- (In reply to Christian Boltz from comment #3)
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 <bjacke@samba.org> --- the rw requirement of urandom is probably coming from gnutls and not samba directly (the older Samba version of SLES doesn't use gnutls for crypto yet). For differences of other paths in the apparmor profile it looks a bit pointless to me to try to include all possible different possibe paths being used by different packagers upstream. The requirements here can change from version to version also. For SUSE specifically I would really appreciate if the apparmor profiles would consistently all be packaged along with the package packages that they are made for and not as part of the apparmore package itself. Currently some are still shipped from the apparmor package and some are shipped with the package they're made for. For the Samba package of SUSE I suggested moving the samba apparmore profile accordingly to Jim some days ago. -- 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#c6 --- Comment #6 from Philippe Andersson <philippe.andersson@iba-group.com> --- As promised, here is my feedback regarding the behaviour of domain member servers and AD domain controllers. First, the good news is that we've not noticed any specificity to these roles at this stage in terms of required AppArmor profiles. *But* we discovered that an extra line needed to be added to 'usr.sbin.nmbd' in order to allow the daemon to generate a namelist dump when requested to through SIGHUP (debugging feature): /var/cache/samba/namelist.debug rwk, That entry does not appear to have been included in any official OpenSUSE update or upgrade yet. -- 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#c7 --- Comment #7 from Philippe Andersson <philippe.andersson@iba-group.com> --- OK -- two more issues have been spotted. 1./ current AppArmor profiles prevent Samba log rotation ---------------------------------------------------- In /etc/apparmor.d/abstractions/samba (latest available stable version: 15.1, fully patched), we see this: /var/log/samba/* w, In order to allow rotation of log.smbd, log.nmbd, etc. to *.old, that should be: /var/log/samba/* rwk, (not sure the 'k' is strictly needed) 2./ the AD DC process itself has no AppArmor profile ------------------------------------------------ The main process on a Samba4 AD DC is '/usr/sbin/samba'. That process doesn't have *any* AppArmor profile, even though I suspect it would be the most critical / vulnerable one. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com