Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)
Hi,
On Fri, Nov 27, 2020 at 07:25:19PM +0100, Jörg Sommer wrote:
> Rene Engelhard schrieb am Fr 27. Nov, 16:48 (+0100):
> > > Package: libreoffice
> >
> > No, libreoffice does not contain anything except dependencies. Do you mean libreoffice-core?
>
> I don't know which package contains this functionality. And it shouldn't
> matter. I file a bug report to a *project* and I'm really don't know which
No, you file it against a *package*. If there was no libreoffice dummy package
reporing it against libreoffice would simply result in a bug for "unknown-package",
there is no "filing against a project" in Debians BTS. :)
> You might view a bug report as an incident in a component
That's what "bug" implies, yes... And you filed it as a "normal" bug :)
> and would like to organize all bug reports.
Exactly.
> > How it is a bug when LO does what it's supposed to do in case people want to
> > sign their documents (with S/MIME, gpg is something else) *and which is
> > documented*?
>
> I didn't touch anything that had to do with signing. I've got a document
> as a mail attachment and hit enter. I use LibreOffice four or five times
> per year.
Me too :)
Anyways, that probably means it initializes xmlsecurity/nss and thus acesses this.
> To be fair I don't look at my logs.
You wrote in your initial report "I'm seeing many entries like these in my log:".
> But I get AppArmor messages via mail. That's why I've spotted this (and
> other) problems.
>
> > > operation="open" profile="libreoffice-soffice" name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 comm="soffice.bin" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=1000
> > > operation="file_lock" profile="libreoffice-soffice" name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000
> >
> > Access to the Mozilla profile is completely expected in how it's
>
> Yes, that's what you expect, but a) the AppArmor rules expect something
> else
They (apparently) miss key4.db, yes. Otherwise they allow "r" access.
"w" or "c" access shoudn't be allowed and yes, upstream acknowldeges it should probably
just be open "r"ead-only. (which is included in the IRC logs I sent in my other reply)
If you read what I wrote in my initial reply: I didn't deny that the profie might need
adaptions.
That doesn't change that you say in this bug that this access shouldn't happen at all,
which somewhat can agree with but as long as they use nss and don't want ~/.pki/nssdb
because there is no (GUI) key management tool for this this discussion is moot.
It's not Debians "job" to replace something integral like this which also probably affects
file format and standards by something else.
> and b) from a generic point of view, I as a software developer
> wouldn't expect any project accessing the internal files of another
> project. This makes any change very difficult, because you have to
> consider all possible external users if you touch anything. That's
> horrible.
Internal details are handled by the nss security library.
Which knows the format because it's it's native format.
(That's why the mozilla profile is used in the first place anyway, LO
just initializes possible locations.)
> > Key *management* is something LO should not do and cannot do anyway. (same with gpg)
>
> Yes, indeed. Why doesn't it use helper tools like openssl?
See my other reply. They care more about end-users with no clue
instead of "openssl" or "certutil" for that matter...
> It requests the tools for it.
... and LO doesn't do any key management either. It just initializes the XML
signing library, which uses nss. (and not openssl, which is IMHO bad,
I agree.)
> At least, I can tell (but this is another problem) LibreOffice crashes
> with gpg using tofu.
>
> apparmor="DENIED" operation="open" profile="libreoffice-soffice//gpg" name="/home/joerg/.gnupg/tofu.db" pid=708430 comm="gpg" requested_mask="wc" denied_mask="wc" fsuid=1000 ouid=1000
>
> If you don't care about it drop this. I've fixed it for me, so it doesn't
> bother me any more.
Again that "tofu" gpg thingy...
Is there any website or so recommending to set this?
This is not default and "normal" gpg just works. See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955271 where this already
was reported.
If you change options you also need to change other stuff if needed.
> … by using a private key store. So, you are telling me it's difficult,
Anything needing to sign stuff needs to access the private key store, wherever
that lies. Whether ~/.pki/nssdb or the firefox profile.
Also gnupg needs to access their own key store (and so does LO if signing a document with
gpg - via libgpgme -, also only in "r" mode;).
You are suggesting not to access any key store => no signing at all. (INSIDE the
document), not something like gpg --detach-sign.
And no, LO has no business of doing key management itself - as we agree
with.
(And before you come with security? Guess who requested and financed the "sign LO
documents with gpg" feature introduced in LO 6.0? Right, the BSI[1],see also
https://wiki.documentfoundation.org/ReleaseNotes/6.0#OpenPGP_document_signing_and_encryption)
> impossible and so on … and at the same time, I'm sitting here in front of
> neomutt and it tells me there's no problem. Why can a project with only
> one developer solve a problem that a project with multiple developers
> can't?
As said above in in my other reply a few days ago.
Because
a) neomutt uses openssl and expects key management for yoursel
b) as shown above and shown in my other reply with the IRC logs a few days ago
LibreOffice upstream doesn't necessarily care about sane things
or managing ~/.pki/nssdb with certutil, they simply care about the "DAU" end-user,
for which unfortunately the "nss key management" GUI is firefox...
As I said in my other mail a few days ago you ttbomk can use certutil to initialize
a ~/.pki/nssdb, stick a export MOZILLA_CERTIFICATE_FOLDER="~/.pki/nssdb" (I mentioned
MOZILLA_CERTIFICATE_FOLDER in my other reply, and this was also in the documentation
I mentioned) somwhere suitable and it'll pick up ~/.pki/nssdb?
Regards,
Rene
Reply to: