Bug#918820: msmtp: AppArmor profile makes passwordeval unusable
The updated Apparmor profile and debian/NEWS were proposed for integration: https://salsa.debian.org/kolter/msmtp/merge_requests/1 Regards, Simon
Bug#918820: msmtp: AppArmor profile makes passwordeval unusable
Package: msmtp Version: 1.8.1-2 Followup-For: Bug #918820 Hi, I just wanted to +1 the updated AppArmor profile attached to the bug report. I suspect there will be a number of users who have their msmtp configured with passwordeval as per the ArchLinux wiki [1], so supporting this configuration as part of Buster could reduce confusion. Thank you for the quick response and clarification in the BTS. It made it much easier to figure out what had happened to my msmtp setup. Cheers, tony [1] https://wiki.archlinux.org/index.php/msmtp#GnuPG
Bug#918820: msmtp: AppArmor profile makes passwordeval unusable
On 2019-01-10 9:54 a.m., Kai Weber wrote:
> * Simon Deziel :
>
>> Actually, please use this new attached profile which is identical in
>> purpose but uses better names.
>
> The profile works with the secret-tool solution.
Great, thanks for testing, I really appreciate it.
> If the maintainers choose to restrict the use of "secret helpers" to
> only gpg* and secret-tool than this should be mentioned in the
> documentation/README/NEWS.
I agree, it's worth mentioning in the doc. Those 2 helpers were selected
because they are mentioned in msmtp's man page. Authorizing more helpers
is doable but should be evaluated case by case.
Also, we cannot cover every use cases so for some folks if Apparmor gets
in the way, they can either tune the profile or disable it.
> Is there any decision yet that says where the restriction of
> AppArmor should be documented in Debian?
I would think that putting it in the README and NEWS is good enough.
> AppArmor restrictions might bring up a lot of bug reports in the
> future.
That is a good point and that's why it's important to tackle the common
use cases ASAP.
If it turns out to not be enough to please the users and maintainers it
is always be possible to ship the profile in complain mode. This would
make the security benefits an "opt-in" choice.
> One addition: I chose to place my logfiles into $XDG_CACHE_HOME, which
> by default is $HOME/.cache. I am no longer able to go this way. Should a
> user not allowed to write in any file at any place in it's home
> directory?
For the Apparmor profile to bring security, it needs to authorize just
enough to cover common use cases. Apparmor removes flexibility so it's a
matter of balancing security with convenience.
> This is my current setting
>
> logfile ~/.cache/msmtp/msmtp.log
You make a case for authorizing ~/.cache/msmtp. How about adding those
rules:
owner @{HOME}/.cache/msmtp/* r,
owner @{HOME}/.cache/msmtp/*.log wk,
> and the error is not very helpful because it never mentions AppArmor:
>
> msmtp: cannot log to /home/kai/.cache/msmtp/msmtp.log: cannot open:
> Permission denied
That is how Apparmor works unfortunately. Everything goes into dmesg.
Regards,
Simon
Bug#918820: msmtp: AppArmor profile makes passwordeval unusable
* Simon Deziel : > Actually, please use this new attached profile which is identical in > purpose but uses better names. The profile works with the secret-tool solution. If the maintainers choose to restrict the use of "secret helpers" to only gpg* and secret-tool than this should be mentioned in the documentation/README/NEWS. Is there any decision yet that says where the restriction of AppArmor should be documented in Debian? AppArmor restrictions might bring up a lot of bug reports in the future. One addition: I chose to place my logfiles into $XDG_CACHE_HOME, which by default is $HOME/.cache. I am no longer able to go this way. Should a user not allowed to write in any file at any place in it's home directory? This is my current setting logfile ~/.cache/msmtp/msmtp.log and the error is not very helpful because it never mentions AppArmor: msmtp: cannot log to /home/kai/.cache/msmtp/msmtp.log: cannot open: Permission denied
Bug#918820: msmtp: AppArmor profile makes passwordeval unusable
On 2019-01-09 8:57 p.m., Simon Deziel wrote:
> Could you give a try to the attached profile and report back?
Actually, please use this new attached profile which is identical in
purpose but uses better names.
Thanks,
Simon
# Author: Simon Deziel
#include
/usr/bin/msmtp flags=(attach_disconnected) {
#include
#include
#include
#include
#include
/usr/bin/msmtp mr,
/etc/aliasesr,
/etc/msmtprcr,
/etc/netrc r,
owner @{HOME}/.msmtp* r,
owner @{HOME}/.netrcr,
owner @{HOME}/.tls-crls r,
owner @{HOME}/.msmtp*.log wk,
/var/log/msmtpwk,
@{PROC}/@{pid}/loginuid r,
/tmp/ rw,
owner /tmp/*rw,
# to type password interactively
owner /dev/pts/[0-9]* rw,
# secret helpers
/{,usr/}bin/bash Cx -> helpers,
/{,usr/}bin/dash Cx -> helpers,
profile helpers {
#include
/{,usr/}bin/bash mr,
/{,usr/}bin/dash mr,
/tmp/rw,
owner /tmp/* rw,
/usr/bin/secret-tool PUx,
/usr/bin/gpg{,2} PUx,
}
#include
}
Bug#918820: msmtp: AppArmor profile makes passwordeval unusable
On 2019-01-09 11:52 a.m., Kai Weber wrote:
> passwordeval python -c "import keyring; print keyring.get_password('smtp',
> 'kai.we...@glorybox.de')"
> passwordeval secret-tool lookup service smtp username kai.we...@glorybox.de
The python version would be hard to secure and is probably not widely
used if I'm not mistaken. The secret-tool one should be common though
and needs work. Could you give a try to the attached profile and report
back?
Regards,
Simon
# Author: Simon Deziel
#include
/usr/bin/msmtp flags=(attach_disconnected) {
#include
#include
#include
#include
#include
/usr/bin/msmtp mr,
/etc/aliasesr,
/etc/msmtprcr,
/etc/netrc r,
owner @{HOME}/.msmtp* r,
owner @{HOME}/.netrcr,
owner @{HOME}/.tls-crls r,
owner @{HOME}/.msmtp*.log wk,
/var/log/msmtpwk,
@{PROC}/@{pid}/loginuid r,
/tmp/ rw,
owner /tmp/*rw,
# to type password interactively
owner /dev/pts/[0-9]* rw,
# secret helpers
/{,usr/}bin/bash Cx -> shell,
/{,usr/}bin/dash Cx -> shell,
profile shell {
#include
/{,usr/}bin/bash mr,
/{,usr/}bin/dash mr,
/tmp/rw,
owner /tmp/* rw,
/usr/bin/secret-tool PUx,
/usr/bin/gpg{,2} PUx,
}
#include
}
Bug#918820: msmtp: AppArmor profile makes passwordeval unusable
* Simon Deziel :
I did two tests. One with passwordeval using python, one with
passwordeval using secret-tool.
passwordeval python -c "import keyring; print keyring.get_password('smtp',
'kai.we...@glorybox.de')"
passwordeval secret-tool lookup service smtp username kai.we...@glorybox.de
Find attached the logfiles.
> Hi Kai,
>
> On 2019-01-09 10:03 a.m., kai.we...@glorybox.de wrote:
>
> > With the AppArmor profile shipped the 'passwordeval' options does not
> > work anymore. I tried using the permitted "gpg" or "secret-tool" but
> > this did not work.
> >
> > msmtp uses popen(3) which in turn seems to exec /bin/dash which is not
> > permitted by AppArmor.
> >
> > This renders the package currently unusable because I use the "pass"
> > password manager. This might render the package unusable for everyone
> > else using 'passwordeval' as well.
>
> If you could put the profile in complain mode and collect the kernel
> messages it would be useful to figure out what rules are missing.
>
> To do so:
>
> 1) please edit the profile flags to include "complain" like this:
>
> /usr/bin/msmtp flags=(attach_disconnected,complain) {
>
> 2) compile the new profile
>
> sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.bin.msmtp
>
> 3) do your test
>
> 4) collect kernel logs
>
> Providing only the apparmor messages would suffice (something like: grep
> apparmor /var/log/syslog).
>
> Thanks,
> Simon
Kai
Jan 9 17:47:09 dummy kernel: [23484.742007] audit: type=1400
audit(1547052429.273:844): apparmor="DENIED" operation="exec"
profile="/usr/bin/msmtp" name="/bin/dash" pid=3869 comm="msmtp"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
Jan 9 17:48:21 dummy kernel: [23557.249217] audit: type=1400
audit(1547052501.788:846): apparmor="STATUS" operation="profile_replace"
profile="unconfined" name="/usr/bin/msmtp" pid=4561 comm="apparmor_parser"
Jan 9 17:48:27 dummy kernel: [23562.647401] audit: type=1400
audit(1547052507.184:847): apparmor="ALLOWED" operation="exec"
profile="/usr/bin/msmtp" name="/bin/dash" pid=4635 comm="msmtp"
requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
target="/usr/bin/msmtp//null-/bin/dash"
Jan 9 17:48:27 dummy kernel: [23562.647756] audit: type=1400
audit(1547052507.184:848): apparmor="ALLOWED" operation="file_inherit"
profile="/usr/bin/msmtp//null-/bin/dash" name="/tmp/#20452048" pid=4635
comm="sh" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=1000
Jan 9 17:48:27 dummy kernel: [23562.647793] audit: type=1400
audit(1547052507.184:849): apparmor="ALLOWED" operation="file_mmap"
profile="/usr/bin/msmtp//null-/bin/dash" name="/bin/dash" pid=4635 comm="sh"
requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Jan 9 17:48:27 dummy kernel: [23562.647842] audit: type=1400
audit(1547052507.184:850): apparmor="ALLOWED" operation="file_mmap"
profile="/usr/bin/msmtp//null-/bin/dash"
name="/lib/x86_64-linux-gnu/ld-2.28.so" pid=4635 comm="sh" requested_mask="r"
denied_mask="r" fsuid=1000 ouid=0
Jan 9 17:48:27 dummy kernel: [23562.648041] audit: type=1400
audit(1547052507.184:851): apparmor="ALLOWED" operation="open"
profile="/usr/bin/msmtp//null-/bin/dash" name="/etc/ld.so.cache" pid=4635
comm="sh" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Jan 9 17:48:27 dummy kernel: [23562.648087] audit: type=1400
audit(1547052507.184:852): apparmor="ALLOWED" operation="open"
profile="/usr/bin/msmtp//null-/bin/dash"
name="/lib/x86_64-linux-gnu/libc-2.28.so" pid=4635 comm="sh" requested_mask="r"
denied_mask="r" fsuid=1000 ouid=0
Jan 9 17:48:27 dummy kernel: [23562.648140] audit: type=1400
audit(1547052507.184:853): apparmor="ALLOWED" operation="file_mmap"
profile="/usr/bin/msmtp//null-/bin/dash"
name="/lib/x86_64-linux-gnu/libc-2.28.so" pid=4635 comm="sh"
requested_mask="rm" denied_mask="rm" fsuid=1000 ouid=0
Jan 9 17:48:27 dummy kernel: [23562.649312] audit: type=1400
audit(1547052507.188:854): apparmor="ALLOWED" operation="exec"
profile="/usr/bin/msmtp//null-/bin/dash" name="/usr/bin/python2.7" pid=4636
comm="sh" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
target="/usr/bin/msmtp//null-/bin/dash//null-/usr/bin/python2.7"
Jan 9 17:48:27 dummy kernel: [23562.649516] audit: type=1400
audit(1547052507.188:855): apparmor="ALLOWED" operation="file_inherit"
profile="/usr/bin/msmtp//null-/bin/dash//null-/usr/bin/python2.7"
name="/tmp/#20452048" pid=4636 comm="python" requested_mask="wr"
denied_mask="wr" fsuid=1000 ouid=1000
Jan 9 17:48:27 dummy kernel: [23562.649523] audit: type=1400
audit(1547052507.188:856): apparmor="ALLOWED" operation="file_mmap"
profile="/usr/bin/msmtp//null-/bin/dash//null-/usr/bin/python2.7"
name="/usr/bin/python2.7" pid=4636 comm="python" requested_mask="r"
denied_mask="r" fsuid=1000 ouid=0
Jan 9 17:49:48 dummy kernel: [23644.263808] audit: type=1400
audit(1547052588.802:1564): apparmor="ALLOWED" operation="exec"
profile="/usr/bin/msmtp" name="/bin/dash" pid=5468 comm="msmtp"
requested_mask="x"
Bug#918820: msmtp: AppArmor profile makes passwordeval unusable
Hi Kai,
On 2019-01-09 10:03 a.m., kai.we...@glorybox.de wrote:
> With the AppArmor profile shipped the 'passwordeval' options does not
> work anymore. I tried using the permitted "gpg" or "secret-tool" but
> this did not work.
>
> msmtp uses popen(3) which in turn seems to exec /bin/dash which is not
> permitted by AppArmor.
>
> This renders the package currently unusable because I use the "pass"
> password manager. This might render the package unusable for everyone
> else using 'passwordeval' as well.
If you could put the profile in complain mode and collect the kernel
messages it would be useful to figure out what rules are missing.
To do so:
1) please edit the profile flags to include "complain" like this:
/usr/bin/msmtp flags=(attach_disconnected,complain) {
2) compile the new profile
sudo apparmor_parser -r -T -W /etc/apparmor.d/usr.bin.msmtp
3) do your test
4) collect kernel logs
Providing only the apparmor messages would suffice (something like: grep
apparmor /var/log/syslog).
Thanks,
Simon
Bug#918820: msmtp: AppArmor profile makes passwordeval unusable
Package: msmtp Version: 1.8.1-2 Severity: important Dear Maintainer, With the AppArmor profile shipped the 'passwordeval' options does not work anymore. I tried using the permitted "gpg" or "secret-tool" but this did not work. msmtp uses popen(3) which in turn seems to exec /bin/dash which is not permitted by AppArmor. This renders the package currently unusable because I use the "pass" password manager. This might render the package unusable for everyone else using 'passwordeval' as well. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages msmtp depends on: ii debconf [debconf-2.0] 1.5.69 ii libc6 2.28-4 ii libgnutls303.6.5-2 ii libgsasl7 1.8.0-8+b2 ii ucf3.0038+nmu1 Versions of packages msmtp recommends: ii ca-certificates 20180409 Versions of packages msmtp suggests: ii msmtp-mta 1.8.1-2 -- debconf information: msmtp/tls: false msmtp/maildomain: msmtp/sysconfig: false msmtp/port: 25 msmtp/auto_from: true msmtp/host:
