Access to Secret daemon is missing

[dcaliste]

I would like to add a profile to give access to the Secret daemon. The use case is the email signature process:

• compose an email with signature, and select send,
• the gpgme library (see QMF plugin for cryptography) will end up calling the /usr/bin/pinentry to ask for the passphrase of the signing key (this is done internally by contacting the gpg-agent on a socket,
• the pinentry program (see gnupg plugin in sailfish-secret) will converse with the Secret daemon to inquire the user for its passphrase or look at the cached value in secret storage. This is done through a peer-to-peer DBus connexion via a socket. It will require access to the secret database storage also.
• the pinentry will send back the passphrase to gpgme so the signature can proceed.

What should be granted as permissions to allow this ? @rainemak, @tomin or @pvuorela if you may give some insights on the matter please?

[chriadam]

From IRC, dcaliste said he's happy to investigate, but would appreciate some hints about how to get started determining what is required, e.g. how to run the thing in CLI with verbose output so I know which access is blocked by firejail. Also I guess what things require modification, and what the syntax is for allowing dbus access etc.

[spiiroin]

"executes /usr/bin/pinentry" -> "private-bin pinentry" makes the executable visible (seemingly not needed now, but that is a bug). Then depending on how it is executed shell access might be needed (not if it is just exec*() call to run elf binary)

"peer-to-peer DBus connection" -> "protocol unix" (but this is allowed by default atm); probably "whitelist /path/to/connect/socket" or so.

"require access to the secret database" -> access via suitable "whitelist" / "private-data" depending on whether the data is in privileged data dir or not. If the database / directory where it resides is generated dynamically, by this sw -> adding "mkdir /whitelisted/path" might be necessary (firejail will create the directory before/during setting up the sandbox -> sandboxed app does not need write access to parent dirs because the directory it actually needs already exists)

debugging: there is "sailjail --trace" shortcut option -> instructs firejail to generate dbus / file access logs. The logs are probably very verbose, but usually at least missing dbus access is easy to spot. Alternatively one can run sailjail in verbose mode -> firejail command line is printed out -> that can be used as reference for lower level firejail debugging.

[dcaliste]

Thanks @spiiroin with your help I should be able to go on.

[dcaliste]

@spiiroin, some news on the front here.

To be able to sign, and use the GnuPG framework in general, one should have access to ~/.gnupg/ directory. This directory is blacklisted in disable-common.inc in Base.permissions. So my basic question is : can we use a noblacklist in the current sailjail framework before the Base permission file is called ?