Bug#905437: libreoffice-common: AppArmor denies access to mesa shader cache
Vincas Dargis: > Cool, I will work on MR. :))) Also, would be good to have a 2.13.x upstream release with the fixes/improvements we need. > "Why not" could be "don't want to manage backports too much" :) . Right, at least not without being aware of a real need. Cheers, -- intrigeri
Bug#905437: libreoffice-common: AppArmor denies access to mesa shader cache
Vincas Dargis: > intrigeri, are we getting AppArmor 3 in Buster, Impossible to predict at this point. > or else maybe we could backport `mesa` abstraction into AppArmor > 2.13? Why not. Create a MR or file a bug against src:apparmor? Cheers, -- intrigeri
Bug#887593: More apparmor="ALLOWED" messages in syslog.
Vincas Dargis: > intrigeri, could we get opencl abstractions in 2.13, or we are expecting to > get AppArmor 3 in Buster? Sure, gimme a bug against src:apparmor :) > BTW I have proposed update to use `dri-enumerate` abstraction and remove > backported rule: > https://gerrit.libreoffice.org/#/c/58589/ If I'm supposed to act on this, please clarify what I should do, otherwise ignore this sentence. Cheers, -- intrigeri
Bug#883800: Ubuntu stance on disabling apparmor profiles
Hi, Rene Engelhard: > On Mon, Feb 26, 2018 at 06:43:18PM +0100, Olivier Tilloy wrote: >> oSoMoN: but, complain mode may be noisy for people who >> don't care about apparmor >> oSoMoN: so, the idea is, in Ubuntu, if the profile is good >> enough to use in the default install of the package, it is enforce. if >> the profile can't really be turned on by default for *reasons* (eg, >> firefox, libreoffice), ship it disabled >> oSoMoN: if the profile is installed via some other means >> and is 'in progress', eg, apparmor-profiles, then install in complain >> mode > And the profile here IS in-progress. Or why do we constantly find new > stuff which needs to be fixed? :) > And disabling it would hide it alltogether and bugs like > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887593 wouldn't even > be filed, thus not knowing what to do until it breaks for users as it > happened for your 5.4.5 packages (and our 5.4.3 packages) > There also is still stuff hidden by complain that would break if it's in > enforce. […] As far as the Debian Buster development cycle is concerned I propose: 1. Ship the profiles that are WIP but not too bad already in enforce mode until the Buster freeze, so that we learn about remaining issues, have a chance to fix them and to draw a conclusion based on actual data later on (see below). 2. Around the Buster freeze, look at how the rate of bug reports has evolved and decide what to do for Buster based on that. E.g. say there's been no new bug report about these profiles since 3 months, and the remaining known issues are acceptable, ship them enforced in Buster; otherwise, disable them by default in Buster. 3. Anyone importing/backporting the package from testing/sid (e.g. uploaders to stretch-backports, Ubuntu maintainers) shall make their own informed decision. In most cases it's probably a good idea to disable the AppArmor profiles in backports and stable distro releases until we reach a decision on #2. Cheers, -- intrigeri
Bug#883800: libreoffice-common: Please re-enable the AppArmor profiles
intrigeri: > Rene Engelhard: >> done already, though in complain mode.. > Thanks! I'll follow up on the next steps on a new bug report, quoting > the useful bits from this one :) FTR that's #886548.
Bug#886548: libreoffice-common: Try to ship all AppArmor profiles in enforce mode
Package: libreoffice-common
Version: 1:5.4.4-1
Severity: wishlist
Hi,
libreoffice-common 1:5.4.4-1 stopped disabling all profiles but the
oosplash and soffice.bin profiles are still shipped in complain mode.
This bug report is meant to track and discuss what needs to be done to
ship them in enforce mode instead. See #883800 for the beginning of
this conversation.
The remaining blocker seems to be autopkgtests being broken by
AppArmor, due to using custom paths:
René Engelhard wrote:
> intrigeri wrote:
>> You mentioned something elsewhere about the LibreOffice test suite
>> being possibly affected by this change. Could you please point me at
>> an example of this problem? I could investigate. In general, test
> I've not *seen* this problem yet, but I can imagine it/foresee it.
>> AppArmor policy. Now, runtime tests such as autopkgtests may be
>> affected; if needed I could take a look.
> Exactly.
> From
> https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/20171206_231513/log.gz:
> [...]
> [build JUT] sc_unoapi_6
> S=/tmp/autopkgtest-lxc.tpv162wi/downtmp/build.hf5/src && I=$S/instdir &&
> W=$S/workdir && rm -rf $W/JunitTest/sc_unoapi_6/user && mkdir -p
> $W/JunitTest/sc_unoapi_6/user/user && cp
> $S/qadevOOo/qa/registrymodifications.xcu
> $W/JunitTest/sc_unoapi_6/user/user/ &&
> (/usr/lib/jvm/default-java/bin/java -Xmx64M -classpath
> "$W/JavaClassSet/JunitTest/sc_unoapi_6:/usr/share/java/junit4.jar:/lib::/usr/lib/libreoffice/program/classes/jurt.jar:/usr/lib/libreoffice/program/classes/test.jar:/usr/lib/libreoffice/program/classes/ScriptProviderForJava.jar:/usr/lib/libreoffice/program/classes/XMergeBridge.jar:/usr/lib/libreoffice/program/classes/xmerge.jar:/usr/lib/libreoffice/program/classes/ridl.jar:/usr/lib/libreoffice/program/classes/test-tools.jar:/usr/lib/libreoffice/program/classes/unoloader.jar:/usr/lib/libreoffice/program/classes/report.jar:/usr/lib/libreoffice/program/classes/unoil.jar:/usr/lib/libreoffice/program/classes/hsqldb.jar:/usr/lib/libreoffice/program/classes/table.jar:/usr/lib/libreoffice/program/classes/smoketest.jar:/usr/lib/libreoffice/program/classes/ScriptFramework.jar:/usr/lib/libreoffice/program/classes/java_uno.jar:/usr/lib/libreoffice/program/classes/ConnectivityTools.jar:/usr/lib/libreoffice/program/classes/query.jar:/usr/lib/libreoffice/program/classes/OOoRunner.jar:/usr/lib/libreoffice/program/classes/sdbc_hsqldb.jar:/usr/lib/libreoffice/program/classes/juh.jar:/usr/lib/libreoffice/program/classes/form.jar:/usr/lib/libreoffice/program/classes/commonwizards.jar"
> -Dorg.openoffice.test.arg.env=LD_LIBRARY_PATH"${LD_LIBRARY_PATH+=$LD_LIBRARY_PATH}"
> -Dorg.openoffice.test.arg.user=file://$W/JunitTest/sc_unoapi_6/user
> -Dorg.openoffice.test.arg.workdir=$W/JunitTest/sc_unoapi_6/user
> -Dorg.openoffice.test.arg.postprocesscommand=$S/solenv/bin/gdb-core-bt.sh
> -Dorg.openoffice.test.arg.soffice="path:/usr/lib/libreoffice/program/soffice"
> -Djava.library.path=/usr/lib/ure/lib
> -Dorg.openoffice.test.arg.sce=$S/sc/qa/unoapi/sc_6.sce
> -Dorg.openoffice.test.arg.tdoc=$S/sc/qa/unoapi/testdocuments
> -Dorg.openoffice.test.arg.xcl=$S/sc/qa/unoapi/knownissues.xcl
> org.junit.runner.JUnitCore org.openoffice.test.UnoApiTest >
> $W/JunitTest/sc_unoapi_6/done.log 2>&1 || (cat
> $W/JunitTest/sc_unoapi_6/done.log && echo "to rerun just this failed
> test without all others, run:" && echo && echo "make
> JunitTest_sc_unoapi_6" && echo && echo "cd into the module dir to run
> the tests faster" && echo "Or to do interactive debugging, run two
> shells with:" && echo && echo "make debugrun" && echo "make
> gb_JunitTest_DEBUGRUN=T JunitTest_sc_unoapi_6" && echo && false))
> [...]
> Note e.g. the -Dorg.openoffice.test.arg.user. Similar (more like what
> was in the bug report in the first place) for the C++ (Unit)tests which
> are not (yet) ran in autopkgtest.
> From my current 6.0.0 beta2 testbuild (yes, that is local):
> [build CUT] sw_ooxmlexport4
> S=/data/rene/git/LibreOffice/libreoffice-6-0 && I=$S/instdir &&
> W=$S/workdir &&mkdir -p $W/CppunitTest/ && rm -fr
> $W/CppunitTest/sw_ooxmlexport4.test.user && cp -r $W/unittest
> $W/CppunitTest/sw_ooxmlexport4.test.user &&rm -fr
> $W/CppunitTest/sw_ooxmlexport4.test.core && mkdir
> $W/CppunitTest/sw_ooxmlexport4.test.core && cd
> $W/CppunitTest/sw_ooxmlexport4.test.core && (
> LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program":$W/UnpackedTarball/cppunit/src/cppunit/.libs
> MALLOC_CHECK_=2 M
Bug#883800: libreoffice-common: Please re-enable the AppArmor profiles
Rene Engelhard: > done already, though in complain mode.. Thanks! I'll follow up on the next steps on a new bug report, quoting the useful bits from this one :) Cheers, -- intrigeri
Bug#882597: [pkg-apparmor] Bug#882597: libreoffice: Failed to start when apparmor is running because of user rights
intrigeri:
> Rene Engelhard:
>>> that everyone else can't benefit from AppArmor security benefits
>>> due to that, so I'm leaning towards:
>>>
>>> 1. keep the AppArmor profile enforced by default, so the vast
>>> majority of users benefit from it;
>>> 2. ensure the AppArmor profile supports customization and
>>> affected users can learn how to tweak it; in this case,
>>> I think adding in README.Debian "add your custom
>>> env:UserInstallation to @{libo_user_dirs}" would be sufficient.
>>>
>>> What do you think? If you agree with my reasoning, then I could
>>> provide a patch to implement the proposed change in README.Debian.
>> Would be nice.
> Great. I'll do this then :)
#883800
Cheers,
--
intrigeri
Bug#883800: libreoffice-common: Please re-enable the AppArmor profiles
Package: libreoffice-common
Version: 1:5.4.3-4
Severity: wishlist
Tags: patch
Hi,
following up on our conversation on #882597, here is a patch series
that documents how advanced users can adjust the included AppArmor
profiles to cope with their local setup, and re-enables the AppArmor
profiles by default.
What do you think?
If you want, I could also document in README.Debian how to disable one
(or all) of these profiles, which might be useful in case a user
prefers not to bother adjusting the profiles to their setup.
You mentioned something elsewhere about the LibreOffice test suite
being possibly affected by this change. Could you please point me at
an example of this problem? I could investigate. In general, test
suites run at package build time are not affected by AppArmor because
they run the binaries for a (build-) path that is not covered by the
AppArmor policy. Now, runtime tests such as autopkgtests may be
affected; if needed I could take a look.
Finally, if this AppArmor policy proves to break too many things for
less technical users, I will support going back to
ENABLE_APPARMOR_PROFILES=n without any afterthought: one of the key
aspects of how we've approaching AppArmor in Debian is that we want to
avoid creating a culture of "AppArmor breaks stuff so I always disable
it entirely".
Cheers,
--
intrigeri
>From 1afd67ec9f4e68e619f4e707bd62142ba8de78cf Mon Sep 17 00:00:00 2001
From: intrigeri <intrig...@boum.org>
Date: Thu, 7 Dec 2017 17:34:48 +
Subject: [PATCH 1/2] * debian/README.Debian: document how to debug and
customize the included AppArmor profiles
---
README.Debian | 18 ++
1 file changed, 18 insertions(+)
diff --git a/README.Debian b/README.Debian
index 815ac735..1493746d 100644
--- a/README.Debian
+++ b/README.Debian
@@ -17,6 +17,7 @@ Font problems
Why are the menu fonts smaller than in older versions?
Changing the default user interface font typeface for non-KDE/Gnome desktops
Disabling the splash screen
+AppArmor problems
More information about LibreOffice in Debian
@@ -278,6 +279,23 @@ If you don't like the splash screen staying in front of other windows while
LibreOffice is loading, you can disable it by editing
/etc/openoffice/sofficerc. Change Logo=1 to Logo=0.
+AppArmor problems
+=
+
+LibreOffice in Debian ships with AppArmor profiles:
+
+/etc/apparmor.d/usr.lib.libreoffice.*
+
+To debug issues with these AppArmor profiles, see:
+
+https://wiki.debian.org/AppArmor/Debug
+
+If you are using custom settings such as a custom env:UserInstallation
+directory, you may need to adjust them to match your local setup.
+In this example, you would need to add your custom
+env:UserInstallation to @{libo_user_dirs} in the
+usr.lib.libreoffice.program.soffice.bin profile.
+
More information about LibreOffice in Debian
===
Please read the official README.gz (in the same directory as this file), too.
--
2.15.1
>From 070fba71b11f1fb6ebc4e229f50c18ff53deea52 Mon Sep 17 00:00:00 2001
From: intrigeri <intrig...@boum.org>
Date: Thu, 7 Dec 2017 17:35:13 +
Subject: [PATCH 2/2] enable the AppArmor profiles back
We disabled them due to #882597. After looking closer at the problem that
triggered this bug report, it appeared that it only affects technical users with
highly specific needs, such as passing a custom env:UserInstallation on the
command line. Now that README.Debian documents how to adjust the AppArmor
profiles to cope with such needs, it seems safe to re-enable them so that
everyone else can benefit from the added security by default.
---
rules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/rules b/rules
index edf08a44..0b2282ff 100755
--- a/rules
+++ b/rules
@@ -532,7 +532,7 @@ BUILD_PPC64EL=y
BUILD_ARM64=y
SYSTEM_STUFF += gpgmepp
INSTALL_APPARMOR_PROFILES=y
-ENABLE_APPARMOR_PROFILES=n
+ENABLE_APPARMOR_PROFILES=y
# Default flags to pass to configure
CONFIGURE_FLAGS= \
--
2.15.1
Bug#882597: libreoffice: Failed to start when apparmor is running because of user rights
Hi Vincas, Vincas Dargis: > It's the same story as with Thunderbird's #882218, we really should think > about > adding customization points to these GUI applications. Sure, on the long term allowing advanced users to add drop-in snippets instead of having to edit conffiles would be great; I'm glad you're working on it! But I don't want to block on this and for now I'll simply document the existing tunable as this sounds good enough on the short/medium term: while it's definitely not my preferred config management system, editing default conffiles shipped in /etc is a well established system administration practice, and it should not come as a surprise to any advanced user who passes a custom profile path to LibreOffice on the command line. Cheers, -- intrigeri
Bug#882597: libreoffice: Failed to start when apparmor is running because of user rights
Hi, Meta: these bits should not be needed once I've implemented my proposal, but regardless, I think it's worth spreading AppArmor knowledge in Debian :) Rene Engelhard: > so aa-complain soffice.bin -d $(PKGDIR)-common/etc/apparmor.d/ Yes, this should work. > etc? (Maybe with full path?) If the above does not work, yes. > One could also just patch it :-) Absolutely. Cheers, -- intrigeri
Bug#882597: [pkg-apparmor] Bug#882597: libreoffice: Failed to start when apparmor is running because of user rights
Hi Rene,
(sorry for the delay, I was focusing on other issues that felt higher
priority than this one, since I've already workaround'ed the
problem successfully.)
Rene Engelhard:
>> that everyone else can't benefit from AppArmor security benefits
>> due to that, so I'm leaning towards:
>>
>> 1. keep the AppArmor profile enforced by default, so the vast
>> majority of users benefit from it;
>> 2. ensure the AppArmor profile supports customization and
>> affected users can learn how to tweak it; in this case,
>> I think adding in README.Debian "add your custom
>> env:UserInstallation to @{libo_user_dirs}" would be sufficient.
>>
>> What do you think? If you agree with my reasoning, then I could
>> provide a patch to implement the proposed change in README.Debian.
> Would be nice.
Great. I'll do this then :)
If you don't mind, once I have a patch I won't build a test package
locally: I suspect src:libreoffice takes a while to build, and my
changes should boil down to setting ENABLE_APPARMOR_PROFILES=y and
adding README.Debian that dh_installdocs should pick up automatically.
Cheers,
--
intrigeri
Bug#882597: libreoffice: Failed to start when apparmor is running because of user rights
Hi,
(context for pkg-apparmor folks: the last upload of libreoffice to
sid disabled the AppArmor profile by default due to #882597)
Rene Engelhard:
> On Fri, Nov 24, 2017 at 02:33:20PM +0100, Michael Ott wrote:
>> start libreoffice with
>> soffice -env:UserInstallation=file:///srv/home/michael/tmp/
>> does not work. Home folder is srv/home/michael
> Sigh. Feared something like this.
> So you try to access stuff outside the LO profile?
My understanding is that Michael tries to access stuff inside his user
LO profile path, *but* that profile is stored in a custom location
which is not supported by the AppArmor profile. When such issues
arise, the general thought process in distros that use AppArmor is:
Is it common to use such a custom location?
→ In this case, I don't know. I assume Rene will know better :)
How technical are the users likely to do such customization?
→ It seems to me that such customization requires reading
the --help output and then typing special commands in a terminal,
which counts as "rather technical".
Then, depending on the answer to the two above questions, either
have the AppArmor policy allow such customization by default (if
possible while keeping the confinement meaningful), or disable the
AppArmor profile by default, or keep the AppArmor profile enforced
by default and assume the people suffering from its limitations will
be able to workaround it (either by disabling the AppArmor profile
or by adjusting it locally).
→ In this case, I would argue that we're talking about a corner
case, that only rather advanced users will hit, and I find it sad
that everyone else can't benefit from AppArmor security benefits
due to that, so I'm leaning towards:
1. keep the AppArmor profile enforced by default, so the vast
majority of users benefit from it;
2. ensure the AppArmor profile supports customization and
affected users can learn how to tweak it; in this case,
I think adding in README.Debian "add your custom
env:UserInstallation to @{libo_user_dirs}" would be sufficient.
What do you think? If you agree with my reasoning, then I could
provide a patch to implement the proposed change in README.Debian.
>> 3. Switch of apprmor with service apparmor teardown
Michael, you don't have to entirely disable AppArmor on your system :)
You can disable a specific AppArmor profile with the aa-disable command.
> Unfortunately there seems no way to install a profile but keep it
> "unconfined), only to just disable it..
Actually there is.
If the AppArmor profile is shipped in the upstream tarball, at package
built time, you can either use aa-complain or manually patch the
profile, for example:
https://anonscm.debian.org/cgit/collab-maint/apparmor-profiles-extra.git/tree/debian/rules#n20
Otherwise, if the AppArmor profile lives in the debian/ directory,
you can directly edit it so it looks like this:
/usr/bin/irssi flags=(complain) {
Cheers,
--
intrigeri
