Too restrictive mbsync apparmor profile

Bug #2130393 reported by Athos Ribeiro
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
Confirmed
High
Unassigned
Questing
New
Undecided
Unassigned
isync (Ubuntu)
Confirmed
High
Unassigned
Questing
Confirmed
High
Unassigned

Bug Description

There is a new apparmor profile for mbsync.

- It restricts the binary to operating under the user's $HOME/Mail directory. However, there is no default configuration nor documentation instructing users to use that directory for their local Maildirs AFAICT (i.e., one would need to understand they are being restricted by apparmor and read the apparmor profile in order to be able to use mbsync).

- It only allows reading the configuration file from ~/.mbsyncrc. The newest version in the archive (rr) explicitly says (manpage) that the preferred configuration file path is under ~/.config/isyncrc. This also hinders the -c option to pass a custom configuration file.

- Finally, it hinders usage of some features such as PassCmd and UserCmd to run specific commands to fetch authentication data (e.g., from the gnome keyring)

I understand that the profile provides a great security layer, but in this case, isn't it being too restrictive to the point it hinders usage? IMHO we should either loosen the restrictions or document the restrictions within the isync package, probably in the mbsync manpage as well, and possibly ship the profile with isync instead to give users more visibility.

See users having issues with the profile in https://askubuntu.com/questions/1549571/mbsync-has-stopped-working-with-weird-permission-error

LP: #2111196 is also related

Athos Ribeiro (athos)
description: updated
Revision history for this message
John Johansen (jjohansen) wrote :

so yes the profile should be updated to allow the common locations, and common commands like some common commands like PassCmd . It shouldn't be updated to allow just any location or to be able to run an arbitrary command.

Documenting the restrictions, so a user has direction on how to update local policy to allow local configuration changes is also a good idea.

Shipping the profile with the isync package is also a possibility if needed.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apparmor (Ubuntu):
status: New → Confirmed
Changed in isync (Ubuntu):
status: New → Confirmed
Revision history for this message
Agathe Porte (gagath) wrote :

I am also affected by this problem, because my mail is in ~/.mail instead of ~/Mail and also because of the use of PassCmd which is currently impossible with the current apparmor profile.

After tweaking the apparmor override file a little, I can see that the PassCmd is always invoking a /usr/bin/dash shell even if a single command is specified (secret-tool). I tweaked the rule override file in /etc/apparmor.d/local/mbsync with the following:

owner @{HOME}/dotfiles/mutt/.mbsyncrc r,

# Required for PassCmd to call secret-tool
/usr/bin/dash mixr,
/usr/bin/secret-tool mixr,

However to call secret-tool to interact with the system keyring I need to find out how to allow the access for dbus as well according to the apparmor logs:

janv. 21 13:48:09 artemis kernel: audit: type=1400 audit(1768999689.179:425): apparmor="DENIED" operation="connect" class="file" profile="mbsync" name="/run/user/1000/bus" pid=7287 comm="pool-0" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000

This profile is indeed very restrictive and unworried users might even put their password in plaintext in their configuration file to alleviate the PassCmd issue, which might be worse than having the apparmor profile enabled in the first place.

Upping importance to "high" to give more visibility for all Ubuntu users impacted. The profile does not seem to exist in Debian proper so this is an Ubuntu issue only.

Changed in isync (Ubuntu):
importance: Undecided → High
Agathe Porte (gagath)
Changed in isync (Ubuntu Questing):
importance: Undecided → High
status: New → Confirmed
Revision history for this message
Athos Ribeiro (athos) wrote :

I am matching the priority in apparmor since the profile is currently shipped there.

Changed in apparmor (Ubuntu):
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.