[apparmor] New LibreOffice Profile

[Christian Boltz]

Hello,

Am Montag, 6. April 2015 schrieb Bryan Quigley:
> > These are looking impressive;
> 
> Thanks!

I can only agree ;-)

I just copied the profiles to /etc/apparmor.d/, switched them to 
complain mode - well, I tried to, but the excessive variable definition 
in the soffice.bin profile uncovered a bug in aa-complain ;-)

[...]
  File "/home/cb/apparmor/HEAD-clean/utils/apparmor/aa.py", line 3272, in store_list_var
    var[list_var] = set(var[list_var] + vlist)
TypeError: unsupported operand type(s) for +: 'set' and 'list'

It seems adding to a variable is broken (in both trunk and 2.9 branch) :-(

Therefore I manually added the complain flag everywhere (and also 
fixed the tools, but that's another mail ;-)

BTW: On openSUSE, LibreOffice is installed to /usr/lib64/... on 64bit 
systems, so you might want to change the profile names to /usr/lib*/...

> >> I added profiles for LibreOffice's built-in launching programs
> >> which
> >> make some of the abstractions/ubuntu useless.
> > 
> > I did wonder if some of the xdg-open kinds of rmPUx permissions
> > might be replaced with the sanitized_helper that ubuntu uses
> > elsewhere.
> Quite possible, but I was trying to make it more cross distro.

Oh, at least openSUSE ships /etc/apparmor.d/abstractions/ubuntu-* (as 
contained in bzr and the release tarball). I'm not too happy about the 
naming scheme, but they can be useful nevertheless ;-)
(and I won't object if we get them renamed one day)

That said - maybe we should make sanitized_helper a global (Px'able) 
profile instead of hiding it in abstractions/ ? That would also be an 
optimization, because every profile that uses it currently keeps its own
copy (as child profile) in the kernel.

> >Another option is shipping them in the package, but disabled by
> >default via /etc/apparmor.d/disabled, like Ubuntu does with firefox 
> >and rsyslog now.

Another interesting discussion point. I'm not a fan of shipping profiles 
disabled or in complain mode, because it could give users a false sense 
of feeling protected.

> I'll approach LibreOffice upstream to see if we can get it included
> there.. then all distros could inherit the right one for the version
> they are using.

Some notes:

/usr/lib*/libreoffice/program/open-url {
  owner @{HOME}/.config/libreoffice{,dev}/4/user/uno_packages/cache/log.txt     rw,

and

/usr/lib*/libreoffice/program/senddoc {
  owner @{HOME}/.config/libreoffice{,dev}/4/user/uno_packages/cache/log.txt     rw,

You are hardcoding the version number here.

/usr/lib*/libreoffice/program/xpdfimport {
  owner /tmp/*          r,  #Seems to need to read file created with pattern /tmp/RRRRRR    

Trailing space after the comment.

  owner @{HOME}/.config/libreoffice{,dev}/4/user/uno_packages/cache/log.txt     rw,

And another hardcoded version number ;-)


/usr/lib*/libreoffice/program/soffice.bin {

  owner @{HOME}/.config/gtk-3.0/bookmarks   r,  #Make bookmarks work

Here's a hardcoded gtk version.

  /usr/lib/@{multiarch}/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner rmPUx,
  owner @{HOME}/.cache/gstreamer-1.0/**  rw,

And another version number, this time gstreamer.

Besides that, the file has an interesting[tm] mix of tabs and spaces, 
and also some trailing spaces in the copyright header.


So far, so good.

After proofreading the profiles, I actually tested them - and have several
additions ;-)

I avoided usage of globbing and abstractions in most cases to make clear
what exactly happens. I'm sure you can (and want to) change that.

+  /bin/bash Cx,   # feel free to use mrix and include the permissions in the main profile (probably just "/dev/tty w")
+  /etc/cups/ppd/*.ppd r,
+  /home/*/.execooo* mrw,   # probably tempfiles, * are 6 random chars
+  /home/*/.icons/*/cursors/* r,   # system-wide cursors are boring *g*  (something for an abstraction? which one?)
+  /home/*/.recently-used rwk,
+  /home/cb/**.odt k,   # looks like you should add lock permissions for all allowed file types
+  /home/cb/**.txt k,
+  /proc/*/status r,
+  /usr/lib64/libreoffice/program/__pycache__/ ra,   # the "usual" problem - the kernel first checks AppArmor, then the directory permissions
+  /usr/lib64/libreoffice/share/extensions/lightproof-en/pythonpath/__pycache__/ ra, # same here
+  /usr/lib64/libreoffice/share/uno_packages/cache/stamp.sys ra, # same here
+  /usr/lib64/pkcs11/gnome-keyring-pkcs11.so mr,   # maybe abstractions/p11-kit instead of this and the following lines
+  /usr/lib64/pkcs11/p11-kit-trust.so mr,
+  /usr/lib64/python3.4/lib-dynload/_heapq.cpython-34m.so mr,  # abstractions/python ?
+  /usr/lib64/python3.4/lib-dynload/_socket.cpython-34m.so mr,
+  /usr/lib64/python3.4/lib-dynload/array.cpython-34m.so mr,
+  /usr/share/cantarell-fonts/conf.avail/*.conf r,   # something that should be in abstractions/fonts?
+  /usr/share/fonts-config/conf.avail/*.conf r,
+  /usr/share/icu/54.1/icudt54l.dat r,
+  /usr/share/libexttextcat/*.lm r,
+  /usr/share/libexttextcat/fpdb.conf r,
+  /usr/share/p11-kit/modules/gnome-keyring.module r,
+  /usr/share/p11-kit/modules/p11-kit-trust.module r,

+  profile /bin/bash flags=(complain) {
+    #include <abstractions/base>
+
+    /bin/bash mr,
+    /dev/tty rw,
+    /home/*/ r,
+    /proc/meminfo r,
+
+  }


Oh, and let me warn you that aa-logprof will merge your nice variable 
definition into the easily readable ;-))

@{libo_base} = /usr/lib*/libreoffice/
@{libreoffice_ext} = [pP][sS][dD] [pP][nN][gG] [sS][vV][gG] [xX][lL][sSwWtT]{,x,X} [cCtT][sS][vV] [jJ][pP][eE][gG] [pP][oO][tT]{,m,M} [xX][mMsS][lL] [uU][oO][fFtTsSpP] [rR][tT][fF] {,f,F}[oO][dDtT][tTsSpPbBgGfF] [pP][pP][tTsS]{,x,X} [tT][iI][fF][fF] [tT][iI][fF] [tT][xX][tT] [jJ][pP][gG] [sS][vV][gG][zZ] [mM][mM][lL] [dD][iIbB][fF] [sS][lL][kK] [pP][dD][fF] [sS][wW][fF] {,x,X}[hH][tT][mM]{,l,L} [dD][oO][cCtT]{,x,X}
@{libreoffice_user_directories} = /mnt @{HOME} /media


BTW: Interestingly, oosplash keeps running all the time (and killing it
kills LibreOffice). Should oosplash also have a profile?


Regards,

Christian Boltz

PS: Speaking about hardcoded version numbers - I wonder if the (random)
    sig needs an update. I expect some KDE4 vs. Plasma 5 flamewars 
    soon ;-)
-- 
I appreciate what you're trying to do - the Rules of OpenSuSE say that
the project has to have at least one KDE3 vs KDE4 flamewar per quarter,
and at least one KDE vs GNOME mudwrestling match a year.
[Will Stephenson in opensuse-factory]