Bug#1034494: Acknowledgement (unbound: Unbound fails to create pid file even when pidfile specified in /etc/unbound/unbound.conf or /etc/init.d/unbound)
You can override ExecStart= by first defining it empty like that: [Service] ExecStart= ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS HTH, Simon On 2023-04-17 23:20, J wrote: Thank you so much, thats exactly what I was missing. I commented out the -p in ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS in /usr/lib/systemd/system/unbound.service And now I have a pidfile back that I can use. Unless there is any better way? I tried to override the unbound.service but I'm not sure ExecStart= can be overrode. On Sun, 16 Apr 2023 at 18:52, J wrote: Hi! I'm having an issue where unbound is not creating the pid file I've specified in unbound.conf `pidfile: "/run/unbound.pid"` I also see that this path is hard coded in `/etc/init.d/unbound` as `PIDFILE="/run/unbound.pid"` The only thing that fixes it is commenting out `. /lib/lsb/init-functions` in `/etc/init.d/unbound` which is obviously not what I want to do On Sun, 16 Apr 2023 at 18:48, Debian Bug Tracking System < ow...@bugs.debian.org> wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 1034494: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): unbound packagers If you wish to submit further information on this problem, please send it to 1034...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 1034494: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034494 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1034494: unbound: Unbound fails to create pid file even when pidfile specified in /etc/unbound/unbound.conf or /etc/init.d/unbound
When managed by systemd, unbound is started with the "-p" argument that tells it to not create a PID file at all. I don't know what use you have for the PID but you can obtain it with: > systemctl show --property MainPID --value unbound That's of course assuming unbound is managed by systemd. HTH, Simon
Bug#1034458: msmtp: Add XDG_CONFIG_PATH/msmtp/* to apparmor profile
Hi, On 2023-04-15 18:05, أحمد المحمودي (Ahmed El-Mahmoudy) wrote: A user might manually set XDG_CONFIG_DIR to another path than $HOME/.config, hence I suggest to add XDG_CONFIG_PATH/msmtp/* to apparmor profile AFAIK, Apparmor profiles cannot reference such user defined variables. HTH, Simon
Bug#761813: Processed: suspect this bug is no longer relevent
On 2023-03-14 08:49, Richard Lewis wrote: On Mon, 13 Mar 2023, 12:36 Simon Deziel, wrote: egrep still consumes a lot of memory for me. A workaround I've been using is to add this to /etc/logcheck/logcheck.conf: # XXX: prevent grep from using incredible amounts of RAM (>3G RSS) # this also speeds up grep a lot export LC_ALL=C interesting - does using C.UTF-8 have the same effect? tl; dr: no :/ According to my simple test: # grep LC_ALL /etc/logcheck/logcheck.conf; time sudo -u logcheck logcheck -t export LC_ALL=C real0m2.706s user0m0.005s sys 0m0.010s # grep LC_ALL /etc/logcheck/logcheck.conf; time sudo -u logcheck logcheck -t export LC_ALL=C.UTF-8 real0m9.374s user0m0.007s sys 0m0.010s The above only shows the time spent but when checking with `top`, the `%MEM` goes up to ~47% for LC_ALL=C and reaches ~95% with LC_ALL=C.UTF-8. Simon
Bug#761813: Processed: suspect this bug is no longer relevent
egrep still consumes a lot of memory for me. A workaround I've been using is to add this to /etc/logcheck/logcheck.conf: # XXX: prevent grep from using incredible amounts of RAM (>3G RSS) # this also speeds up grep a lot export LC_ALL=C HTH, Simon
Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/
On 2023-02-28 18:37, James Lownie wrote: It sounds like the problem is at our end then, I will investigate further. Thanks for helping with this Simon. Great, please let us know how it goes! Thanks
Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/
On 2023-02-28 17:42, James Lownie wrote: It's not in salsa but it was in my config file. Is it the case that my version of /etc/apparmor.d/usr.lib.ipsec.charon is different to the package version? I didn't modify that file manually (apart from moving the lines up in the file), I did deploy ipsec with an Ansible playbook but I just had a look through it and I don't think it modified it either. I just downloaded the same package (https://packages.debian.org/bullseye/strongswan) and double checked. The Apparmor profile doesn't mention any "/etc/ipsec.secrets.d" directory. Dunno what to tell you, sorry. HTH. Simon
Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/
On 2023-02-28 17:12, James Lownie wrote: Hi Simon, thanks for the suggestion. I'm going to wait and see if other people can reproduce this before running any tests, this machine is now in production which makes things awkward. I would have thought putting the secrets in /etc/ipsec.secrets.d/ would just work given it was already in the profile as a directory with read access. Hmm, I don't see such *directory* rule in salsa: https://salsa.debian.org/debian/strongswan/-/blob/debian/master/debian/usr.lib.ipsec.charon#L47-51 Maybe you thought that "/etc/ipsec.*.secrets" covered your dir? If so, that's not the case because Apparmor needs the trailing "/" to apply to directories. So the rule "/etc/ipsec.*.secrets" only covers files with a prefix of "ipsec." and a ".secrets" suffix. HTH, Simon
Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/
On 2023-02-28 00:44, James Lownie wrote: Version: 5.9.1-1+deb11u3 Package: strongswan-charon Version: 5.9.1-1+deb11u3 Severity: normal X-Debbugs-Cc: none Dear maintainer, Hello James, I'm not maintainer but I've used strongswan with the Apparmor profiles. I ran into a problem using Strongswan which looks like a bug to me. I'm not sure if its in strongswan-charon or in Apparmor but I fixed it by editing /etc/apparmor.d/usr.lib.ipsec.charon which is strongswan-charon code, so I'm raising it here first. In general, you are better off putting your modifications in /etc/apparmor.d/local/usr.lib.ipsec.charon as the "local" directory is meant to have the rules the local admin wanted to add. The main profile includes this file so your rules would still work. The problem was that when I ran the command 'ipsec rereadsecrets' these messages appeared in syslog: Feb 28 14:50:41 myhostname charon: 01[CFG] expanding file expression '/etc/ipsec.secrets.d/*' failed Feb 28 14:50:41 myhostname kernel: [2262128.239395] audit: type=1400 audit(1677556241.557:15): apparmor="DENIED" operation="open" profile="/usr/lib/ipsec/charon" name="/etc/ipsec.secrets.d/" pid=49996 comm="charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 ... /etc/ipsec.secrets r, /etc/ipsec.*.secrets r, /etc/ipsec.d/ r, /etc/ipsec.d/** r, In your case, maybe it would be simpler to move your secrets files directly to /etc/ipsec.d/*.secrets or if you prefer inside a manually created directory like /etc/ipsed.d/secrets/*.secrets. This way, you wouldn't need to customize the Apparmor profile at all and it would just work. HTH, Simon
Bug#1029197: ip-transparent: yes is blocked by apparmor
On 2023-01-19 08:35, Tiger!P wrote: Package: unbound Version: 1.17.0-1 Severity: normal Tags: patch Dear Maintainer, * What led up to the situation? I wanted to configure a static IPv6 address in unbound, but that is not (always) available when booting the system. Therefor I enabled ip-transparent in the server section. On Linux, you can use "ip-freebind: yes" which doesn't require any additional capability. Here's the man unbound.conf description snippet for it: > Allows you to bind to IP addresses that are nonlocal or do not exist, > like when the network interface or IP address is down. Works like a charm as I discovered 2 days ago when running into the same situation as you (IPv6 not being present when unbound starts). HTH, Simon
Bug#1009301: acpid: acpi.path in container generates - systemd[1]: Condition check resulted in ACPI event daemon being skipped.
This issue was reported in https://discuss.linuxcontainers.org/t/odd-behavior-with-ubuntu-22-04-and-lxd-22-04-containers/14275 which lead me to report it to Ubuntu in: https://bugs.launchpad.net/debian/+source/acpid/+bug/1977896 I had not noticed the MR on Salsa so I proposed a very similar solution in: https://salsa.debian.org/debian/acpid/-/merge_requests/3 The only difference is that `acpid.socket` is also disabled inside containers.
Bug#1010517: unbound apparmor profile does not let the root.key write making unbound fail to start
On 2022-05-03 10:20, Michael Tokarev wrote: 03.05.2022 17:08, Simon Deziel wrote: On 2022-05-03 07:44, Michael Tokarev wrote: Package: unbound Version: 1.15.0-8 Severity: normal When enabling apparmor, unbound fails to start. From the dmesg: audit: type=1400 audit(1651577812.219:369): apparmor="DENIED" \ operation="mknod" profile="/usr/sbin/unbound" \ name="/etc/unbound/var/lib/unbound/root.key.68281-0-55cf18ed18a0" \ pid=68281 comm="unbound" requested_mask="c" denied_mask="c" \ fsuid=930 ouid=930 from the unbound log: unbound: [68281:0] fatal error: could not open autotrust file for writing, \ /var/lib/unbound/root.key.68281-0-55cf18ed18a0: Permission denied I'm assuming the way to reproduce this is with `chroot: "/etc/unbound"`. Having a daemon write to /etc/ feels wrong, IMHO. The profile was designed with the following in mind IIRC: Oh. Yes, you're right, I haven't noticed the difference here between unbound message and kernel message. This explains why I can't fix it by adding stuff for /var/lib/unbound to aparmor.d/. Yes, I chroot it to /etc/unbound, with /var/lib/unbound bind-mounted to /etc/unbound/var/... - the way it was supposed to work by upstream, apparently. The problem with chrooting it to /var/lib/unbound is the copy of all the configuration which must not be done by root into nonroot-owned untrusted directory, and because you lose unbound-control reload. Could a bind mount of the control socket make it work? Similar to systemd's notify socket. Copying configs is bad, I think. Well, the way unbound chroots feels awkward to me. I don't understand why stuff needs to be present in the chroot. I maybe naively think that unbound-control could have supplied fresh configs to the running chroot'ed daemon without having to move files/sockets/pid/etc around. # cat /etc/unbound/unbound.conf.d/chroot.conf server: chroot: "/var/lib/unbound" I just tested the above and it seems to work. Yes, this one works (with the above comment/restriction). And yes, adding /etc/unbound/var/lib/unbound/* stuff to apparmor profile seems to be working as well, - something which I missed initially, - that's why I filed this bugreport instead of fixing it right away, - b/c I weren't able to figure out why it doesn't work after my attempts to fix the profile. If you'd like to have your bind-mount setup to work, I'm happy to add the missing apparmor bits to https://salsa.debian.org/dns-team/unbound/-/merge_requests/19 Thanks, Simon
Bug#1010517: unbound apparmor profile does not let the root.key write making unbound fail to start
On 2022-05-03 07:44, Michael Tokarev wrote: Package: unbound Version: 1.15.0-8 Severity: normal When enabling apparmor, unbound fails to start. From the dmesg: audit: type=1400 audit(1651577812.219:369): apparmor="DENIED" \ operation="mknod" profile="/usr/sbin/unbound" \ name="/etc/unbound/var/lib/unbound/root.key.68281-0-55cf18ed18a0" \ pid=68281 comm="unbound" requested_mask="c" denied_mask="c" \ fsuid=930 ouid=930 from the unbound log: unbound: [68281:0] fatal error: could not open autotrust file for writing, \ /var/lib/unbound/root.key.68281-0-55cf18ed18a0: Permission denied I'm assuming the way to reproduce this is with `chroot: "/etc/unbound"`. Having a daemon write to /etc/ feels wrong, IMHO. The profile was designed with the following in mind IIRC: # cat /etc/unbound/unbound.conf.d/chroot.conf server: chroot: "/var/lib/unbound" I just tested the above and it seems to work. HTH, Simon
Bug#641704: unbound-host should be preconfigured with DNS root trust anchor
There is another difference between /var/lib/unbound/root.key and /usr/share/dns/root.key: their respective source of update. The former normally starts its life as a copy of the later but is then managed using RFC 5011 to cope with root KSK rollovers. The later being changed only via package updates. I think Debian needs to settle on a way to deal with the root KSK updates. The current state of having unbound maintain it's own copy feels awkward, IMHO. A possible simplification would be to have all the packages simply consult the read-only copy provided by dns-root-data. This would imply changing `/etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf` from unbound's package and turn it into: trust-anchor-file: "/usr/share/dns/root.key" To tell it not to do RFC 5011 maintenance. That way, root KSK refresh would only come from dns-root-data updates. My 2 cents, Simon
Bug#900241: no root.key provided by libunbound2
On 2022-04-28 13:02, Michael Tokarev wrote: Control: tag -1 + moreinfo So, will adding a Recommends: dns-root-data either to libunbound or to various software packages (eg unbound-host) fix this? dns-root-data doesn't put the key where unbound-host expects it though: # unbound-host -D google.com [1651242475] libunbound[100:0] error: error opening file /var/lib/unbound/root.key: No such file or directory [1651242475] libunbound[100:0] error: error reading trust-anchor-file: /var/lib/unbound/root.key [1651242475] libunbound[100:0] error: validator: error in trustanchors config [1651242475] libunbound[100:0] error: validator: could not apply configuration settings. [1651242475] libunbound[100:0] error: module init for module validator failed resolve error: initialization failure Since unbound-host only reads the root.key, maybe it could be told to fallback to reading it from /usr/share/dns/root.key. I'm suggesting to doing it as fallback only because that file isn't subject to RFC 5011 maintenance, only package updates will bring fresh KSK. I suspect that for some environments the distinction could matter. Simon
Bug#1004489: Acknowledgement (spamassassin: /etc/cron.daily/spamassassin should keep https_proxy var)
Here is the merge request: https://salsa.debian.org/debian/spamassassin/-/merge_requests/7 I have tested on my Ubuntu 20.04 server running a manually patched spamassassin 3.4.4-1ubuntu1.1 Thank you! Simon
Bug#1004489: spamassassin: /etc/cron.daily/spamassassin should keep https_proxy var
Package: spamassassin Version: 3.4.4-1ubuntu1.1 The cron.daily refresh script works well for HTTP mirrors accessed through a `http_proxy` (thanks to [*]) but fails when accessing HTTPS mirrors. For those, the HTTPS equivalent variable would need to be supported. Thanks, Simon *: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805009 P.S: I will provide a MR on Salsa soon.
Bug#1002640: bind9 won't start after upgrading from 9.11 - "the working directory is not writable"
On 2021-12-26 06:09, Robert Waldner wrote: Package: bind9 Version: 1:9.16.22-1~deb11u1 Severity: important Dear Maintainers, I upgraded my nameserver from buster to bullseye, afterwards named wouldn't start anymore. Looking at syslog, the relevant part seems to be: ... Dec 26 11:36:01 fsck named[128029]: configuring command channel from '/etc/bind/rndc.key' Dec 26 11:36:01 fsck named[128029]: command channel listening on 127.0.0.1#953 Dec 26 11:36:01 fsck named[128029]: configuring command channel from '/etc/bind/rndc.key' Dec 26 11:36:01 fsck named[128029]: command channel listening on ::1#953 Dec 26 11:36:01 fsck named[128029]: the working directory is not writable ^ Dec 26 11:36:01 fsck named[128029]: loading configuration: permission denied Dec 26 11:36:01 fsck named[128029]: exiting (due to fatal error) Dec 26 11:36:01 fsck systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE Dec 26 11:36:01 fsck systemd[1]: named.service: Failed with result 'exit-code'. Note that this is straight from systemd trying to start it. Running named as `named -g -u bind` got the same result (CWD: /home/myuser). But! starting it manually with a CWD that's writable by group bind (eg. `cd /etc/bind; named -g -u bind`) works: ... 26-Dec-2021 11:44:10.434 configuring command channel from '/etc/bind/rndc.key' 26-Dec-2021 11:44:10.434 command channel listening on 127.0.0.1#953 26-Dec-2021 11:44:10.434 configuring command channel from '/etc/bind/rndc.key' 26-Dec-2021 11:44:10.434 command channel listening on ::1#953 26-Dec-2021 11:44:10.434 not using config file logging statement for logging due to -g option 26-Dec-2021 11:44:10.434 zone 10.in-addr.arpa/IN: loaded serial 2002041301 ... Now this wouldn't be a problem is systemd could start named, but it can't: root@fsckv2:/etc/bind# systemctl start named root@fsckv2:/etc/bind# systemctl status named ● named.service - BIND Domain Name Server Loaded: loaded (/lib/systemd/system/named.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2021-12-26 11:46:23 CET; 1s ago Docs: man:named(8) Process: 130605 ExecStart=/usr/sbin/named -f $OPTIONS (code=exited, status=1/FAILURE) Main PID: 130605 (code=exited, status=1/FAILURE) CPU: 51ms Dec 26 11:46:23 fsckv2 systemd[1]: named.service: Scheduled restart job, restart counter is at 5. Dec 26 11:46:23 fsckv2 systemd[1]: Stopped BIND Domain Name Server. Dec 26 11:46:23 fsckv2 systemd[1]: named.service: Start request repeated too quickly. Dec 26 11:46:23 fsckv2 systemd[1]: named.service: Failed with result 'exit-code'. Dec 26 11:46:23 fsckv2 systemd[1]: Failed to start BIND Domain Name Server. For testing, I also `apt-get -b source`d bind9 from testing/unstable (9.17.21-1) but it exhibits the same non-working bevaviour. (If needed I can provide all config in private mail, but am loathe to disclose them publicly as it's quite extensive (this is a nameserver for quite some domains, plus the resolver for all my internal networks).) What's in /etc/default/named? Chroot'ing could cause some issues. Since you are hitting permission issues, I'd also check dmesg for AppArmor denial messages (`dmesg | grep apparmor`). Simon
Bug#947771: unbound: cannot restart daemon under sysvinit-core when apparmor is enforced
I took the patch from Gedalya and proposed it: https://salsa.debian.org/dns-team/unbound/-/merge_requests/17
Bug#944188: /etc/msmtprc password disclosure
Hello On 2021-06-19 9:52 a.m., nodiscc wrote: I found 4 msmtp repositories on salsa.debian.org, is it this one? https://salsa.debian.org/kolter/msmtp Yes, ^ that's the one. Thanks Simon
Bug#985471: msmtp: Unable to send email with starttls if post-handshake new tls session ticket arrives
Hi Rajeev, That seems to be due to a bogus cert chain on the server side. One of the intermediate expired recently, see the "Not After": https://letsencrypt.org/certs/lets-encrypt-x3-cross-signed.txt Presumably Thunderbird is a bit more forgiving and uses another chain of trust but msmtp's TLS stack doesn't. Another confirmation https://www.hardenize.com/report/smtp.sivalik.com/1616099988#email_certs HTH, Simon On 2021-03-18 3:02 p.m., Rajeev wrote: Package: msmtp Version: 1.8.11-2 Severity: normal Dear Maintainer, I am able to talk to the smtp server at smtp.sivalik.com:587 to submit email using thunderbird but msmtp gives error that the certificate has expired. I have confirmed that the certificate is valid. I tried to debug using openssl s_client and for the case where msmtp works (gmail) and the case for which it does not (sivalik). I found that sivalik server sends a post handshake new session ticket, which msmtp does not seem to handle and gives an incorrect error description. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages msmtp depends on: ii adduser3.118 ii debconf [debconf-2.0] 1.5.75 ii libc6 2.31-9 ii libgnutls303.7.0-7 ii libgsasl7 1.10.0-4 ii libsecret-1-0 0.20.4-2 ii ucf3.0043 Versions of packages msmtp recommends: ii ca-certificates 20210119 Versions of packages msmtp suggests: ii msmtp-mta 1.8.11-2 -- Configuration Files: /etc/apparmor.d/usr.bin.msmtp changed [not included] -- debconf information excluded
Bug#944188: /etc/msmtprc password disclosure
On 2021-02-17 8:30 p.m., Simon McVittie wrote: On Wed, 17 Feb 2021 at 18:01:26 -0500, Simon Deziel wrote: 1) you are worried that since msmtp wasn't written with setgid in mind, there's a risk of someone elevating their privileges to $USER:msmtp to execute code => Doesn't that just give you read access to /etc/msmtprc? I don't know, I don't use msmtp. Presumably yes? If this is worth protecting by using OS-level security boundaries, then it seems to me that it's worth protecting in a way that isn't easily defeated - otherwise the effect is to give sysadmins a false sense of security. If by easily defeated, you mean leaking the SMTP password with 'msmtp --debug' then I fully agree. If on the other hand you are implying that the setgid feature could be abused to leak the SMTP password, then I wouldn't consider this easily defeated. 2) Glib should be hardened to treat setgid processes specially to make it more secure. Doing so breaks the msmtp libsecret integration. Yes, ish. It's more like: GLib should ideally be hardened to treat all processes that have the AT_SECURE flag equally specially. AT_SECURE is the kernel telling us "you have privileges, be careful not to trust your parent process", and ideally GLib would always respond to that by being as careful as possible. However, GLib 2.66.4-2 tried being as careful as possible, and it turns out to make programs (at least msmtp and gnome-keyring) regress, by preventing them from learning the address of the D-Bus session bus. At the moment, GLib is second-guessing that warning from the kernel and asking "but am I *really* privileged, or just *slightly* privileged?" in order to keep msmtp and gnome-keyring working, but that's extra security exposure - and not just in msmtp, but also in programs that are protecting something more important than a SMTP password. Thanks for the clear explanation! GLib is not really in a position to know that setgid msmtp is any less dangerous than setgid shadow, or setgid adm, or setgid sudo. If we tried to hard-code which privileges are genuinely important and which privileges are unimportant, that would scale really badly. Agreed. I would recommend removing the setgid support from msmtp, and recommending that people who want a system-wide authenticating MTA whose credentials are not disclosed to unprivileged users Doing so by default would let everyone read creds from /etc/msmtprc which sounds easier than abusing a setgid (even one not designed to run that way). If Debian wasn't telling sysadmins "it's safe to put msmtp credentials in /etc/msmtprc, unprivileged users won't be able to read them", then they could make their own decision about whether it's acceptable for unprivileged users on their systems to be able to see the SMTP password. If that's fine for that particular sysadmin's threat model, then the setgid mechanism would be unnecessary. If not, then that sysadmin should probably be choosing something "heavier" than msmtp, that does put a real security boundary between users and SMTP credentials, and treats it as a security vulnerability with CVE IDs and advisories if that boundary fails - like exim or postfix. And, yes, that often implies running a daemon. The sysadmin will have to decide whether that's worth it. That said, msmtp is really nice due to not having to run a daemon. Of course - I don't use msmtp myself, but I've used similar small SMTP-sending implementations like esmtp in the past, and I recognise the advantages of that architecture. However, this architecture comes with limitations, and I think it's important to be realistic about what msmtp can and can't promise. > As a user, I guess I wouldn't mind having that setgid behind a debconf question. Would that middle ground work? I'm not sure that really helps. If the sysadmin doesn't trust msmtp to keep passwords safe from unprivileged users, they can just not put those passwords in /etc/msmtprc, or at the other extreme, if they don't care whether unprivileged users can read those passwords, then they can make it world-readable. The problem case is in the middle, where msmtp is promising that it will protect the credentials, and the sysadmin believes its promise, but actually they should not have done. If a sysadmin is in that position, then they'll answer the debconf question "yes, make it setgid" and then be disappointed or angry when their passwords are disclosed. If msmtp is promising to protect the credentials from unprivileged users, under at least some configurations, then it needs to be designed to do that. If it's going to do that in a way that lives up to that promise, > then every line of code that ends up in its process space (including libraries) needs to have been written, or at least reviewed, while thinking "what's the worst possible way this could be tricked by a malicious user?" - otherwise it's just providing a false sense of
Bug#982162: msmtp: cannot read custom aliases file (Permission denied)
Hello Hugo, On 2021-02-06 11:13 p.m., Hugo Villeneuve wrote: Source: msmtp Version: 1.8.3 Severity: normal Dear Maintainer, when specifying a custom aliases file in /etc/msmtprc configuration file like this: aliases /etc/aliases.msmtp msmtp returns the following error: $> echo -e "foo" | msmtp -t postmaster msmtp: /etc/aliases.msmtp: Permission denied Here are the permissions of the file: $> ls -al /etc/aliases.msmtp -rw-r--r-- 1 root root 75 Feb 6 21:44 /etc/aliases.msmtp That is not a common configuration but a valid one nevertheless. Here is the dmesg output that I observed that seems to indicate it is a problem with AppArmor (which I know nothing about): [1051574.267096] audit: type=1400 audit(1612667641.178:68): apparmor="DENIED" operation="open" profile="/usr/bin/msmtp" name="/etc/aliases.msmtp" pid=17563 comm="sendmail" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 Indeed, the default Apparmor profile only allows reading a handful of files. You have several options available to make it work: 1) move the aliases file to /etc/aliases 2) add a custom rule to the local override file 3) disable msmtp's Apparmor profile For instructions on how to do 2 and 3, please refer to msmtp's NEWS.Debian.gz. Regards, Simon
Bug#944188: /etc/msmtprc password disclosure
On 2021-02-03 7:26 a.m., Simon McVittie wrote: On Tue, 05 Nov 2019 at 10:02:23 -0500, Simon Deziel wrote: On 2019-11-05 9:29 a.m., Jakub Wilk wrote: If /etc/msmtprc is readable by group msmtp (as suggested in README.Debian), any user can acquire password from that file Nice catch! Having /etc/msmtprc group readable is AFAIK, a "debianism". I don't know if upstream endorses this method of restricting access to the default account's password. Even if this specific attack did not exist, if msmtp is not specifically Right, I'll be ignoring this (upstream) fixable problem for the sake of discussion. designed to be safe to use with elevated privileges, then I think it's a security-significant, Debian-specific bug to be making it setgid in Debian. Privileged (setuid/setgid/setcap) executables need to be written in a defensive/paranoid way. They have to be specifically designed to distrust their whole execution environment - environment variables, command-line options, resource limits and so on - and every library they are linked to needs to be specifically designed to do the same. Otherwise, there is often a way for an attacker to trick the process into executing arbitrary code with its elevated privileges, which gives the attacker access to those elevated privileges. Please see <https://dwheeler.com/secure-programs/Secure-Programs-HOWTO.html> for a lot more information on this topic. In this case, the elevated privilege is the ability to read files that are 0640 root:msmtp, such as /etc/msmtprc in the configuration suggested by Debian-specific documentation in this package. This came to my attention because I was recently involved in hardening GLib so that it is more difficult to use as an attack vector to get elevated privileges like this. This made GLib distrust environment variables, which ended up breaking msmtp's support for retrieving passwords from libsecret (see <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981420#59>, <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981420#71>). Note that GLib is not really designed to be used in processes that run with elevated privileges, so the GLib upstream maintainers consider this to be security hardening to mitigate it being used in an unsafe way, rather than a fix for a vulnerability in GLib. For now, GLib upstream has partially reverted that change, weakening the security hardening in order to fix the regression, and I'm going to do the same in Debian. This should stop msmtp from regressing in terms of which features work, but I cannot guarantee that it does not make msmtp exploitable. If I find a concrete attack, I will report it privately to the security team. If I understand, the problem is twofold: 1) you are worried that since msmtp wasn't written with setgid in mind, there's a risk of someone elevating their privileges to $USER:msmtp to execute code => Doesn't that just give you read access to /etc/msmtprc? 2) Glib should be hardened to treat setgid processes specially to make it more secure. Doing so breaks the msmtp libsecret integration. I would recommend removing the setgid support from msmtp, and recommending that people who want a system-wide authenticating MTA whose credentials are not disclosed to unprivileged users Doing so by default would let everyone read creds from /etc/msmtprc which sounds easier than abusing a setgid (even one not designed to run that way). should be using a fully-featured MTA that was designed to act as a security boundary, like Exim or Postfix. I don't fully understand your concerns but I trust you on their seriousness. That said, msmtp is really nice due to not having to run a daemon. I understand that makes it harder to secure the plain text creds that are in its config file. I've been using msmtp for years on hundreds of machine and never used the libsecret integration. I'm sure I'm not alone so it would be nice to not go back to having /etc/msmtprc world-readable for all of us. As a user, I guess I wouldn't mind having that setgid behind a debconf question. Would that middle ground work? Regards, Simon
Bug#981283: Should the daemon started at postinst?
On 2021-01-28 11:30 a.m., u...@net9.ga wrote:
Package: nsd
Version: 4.1.26-1
Severity: normal
The bottom lines of the package installation were:
Preparing to unpack .../nsd_4.1.26-1_amd64.deb ...
Job for nsd.service failed because the control process exited with error
code.
See "systemctl status nsd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript nsd, action "start" failed.
* nsd.service - Name Server Daemon
Loaded: loaded (file:/lib/systemd/system/nsd.service
/lib/systemd/system/nsd.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Wed
2021-01-27 16:38:05 EST; 12ms ago
Docs: man:nsd(8) man:nsd(8)
Process: 536 ExecStart=/usr/sbin/nsd -d (code=exited, status=1/FAILURE)
Main PID: 536 (code=exited, status=1/FAILURE)
Jan 27 16:38:05 systemd[1]: nsd.service: Main process exited, code=exited, status=1/FAILURE
Jan 27 16:38:05 systemd[1]: nsd.service: Failed with result 'exit-code'.
Jan 27 16:38:05 systemd[1]: Failed to start Name Server Daemon.
dpkg: error processing package nsd (--configure):
installed nsd package post-installation script subprocess returned error
exit status 1
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u5) ...
Errors were encountered while processing:
nsd
Sub-process /usr/bin/dpkg returned an error code (1)
The package is left in an half-Conf state.
I think the problem is not having a working nsd configuration files. Which
is a bit trickier to solve. Just setting appropriate configuration files
and
You should check "journalctl -u nsd" and see why it is failing to start.
A common situation is when systemd-resolved stub listener has already
bound port 53. You can check with:
{ ss -nlt; ss -nlu; } | grep :53
If that's the case, setting DNSStubListener=no in
/etc/systemd/resolved.conf and restarting systemd-resolved usually fixes it.
HTH,
Simon
Bug#975333: msmtp: AppArmor profile breaks --file, logfile, and passwordeval
On 2020-11-24 4:23 a.m., Emmanuel Bouthenot wrote: Hi, On Tue, Nov 24, 2020 at 12:03:07AM -0500, Simon Deziel wrote: [...] Yes, an opt-in approach seems ideal. Here's the proposal: https://salsa.debian.org/kolter/msmtp/-/merge_requests/16 Thanks Simon for your merge request. I'd like to propose some improvements: - a debconf question which ask to enable/disable AppArmor - make it idempotent, so that it could possible to enable or disable apparmor profile with dpkg-reconfigure even if the package was already installed - add a debian/NEWS entry so that users which already use msmtp could be aware that it is now easy and possible to disable AppArmor Those make sense. I'll back to you with something, hopefully in a not too distant future. Regards, Simon
Bug#975333: msmtp: AppArmor profile breaks --file, logfile, and passwordeval
On 2020-11-21 4:02 a.m., Martin Lambers wrote: On Fri, 20 Nov 2020 10:35:00 -0500, Simon Deziel wrote: A big problem is that users do not know where to look if they get an unexplainable "permission denied" error. Almost nobody knows that AppArmor interferes. A working AppArmor profile would have to allow reading, writing and executing arbitrary files, which would make it pretty much useless. I therefore propose to either remove the AppArmor profile or restrict it to the msmtp-mta package, so that most users can continue using msmtp as expected. I'd like to propose to continue shipping the Apparmor profile but have it disabled by default. This way it would be an (easy) opt-in procedure for those who want the additional security and not even a concern for others. Presumably, those opting in would be more savvy with Apparmor and should in theory not send you as many bug reports. Would that work for you? Yes, an opt-in approach seems ideal. Here's the proposal: https://salsa.debian.org/kolter/msmtp/-/merge_requests/16 I appreciate your work on securing msmtp; it's just that the current approach causes problems. The threat scenario is a malicious SMTP server trying to trigger a bug in msmtp, right? Another use case is to limit transitions between Apparmor confined apps. If you lockdown a daemon (like apache2) with Apparmor, you can still permit it to send emails by allowing it to execute msmtp in its own profile. For that case, I thought about adding seccomp() after the configuration is initialized (file read, logfile opened, passwords acquired) but before connecting to the SMTP server. Msmtp would still need memory allocation and temporary file usage. When TLS is involved, things are more complex. GnuTLS requires a long list of syscalls to work properly [1], and that list will probably change with future versions, so using seccomp() here seems complex, fragile and hard to maintain. Something like OpenBSDs pledge() would be simpler, but still require knowledge about the requirements of GnuTLS. seccomp() seems brittle and overly complex when compared with pledge()'s simplistic beauty. One can hope though [1]. Regards, Simon [1] https://github.com/seccomp/libseccomp/issues/71
Bug#975333: msmtp: AppArmor profile breaks --file, logfile, and passwordeval
On 2020-11-20 10:16 a.m., Martin Lambers wrote: > Package: msmtp > Version: 1.8.11-2 > Severity: normal > > Dear Maintainer, > > There are several problems in the Debian AppArmor profile that are frequently > reported to me as the upstream maintainer, but I cannot fix them since > I do not ship the AppArmor profile. I'm sorry that it caused you trouble and thanks for reaching out! > 1. Option --file >AppArmor restricts which configuration files msmtp may read. This >breaks option --file because the user cannot chose freely anymore. > > 2. Option --logfile and configuration command logfile >The AppArmor profile does not allow msmtp to write log information >to arbitrary files, which breaks the corresponding configuration >options and command. > > 3. Option --passwordeval and command passwordeval >The AppArmor profile restricts the commands that msmtp may execute. >This breaks the passwordeval configuration option and command. >This restriction is documented in News.Debian, but in my opinion this >does not make things better. > > A big problem is that users do not know where to look if they get an > unexplainable "permission denied" error. Almost nobody knows that > AppArmor interferes. > > A working AppArmor profile would have to allow reading, writing and > executing arbitrary files, which would make it pretty much useless. > > I therefore propose to either remove the AppArmor profile or restrict it > to the msmtp-mta package, so that most users can continue using msmtp as > expected. I'd like to propose to continue shipping the Apparmor profile but have it disabled by default. This way it would be an (easy) opt-in procedure for those who want the additional security and not even a concern for others. Presumably, those opting in would be more savvy with Apparmor and should in theory not send you as many bug reports. Would that work for you? Regards, Simon P.S.: I'd like to thank you for building the best small MTA I know of!
Bug#969198: msmtp-mta package should use update-alternatives for symlinking to msmtp
Hi Heikki, On 2020-08-29 4:38 a.m., Heikki Orsila wrote: > msmtp-mta creates a symlink from "/usr/sbin/sendmail" to "../bin/msmtp". > It does not use update-alternatives which makes it difficult to install > msmtp-mta and another MTA on the same system. In this case, you might want to use the msmtp package instead of msmtp-mta. The former doesn't creates the sendmail symlink. HTH, Simon
Bug#966395: Please support SSL bumping with '--with-openssl' configure option
Package: squid Version: 4.12-1 In order to do SSL bumping [1], it seems that squid needs to be configured '--with-openssl'. I believe that Debian chose to use GnuTLS due to license incompatibility with OpenSSL. OpenSSL went through the process of re-licensing and were able to do so in 2017 according to: https://www.openssl.org/blog/blog/2017/03/22/license/ Now that OpenSSL is available under the Apache License v. 2.0, there should no longer be any incompatibility with Debian. As such, it would be great to benefit from the more features oferred by builds using --with-openssl. Justification/use cases: Nowadays, HTTPS represents the majority of the traffic and it cannot be observed as easily as HTTP. With SSL bumping, squid can use the SNI header that is (still) in the cleartext portion of the SSL/TLS connection and use that to allow/deny forwarding the connection. That is the 'peek-n-splice' mode in upstream docs [2]. This mode doesn't compromise the security/privacy of the intercepted traffic as SSL/TLS is not terminated. The SNI inspection may be considered a privacy concern by some. One can also do fancier things like implementing a corporate MITM that generates certs on the fly signed by locally trusted CA [3]. This terminates the SSL/TLS connection in order to inspect the inner communication. This "intrusion" is sometimes required by organization policies. I can only speak for my organization but we ran into multiple situations where the peek-n-splice capability would have been handy. In other scenarios, we would have appreciated the MITM version too, so I think there is demand for such feature. Regards, Simon 1: https://wiki.squid-cache.org/Features/SslBump 2: https://wiki.squid-cache.org/Features/SslPeekAndSplice 3: https://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit
Bug#867187: update chroot script to mount bind systemd notify socket
Hello, An ubuntu user also ran into this problem [1] as well so I revisited the patch and turned it into a merge request [2]. I tested the code with Unbound 1.10.1-1 and chroot set to /var/lib/unbound. Regards, Simon 1: https://bugs.launchpad.net/bugs/1885907 2: https://salsa.debian.org/dns-team/unbound/-/merge_requests/10
Bug#958934: bind9: named fails to start after upgrade to 9.16.2
On 2020-04-27 11:33 a.m., Scott Bailey wrote: > buzz:~# journalctl -k -b0 | grep -F apparmor > buzz:~# > > So whatever's going on, it doesn't look like AppArmor has anything to do with > it. To completely rule out Apparmor, please share the following: aa-enabled sudo aa-status | grep -E '^[0-9]+|named' Thanks, Simon
Bug#958934: bind9: named fails to start after upgrade to 9.16.2
On 2020-04-27 9:34 a.m., Scott Bailey wrote: > Does anybody have any additional suggestions on what to look at the next time > I start a troubleshooting session? Apparmor denials show up in kernel logs, so dmesg/journalctl -k are good places to look. sudo journalctl -k -b0 | grep -F 'apparmor="DENIED"' HTH, Simon
Bug#940956: systemd unit description worded misleadingly
Hi Mark, On Sun, 22 Sep 2019 15:05:19 +0200 Marc Haber wrote: > 1 [4/4992]mh@torres:~ $ sudo systemctl cat openvpn@.service > /lib/systemd/system/openvpn@.service > [Unit] > Description=OpenVPN connection to %i > > leads to the misleading output "OpenVPN connection to server" when an > OpenVPN instance called "server" is started which doesnt connect > anywhere but instead waits for an incoming connection. > > Maybe this should be re-worded like "OpenVPN instance (%i)". While "instance" indeed aligns better with the systemd concept, I believe the newer units have better descriptions: $ systemctl cat openvpn@.service \ openvpn-server@.service \ openvpn-client@.service | grep Description Description=OpenVPN connection to %i Description=OpenVPN service for %I Description=OpenVPN tunnel for %I The openvpn@.service variant should probably be avoided but is supposedly kept for backward compatibility. HTH, Simon
Bug#953891: msmtp fails to connect to gnome-keyring with AppArmor
Hi Andrej, On 2020-03-14 11:13 a.m., Andrej Shadura wrote: > Dear Maintainer, I'm not the maintainer but have been involved with this Apparmor profile. > I’m using msmtp with AppArmor, and it cannot connect to gnome-keyring > unless I add this to the profile: > > #include > > dbus send > bus=session > interface=org.freedesktop.Secret.Service, > > Please see https://salsa.debian.org/kolter/msmtp/-/merge_requests/11 for > the patch. The MR looks good, thanks! The only thing I'd like to see added here would be the kernel denial messages you got before, please. Regards, Simon
Bug#951127: Please update to version 2.1a Beta1
Package: openvpn-auth-radius Version: 2.1-7 In 2010, upstream published a beta release [1] adding those features: - Implement accounting only feature (option: accountingonly, default false) - Implement non fatal accounting (failures during accounting let the user still connect) (nonfatalaccounting) It would be nice to have those features available in Debian. Thanks in advance. Regards, Simon 1: https://www.nongnu.org/radiusplugin/radiusplugin_v2.1a_beta1.tar.gz
Bug#935819: msmtp cannot read symbolic linked ~/.msmtprc config file
Hi Roger, On Wed, 28 Aug 2019 18:42:36 +0900 Roger Shimizu wrote: > Thanks for the hint! > Yes, I confirm it's an apparmor issue after checking dmesg log. > And I added one line to /etc/apparmor.d/usr.bin.msmtp to fix my problem. > > Enclosed is the patch. > I think since "dot_msmtprc" can be the user setting file, why not > adding another "_msmtprc"? > And it's no harm. :-P I've submit a merge request [*] that permits more name variations which should cover your needs. Regards, Simon *: https://salsa.debian.org/kolter/msmtp/merge_requests/10
Bug#942749: Please add /usr/bin/keyring as secret helper
Hi Daniele,
On Sun, 20 Oct 2019 23:10:29 +0200 Daniele Tricoli wrote:
> Package: msmtp
> Version: 1.8.6-1
> Severity: wishlist
>
> Hello,
> I recently switched from gpg to python-keyring[¹] to handle the
> password. Could you consider adding keyring as a secret helper?
Sounds reasonable, thanks for suggesting!
> Currently I just patched the msmtp profile as follow:
>
> --- /etc/apparmor.d/usr.bin.msmtp 2019-10-20 13:29:11.126575030 +0200
> +++ /tmp/usr.bin.msmtp 2019-10-20 13:28:59.062477179 +0200
> @@ -49,6 +49,7 @@
> /usr/bin/passPUx,
> /usr/bin/headPUx,
> /{,usr/}bin/cat PUx,
> +/usr/bin/keyring PUx,
>}
>
>#include
>
> and it works as expected.
I've submit a merge request [*] with your suggestion.
*: https://salsa.debian.org/kolter/msmtp/merge_requests/10
Regards,
Simon
> Thanks in advance,
> Daniele
>
> [¹] https://tracker.debian.org/pkg/python-keyring
Bug#944188: /etc/msmtprc password disclosure
Hi Jakub, On 2019-11-05 9:29 a.m., Jakub Wilk wrote: > Package: msmtp > Version: 1.8.6-1 > Tags: security > > If /etc/msmtprc is readable by group msmtp (as suggested in > README.Debian), any user can acquire password from that file: > > $ ls -l /etc/msmtprc > -rw-r- 1 root msmtp 86 Nov 5 15:06 /etc/msmtprc > > $ cat /etc/msmtprc > cat: /etc/msmtprc: Permission denied > > $ msmtp --debug nob...@example.org < /dev/null > loaded system configuration file /etc/msmtprc > ignoring user configuration file /home/jwilk/.msmtprc: No such file or > directory > falling back to default account > using account default from /etc/msmtprc > ... > --> AUTH PLAIN AGFsaWNlAGh1bnRlcjI= > ... > > $ base64 -d <<< 'AGFsaWNlAGh1bnRlcjI=' | tr '\0' ':'; echo > :alice:hunter2 Nice catch! Having /etc/msmtprc group readable is AFAIK, a "debianism". I don't know if upstream endorses this method of restricting access to the default account's password. That said, I think it would be feasible for msmtp to obfuscate the AUTH line when the UID/GID do not match the EUID/EGID and the config file used it not world-readable. The upstream developer is usually very responsive so it would be great if you could report it to him. Thank you! Simon
Bug#944188: /etc/msmtprc password disclosure
On 2019-11-05 3:30 p.m., Jakub Wilk wrote: > * Simon Deziel , 2019-11-05, 10:02: >> Having /etc/msmtprc group readable is AFAIK, a "debianism". > > This is my understanding, too. > >> I don't know if upstream endorses this method of restricting access to >> the default account's password. > > I don't belive they do. > >> That said, I think it would be feasible for msmtp to obfuscate the >> AUTH line when the UID/GID do not match the EUID/EGID and the config >> file used it not world-readable. > > That wouldn't be sufficient. The attacker could run: > > $ msmtp --proxy-host=$HOST --proxy-port=$PORT --tls=off --auth=plain > nob...@example.org < /dev/null > > to make msmtp send unencrypted password to a proxy server of the > attacker's choice. That's an interesting variation because it also defeat other ways of concealing the password from users (like a secret helper to decrypt it). Maybe the proxy directives provided as argument or env vars could be ignored when the UID/GID do not match the EUID/EGID. Simon
Bug#942457: msmtp: Running msmtp as a user and Apparmor
Hello Francesco, On 2019-10-16 1:41 p.m., Francesco Ariis wrote: > Package: msmtp > Version: 1.8.3-1 > Severity: normal > > Dear Maintainer, > > I wonder how appropriate the current Apparmor configuration is for > msmtp. Story time: > > - After dist-upgrading my system to buster, my msmtp setup stopped > working. > - I invoke msmtp as: msmtp -C /home/f/cfg/msmtp/msmtpall > It exited with this error: msmtpall: Permission denied > - The reason and fix for this were clearly illustrated in > NEWS.Debian.gz; the fix involved some messing with /etc/ > > Everything went fine but I wonder: should I be touching /etc/ to > configure a program I run as a user with a config that is located > in my $HOME? > What if I had not root access? It's really up to you but if you'd like to not workaround this with root privileges, you could move/rename the config file so that it matches a more generic/common name that's allowed by the Apparmor profile. Alternatively, you could even stick with your existing way of invoking msmtp if you do a minor change. You'd need to move the conf around and use a symlink like this (untested): mv /home/f/cfg/msmtp/msmtpall /home/f/.msmtpall ln -s /home/f/.msmtpall /home/f/cfg/msmtp/msmtpall Apparmor only cares about the final destination of a symlink and "~f/.msmtpall" is permitted by the policy. Let me know if that doesn't work. Regards, Simon
Bug#941368: savelog prompts when overwriting files that are read only
Here is a merge request addressing the bug: https://salsa.debian.org/debian/debianutils/merge_requests/3 Regards, Simon
Bug#941368: savelog prompts when overwriting files that are read only
Package: debianutils Version: 4.9 If savelog is invoked as a *normal user* and asked to create files that are not writeable (-m 0400), it will prompt during mv: $ savelog -qm 0400 bar mv: replace 'bar', overriding mode 0400 (r)?
Bug#940716: openvpn: Missing systemd-resolved update example
Hi Holger, I did the exact same thing as you months ago until I noticed the existence of "openvpn-systemd-resolved" that happens to be a "suggested" package: On 2019-09-19 7:37 a.m., Holger Mueller wrote: ... > Versions of packages openvpn suggests: > ii openssl 1.1.1c-1 > pn openvpn-systemd-resolved > pn resolvconf It worked well in my tests so you should give it a try. Regards, Simon
Bug#935819: msmtp cannot read symbolic linked ~/.msmtprc config file
On 2019-08-28 5:42 a.m., Roger Shimizu wrote: > control: severity -1 wishlist > control: tag -1 +patch > > Dear Simon, > > On Tue, Aug 27, 2019 at 1:26 AM Simon Deziel wrote: >> >> This permission denied is likely due to Apparmor not letting msmtp >> access a "random file". The Apparmor profile only allows reading the >> config from a few different locations and the rest is denied. Please >> consult the NEWS file for details and/or the profile itself: >> /etc/apparmor.d/usr.bin.msmtp >> >> The NEWS file provides possible workarounds to support your >> "non-standard" setup. If you have any questions after that, please let >> us know! > > Thanks for the hint! > Yes, I confirm it's an apparmor issue after checking dmesg log. > And I added one line to /etc/apparmor.d/usr.bin.msmtp to fix my problem. > > Enclosed is the patch. > I think since "dot_msmtprc" can be the user setting file, why not > adding another "_msmtprc"? > And it's no harm. :-P The "dot_" prefix was added to support chezmoi [1], would you mind letting us know which system you are using that wants to use "_" prefixes? Thanks, Simon 1: https://github.com/twpayne/chezmoi
Bug#935819: msmtp cannot read symbolic linked ~/.msmtprc config file
Hello Roger, On 2019-08-26 11:41 a.m., Roger Shimizu wrote: > I tried to put my .msmtprc to somewhere else than $HOME, and just make a > symbolic link to $HOME. But msmtp refused to read that way and report: > > > $ msmtp -v -t < ../email.txt > ignoring system configuration file /etc/msmtprc: No such file or directory > ignoring user configuration file /home/[HOME]/.msmtprc: Permission denied > falling back to default account > msmtp: account default not found: no configuration file available > This permission denied is likely due to Apparmor not letting msmtp access a "random file". The Apparmor profile only allows reading the config from a few different locations and the rest is denied. Please consult the NEWS file for details and/or the profile itself: /etc/apparmor.d/usr.bin.msmtp The NEWS file provides possible workarounds to support your "non-standard" setup. If you have any questions after that, please let us know! Regards, Simon
Bug#933551: msmtp can't write logs to an encfs file
Hello Vincent,
On 2019-07-31 9:49 a.m., Vincent Hobeïka wrote:
> Package: msmtp
> Version: 1.8.3-1
> Severity: normal
>
> Dear Maintainer,
>
> msmtp is unable to write logs into an encfs file. If I try to write
> the logs elsewhere everything is fine.
>
> I believe I have the same problem regarding the reading of the
> .msmtprc since I had to move it outside of my encfs folder too.
>
> Here is an example of error message I obtain when trying to write logs
> in an encfs file:
>
> message-send-mail-with-sendmail: Sending...failed to msmtp: cannot log to
> /home/vincent/orgd/msmtp.log: cannot open: Permission denied; msmtp: log info
> was: host=smtp.gmail.com tls=on auth=on user=vincent.hobe...@gmail.com
> from=vincent.hobe...@gmail.com recipients=someper...@gmail.com mailsize=11420
> smtpstatus=250 smtpmsg='250 2.0.0 OK 1564578476 s17sm12382144ejz.70 - gsmtp'
> exitcode=EX_OK;
>
> Prior to Buster things worked fine with encfs. Could this be related
> to the apparmor settings? I am not at ease with apparmor and can't
> provide further debugging info. Feel free to ask me to try different
> settings.
You are correct that it's due to the Apparmor profile not permitting
this. encfs is not supported by the stock profile. You have multiple
options to workaround this:
1) log elsewhere
2) add a rule to the local override file
(/etc/apparmor.d/local/usr.bin.msmtp)
3) disable the apparmor profile completely
I would recommend 2) as the safest option. Please see the NEWS file for
the full details but it should look like this (as root):
echo ' owner @{HOME}/orgd/msmtp.log wk,' \
>> /etc/apparmor.d/local/usr.bin.msmtp
apparmor_parser -R /etc/apparmor.d/usr.bin.msmtp
Then it should be able to log to the real backing file under
~vincent/orgd. Please let me know if the above still doesn't work.
Regards,
Simon
Bug#933771: AppArmor profile prevents reading password on tty
Hello, On 2019-08-03 4:29 a.m., VA wrote: > Package: msmtp > Version: 1.8.3-1 > > msmtp is capable of reading SMTP passwords in a conf file, using an > external command, or reading it on the TTY. So it tests by opening > /dev/tty: > > https://git.marlam.de/gitweb/?p=msmtp.git;a=blob;f=src/password.c;h=aa3b1b530e6e17f3e6d45b395bf399ba99924ecc;hb=HEAD#l198 > > > However, the AppArmor profile prevents this, so in the default > configuration, msmtp cannot read the tty: > > msmtp: authentication method PLAIN needs a password > msmtp: could not send mail (account xxx from xxx/.msmtprc) > > It would be enough to add > > #include > > in /etc/apparmor.d/usr.bin.msmtp though. Thank you very much for reporting the issue! I just submit [*] that is very similar and tested fine here. Regards, Simon *: https://salsa.debian.org/kolter/msmtp/merge_requests/8
Bug#928178: apparmor: thunderbird fails to start, saying that is already running
Hello,
On 2019-05-02 10:58 a.m., Carsten Schoenert wrote:
> Hi,
>
> Am 02.05.19 um 09:05 schrieb Ulrike Uhlig:
>>> Well, but who has enabled AA in PC? I'm sure that I have not worked on
>>> /etc in these days and I am the only one can access on it. In my opinion
>>> there is a bug in some package update that has enabled TB AA profile...
>>> but in effect I realize that to be believable someone else would find
>>> this unbelievable behaviour...
>>
>> Maybe you accidentally upgraded to Buster or you are using a kernel that
>> has AA enabled by default.
>
> the starting email of this bugreport is showing an installed kernel from
> backports. So for me it's quite obvious *why* apparmor is installed and
> has activated all the profiles for the various packages that come along
> with AA profiles which should be also activated then.
>
>> Kernel: Linux 4.19.0-0.bpo.4-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
>> LANGUAGE=it_IT.UTF-8 (charmap=UTF-8)
>
> I can remember we have such discussions again and again from time to
> time and users are surprised why Thunderbird isn't working any more as
> usual or expected after some random update. So far I remember it was
> always an active TB AA profile. And users are even more surprised if I
> tell them the TB packaging in Stretch did never had an automatically
> activated AA profile, in other words, they have it activated it by
> themselves.
>
> In this report there are two things that have come together in my eyes.
>
> 1.) An activated AA profile for Thunderbird.
>
> 2.) An different path for ${HOME} because of an membership within a
> Windows domain.
>
> The first one isn't a big problem anymore in newer days, the current AA
> profile is covering for sure about 95% of the use cases.
Agreed.
> The second point isn't covered nicely until now in the AppArmor
> installations within Debian at least. But I think also that Thunderbird
> isn't the only package that will suffer from this problem and we will
> need a more general solution for this. And this needs to go into
> Apparmor itself instead of every body tries to implement some super
> logic within their AA package profile.
Thunderbird is definitely not the only package affected. There already
is a way to deal with non-standard home path: local adjustment of the
'tunables' provided by Apparmor. Those will affect every profile using
the @{HOME} variable.
> Currently I've no idea how to detect a membership of a Windows domain
> nicely, for sure this is solvable by some PAM voodoo. I have simply no
> knowledge in this area. And I have no environment to test something. It
> seems we just need to trigger a dpkg-reconfigure of AA if the PC is
> within a domain membership.
I don't think it's specific to domain members as all it takes is to have
a home dir located somewhere non-standard (!= /home/$user) as the
default value for @{HOME} only permits what's common.
That said, having a dpkg-reconfigure trigger when $HOME non-standard
might be an idea, but that's a concern for Apparmor itself, not
Thunderbird :)
Regards,
Simon
Bug#928178: apparmor: thunderbird fails to start, saying that is already running
Hi,
On 2019-04-30 5:05 a.m., Piviul wrote:
> Il 30/04/19 10:31, Ulrike Uhlig ha scritto:
>> Hi!
>>
>> On 30.04.19 09:31, Piviul wrote:
>>> Il 30/04/19 07:51, Carsten Schoenert ha scritto:
>>
downgrading severity as AppArmor isn't officially supported and
activated for the Thunderbird package.
>>> but I'm not the one that activated apparmor for thunderbird: AFAIK in
>>> debian stretch (debian stable) the apparmor profile is enabled by
>>> default!
>>
>> There are two things:
>>
>> - installing and activating AppArmor
>> - activating a profile to confine a given software
>>
>> The latter is sometimes done by packages but only takes effect if you
>> did the former.
>>
>> In Stretch, AppArmor is not activated by default. Did you activate it
>> and use it for other software?
> I can't remember why have installed apparmor.. even if the kernel
> recommend it!
>
>> [...]
>> Your folder path was:
>> name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"
>>
>> The issue is the "psala", that does not look like a standard path to me,
>> or is there a software which creates such a folder?
> is a standard path for remote users. In this case the PC is join to a
> samba domain but AFAIK every time you use remote authentication
> (winbind, ldap...) the user home have a path like this.
I'm not sure there is a standard for remote homes, I've seen both
/home/$user and /home/$domain/$user. That said, have you tried
augmenting the definition of @{HOME}? See /etc/apparmor.d/tunable/home
and /etc/apparmor.d/tunable/home.d/*
Regards,
Simon
Bug#927961: strongswan Apparmor profiles are missing the setpcap capability
On 2019-04-25 9:41 a.m., Simon Deziel wrote: > I'll soon be proposing a fix via salsa. https://salsa.debian.org/debian/strongswan/merge_requests/4 signature.asc Description: OpenPGP digital signature
Bug#927961: strongswan Apparmor profiles are missing the setpcap capability
Package: strongswan Version: 5.7.1-1 Hello, A user on Ubuntu reported [1] that Strongswan 5.7.1-1 no longer worked with privilege downgrade. He also traced the root cause to a missing capability: CAP_SETPCAP. I'll soon be proposing a fix via salsa. Thanks, Simon 1: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1826238 signature.asc Description: OpenPGP digital signature
Bug#834167: Should allow pinning server key
Hi Christoph, On Fri, 12 Aug 2016 19:09:40 +0200 Christoph Egger wrote: > It's a bit unfortunate that tls_fingerprint pinns the server > certificate instead of the public key. Especially with the new kid > letsencrypt certificate turnover times are getting even shorter all > the time while keys can easily be kept the same for years. I too faced this problem and resorted to pinning the signing CA. This allows rotating the cert/key of the mail server and also not trust every single CAs out there. If you want to do so for Let's Encrypt specifically, you can put Let's Encrypt Authority X3 (primary) and X4 (backup) certs in a file (i.e: /etc/ssl/certs/LetsEncryptAuthorityX3-X4.crt) and reference it with "tls_trust_file". HTH, Simon signature.asc Description: OpenPGP digital signature
Bug#921538: Fails to start since upgrade to 1.9.0-1
On 2019-02-09 8:28 p.m., Robert Edmonds wrote: > Probably it's better to use the --with-chroot-dir= argument to configure > rather than directly patching the source to change the default. Indeed and that's what's being proposed in the merge request. Regards, Simon
Bug#921538: Fails to start since upgrade to 1.9.0-1
On 2019-02-08 7:26 a.m., Kepi wrote: > Chroot workaround is working for me too. Good. > Anyway in the long term would it be better to have chroot setup > automatically again? I found out that it was working before, at least > some work was done in #579622 for auto support. The auto-chroot setup was broken with the (welcomed) move to systemd notify. I have a working PoC to restore the functionality that I'll submit soon as another merge request. Regards, Simon signature.asc Description: OpenPGP digital signature
Bug#900241: no root.key provided by libunbound2
On 2019-01-20 3:59 p.m., Ondřej Surý wrote: > That seems overly complicated for a little gain. dns-root-data has the > current root key and keeps it up-to-date for all DNS related packages. Here's a much simpler fix: https://salsa.debian.org/dns-team/unbound/merge_requests/4 Regards, Simon
Bug#921538: Fails to start since upgrade to 1.9.0-1
Here is a merge request [*] to disable chroot'ing again like it has been since version 1.0.0-3 Regards, Simon *: https://salsa.debian.org/dns-team/unbound/merge_requests/3 signature.asc Description: OpenPGP digital signature
Bug#921538: Fails to start since upgrade to 1.9.0-1
Hi Ryan, On 2019-02-06 11:12 a.m., Ryan Kavanagh wrote: > Since the upgrade to 1.9.0-1, unbound fails to start. Purging the > package and reinstalling does not fix the issue. The errors seem to be > due to being unable to read various configuration files. > > Feb 06 11:01:12 zeta unbound[28647]: [28647:0] error: unable to open > /var/lib/unbound/root.key for reading: No such file or directory > Feb 06 11:01:12 zeta package-helper[28648]: [1549468872] > unbound-checkconf[28651:0] error: Could not open > /etc/unbound//etc/unbound/unbound.conf: No such file or director It seems like chroot'ing to /etc/unbound is attempted. To workaround you can try this: cat << EOF > /etc/unbound/unbound.conf.d/chroot.conf server: chroot: "" EOF service unbound restart Regards, Simon signature.asc Description: OpenPGP digital signature
Bug#919511: unbound: apparmor enabled after systemd service started, thus not applied
Hi Julian, On 2019-01-16 1:53 p.m., Julian Andres Klode wrote: > The unbound package runs dh_apparmor too late, causing the generated postinst > to have dh_enable_systemd parts run first, which enable and start the service. > > Because the process is already running the parts added by dh_apparmor to load > the apparmor files have no effect until a manual service restart. I was able to verify this behavior and have proposed a fix [*] that worked here. Regards, Simon *: https://salsa.debian.org/dns-team/unbound/merge_requests/2
Bug#900241: no root.key provided by libunbound2
On 2019-01-20 3:59 p.m., Ondřej Surý wrote: > That seems overly complicated for a little gain. dns-root-data has > the current root key and keeps it up-to-date for all DNS related > packages. Boiler plate aside, it essentially turns unbound-anchor into a daily job that keeps the root.key current (seeding it from dns-root-data if applicable). I couldn't find a simpler way to implement RFC 5011 for those not running the full fledged unbound daemon. Considering that libs and tools expect the root.key to be under /var/lib/unbound and unbound itself wants to write to that file for RFC 5011, I can't think of a simpler way to rely only on dns-root-data [*]. IIRC, unbound is installed by default in Fedora so the concept received some testing already but I agree it's a little complex. I'm definitely open to implement a different solution if you have an idea in mind. Regards, Simon *: updates to dns-root-data can take time to propagate to downstream distros so unbound-anchor could provide an elegant failsafe solution
Bug#900241: no root.key provided by libunbound2
Inspired by discussions on the unbound-users list [1] and what other distros (SLES, Fedora) are doing to keep the root.key current and make it available for other unbound related packages I came up with this merge request [2]. Comments and suggestions are welcome. Thanks, Simon 1: https://nlnetlabs.nl/pipermail/unbound-users/2018-November/011086.html 2: https://salsa.debian.org/dns-team/unbound/merge_requests/1
Bug#919391: msmtp: AppArmor profile doesn't include ~/.config/msmtp/
Hello Mantas,
On 2019-01-15 7:59 a.m., Mantas Mikulėnas wrote:
> 1. the traditional @{HOME}/.msmtprc, and
> 2. the XDG Basedir compatible @{HOME}/.config/msmtp/config
>
> The new AppArmor profile is missing the latter path. I think both
> default locations should be included in the standard profile. Similar to
> the current entry, the whole .config/msmtp/* should probably be
> whitelisted.
Apparmor fixes were proposed very recently in [1] addressing this issue.
> (Technically the latter is $XDG_CONFIG_HOME/msmtp/config, but I
> understand that AppArmor won't care about the user's environment
> variables, and I think that's fine – the local profile can be used.)
That is correct, no variable is looked up but the default value is
covered in the proposed fix.
Regards,
Simon
1: https://salsa.debian.org/kolter/msmtp/merge_requests/3
Bug#919326: msmtp: account default not found: no configuration file available
On 2019-01-14 6:03 p.m., Sergio Mendoza wrote:
> Yes. I have now checked and I have .msmtprc as a symlink. If it is not
> a symlink then I have no problems and everything runs smooth.
Great, thanks Sergio.
> In any case
> this is the output you asked for:
>
> root@quetzalli:~# dmesg | grep apparmor | tail -n 20
> [1064151.025521] audit: type=1400 audit(1547506707.004:157):
> apparmor="DENIED" operation="open" profile="/usr/bin/msmtp"
> name="/home/sergio/Private/.msmtprc" pid=14560 comm="msmtp"
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
This should eventually work even when ~/.msmtprc will be a symlink to
~/Private/.msmtprc. I hope the fix will land in the next package update [*].
> [1064177.994021] audit: type=1400 audit(1547506733.971:158):
> apparmor="DENIED" operation="open" profile="/usr/bin/msmtp"
> name="/home/sergio/mail/msmtp/log.txt" pid=14580 comm="msmtp"
> requested_mask="ac" denied_mask="ac" fsuid=1000 ouid=1000
> [1064281.325901] audit: type=1400 audit(1547506837.302:159):
> apparmor="DENIED" operation="open" profile="/usr/bin/msmtp"
> name="/home/sergio/mail/msmtp/log.txt" pid=14656 comm="msmtp"
> requested_mask="ac" denied_mask="ac" fsuid=1000 ouid=1000
This shows that msmtp was denied logging to ~/mail/msmtp/log.txt.
Unfortunately, this isn't a common location to for logs so it likely
won't be supported by the default base Apparmor profile. You have few
options to make it work though:
1) you can have it log to more usual locations like one of those:
~/.msmtp.log
~/.cache/msmtp/*.log
2) add this local override rule to /etc/apparmor.d/local/usr.bin.msmtp:
owner @{HOME}/mail/msmtp/log.txt wk,
3) disable the Apparmor profile
1 would be preferable but for 2 and 3, please refer to the README.Debian
file for detailed instructions.
Regards,
Simon
*: https://salsa.debian.org/kolter/msmtp/merge_requests/3
Bug#919326: msmtp: account default not found: no configuration file available
Hi Sergio, On 2019-01-14 5:40 p.m., Sergio Mendoza wrote: > A few days ago, msmtp fails to work. It all seems to be related to the > inability to read ~/.msmtprc file. In other words it seems that > ~/.msmtprc needs to have mode 644. This is not at all desired since > sensible (private) information can be included in that file. The package > msmtp should run with no trouble when the user configuration file > ~/.msmtprc has mode 600. Indeed, it should work with ~/.msmtprc with mode 0600. Is it working when you have it set to 0644? > I am sending you some useful output so that you can check the relevance of > the > situation (please note that I tried playing with stable, testing and sid > versions of msmtp and I get the same output -this lead me to think whether > the problem is with msmtp or with some other related package): > > >> > > sergio@quetzalli:~$ echo "Hello World" | msmtp -d ser...@mendozza.org > ignoring system configuration file /etc/msmtprc: No such file or directory > ignoring user configuration file /home/sergio/.msmtprc: Permission denied > falling back to default account > msmtp: account default not found: no configuration file available > > > > As such, the bug leaves the package fully unusable. That's unexpected but could be related to the Apparmor profile changes that went in recently. Is /home/sergio/.msmtprc a symlink by any chance? If yes, could you share the output of "ls -l /home/sergio/.msmtprc"? Could you please also share the output of "dmesg | grep apparmor" Thanks in advance, Simon
Bug#918820:
On 2019-01-14 1:42 p.m., demuredemeanor wrote: > After testing this new configuration (and retesting after removing my > temporary apparmor force-complain symlink) msmtp seems to working for > both `pass` and the GNU stow symlink. Thanks for the testing and feedback!
Bug#919323: msmtp: apparmor blocks reading configuration file ~/.msmtprc
Hi Robbie, On 2019-01-14 5:28 p.m., Robbie Harwood wrote: > Package: msmtp > Version: 1.8.1-2 > Severity: important > > Dear Maintainer, > > Trying to send mail with msmtp after upgrading, it fails with "no > configuration file available". The audit line is: > > audit: type=1400 audit(1547504604.078:263): apparmor="DENIED" > operation="open" profile="/usr/bin/msmtp" name="/home/bos/rharwood/.msmtprc" > pid=15946 comm="msmtp" requested_mask="r" denied_mask="r" fsuid=21259 > ouid=21259 > > I wish I could tell you more, but I know nothing about apparmor. That's exactly what we need for such bugs so thanks! A bunch of fixes to the Apparmor profile are being worked on [1] and it should make it work for you. Regards, Simon 1: https://salsa.debian.org/sdeziel-guest/msmtp/blob/misc-fixes/debian/apparmor/usr.bin.msmtp
Bug#918655: Expanding the NEWS
On 2019-01-14 11:17 a.m., Gard Spreemann wrote: > > Simon Deziel writes: > >> Would you mind testing this base profile [1] and report back. If it >> still doesn't work for you, please provide the denial logs from dmesg. > > It works well! I realize that the game of adding more and more allowed > stuff to the profile might be futile, but pass and some common shells > seem like reasonable additions. Thanks for testing and reporting back. > Thanks a lot - and for maintaining msmtp! I'm not the maintainer, I'm merely helping to reduce the friction with the Apparmor profile I authored. I'm waiting for more feedback on this test branch and if everything looks good, I'll propose it for merging. Thanks again, Simon
Bug#919266: msmtp: AppArmor profile makes .msmtprc symlink unusable
Hi Jani, On 2019-01-14 5:17 a.m., Jani Nikula wrote: > I store my dotfiles in a git repo, and symlink the actual dotfiles to > the git checkout. After msmtp update, the AppArmor profile blocked this: > > [622972.288769] audit: type=1400 audit(1547459536.817:103): apparmor="DENIED" > operation="open" profile="/usr/bin/msmtp" name="/path/to/dotfiles/.msmtprc" > pid=2564 comm="sendmail" requested_mask="r" denied_mask="r" fsuid=1000 > ouid=1000 > > Without the symlink it works fine, but then msmtp doesn't play well with > my dotfiles approach. Either I'll have to nuke the AppArmor profile, or > start looking for another mta. Would you mind testing this base profile [1] and report back. If it still doesn't work for you, please provide the denial logs from dmesg. Regards, Simon 1: https://salsa.debian.org/sdeziel-guest/msmtp/blob/misc-fixes/debian/apparmor/usr.bin.msmtp
Bug#918655: Expanding the NEWS
On 2019-01-14 9:52 a.m., Gard Spreemann wrote: > Thanks to the maintainer for taking care of things so quickly. > > Could perhaps the NEWS file be expanded a little bit, though? I would > not be surprised if my setup is quite common: I use > > passwordeval /usr/bin/pass foo | head -n 1 Yes, thanks for reporting about this! > with msmtp, and have logging enabled. In such a setup, the apparmor > profile has to be expanded to allow execution of pass, the default > shell, and also to be allowed to write to the logfile. (Incidentally, if > each user has a different log file set up, this sounds like a bit of a > hassle). > > I personally ended up disabling the apparmor profile. Would you mind testing this base profile [1] and report back. If it still doesn't work for you, please provide the denial logs from dmesg. Regards, Simon 1: https://salsa.debian.org/sdeziel-guest/msmtp/blob/misc-fixes/debian/apparmor/usr.bin.msmtp
Bug#918820:
On 2019-01-14 5:32 a.m., demuredemeanor wrote: > The apparmor change has royally broken my neomutt+msmtp. > > The two big issues this brings to me is 1) I use `pass` ( > https://www.passwordstore.org) as my password manager with passworleval and > 2) as a user of GNU Stow for my dotfiles apparmor hates that my ~/.msmtprc > is symlinked. Would you mind testing this base profile [1] and report back. If it still doesn't work for you, please provide the denial logs from dmesg. Regards, Simon 1: https://salsa.debian.org/sdeziel-guest/msmtp/blob/misc-fixes/debian/apparmor/usr.bin.msmtp
Bug#919266: msmtp: AppArmor profile makes .msmtprc symlink unusable
Hi Jani,
On 2019-01-14 5:17 a.m., Jani Nikula wrote:
> Package: msmtp
> Version: 1.8.1-2
> Severity: important
>
> Dear Maintainer,
>
> I store my dotfiles in a git repo, and symlink the actual dotfiles to
> the git checkout. After msmtp update, the AppArmor profile blocked this:
>
> [622972.288769] audit: type=1400 audit(1547459536.817:103): apparmor="DENIED"
> operation="open" profile="/usr/bin/msmtp" name="/path/to/dotfiles/.msmtprc"
> pid=2564 comm="sendmail" requested_mask="r" denied_mask="r" fsuid=1000
> ouid=1000
>
> Without the symlink it works fine, but then msmtp doesn't play well with
> my dotfiles approach. Either I'll have to nuke the AppArmor profile, or
> start looking for another mta.
Indeed, Apparmor only cares about the final target file, not symlinks
leading to it.
Since you are not the first to complain about the need to store .msmtprc
in a different directory, I'll propose an updated base profile to permit
this file to be store anywhere in $HOME. Hopefully that will match your
"/path/to/dotfiles" case.
In the meantime, you may want to add this rule to the local override
file (/etc/apparmor.d/local/usr.bin.msmtp) and recompile the profile:
owner @{HOME}/**/.msmtprc r,
Regards,
Simon
Bug#918820:
On 2019-01-14 5:32 a.m., demuredemeanor wrote: > The apparmor change has royally broken my neomutt+msmtp. > > The two big issues this brings to me is 1) I use `pass` ( > https://www.passwordstore.org) as my password manager with passworleval and I think this helper should be easy and safe to support. Could you please provide your denial messages from dmesg? > 2) as a user of GNU Stow for my dotfiles apparmor hates that my ~/.msmtprc > is symlinked. Right, Apparmor rules are applied to the final target of a symlink. Depending on where you have that target file stored, it might make sense to add it to the local override file (local/usr.bin.msmtp)? Regards, Simon
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
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
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#662960: ssmtp doesn't validate server TLS certificates
On 2019-01-09 10:23 a.m., Cédric Dufour - Idiap Research Institute wrote: > PS: ssmtp is extremely handy to forward machine-generated messages in large > deployments, internally, iow. where TLS is not required ssmtp seems like abandonware. Have you tried msmtp(-mta)? It works in a similar way, is well supported and does the right thing when you want TLS. Regards, Simon
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#918655: msmtp: Apparmor causing Permission denied when creating tmp files and logging
Hi, On 2019-01-08 5:03 p.m., Emmanuel Bouthenot wrote: > On Mon, Jan 07, 2019 at 08:35:25PM -0500, Simon Deziel wrote: > [...] > >> I agree, I should have thought of that. How about adding the text from >> README.Debian as a NEWS entry? >> >> I will do some testing with 1.8.1-1 but in the meantime, please find >> attached a more up to date profile that received more testing and also >> incorporates your feedback (thanks!). > > Thanks (to you and Ondra) for your feedback. > > I've just uploaded msmtp 1.8.1-2 with your patch and a notice in > debian/NEWS Your fast turnaround is much appreciated, thanks! Regards, Simon
Bug#918655: msmtp: Apparmor causing Permission denied when creating tmp files and logging
Hello,
On 2019-01-07 6:56 p.m., Ondra Kudlík wrote:
> Package: msmtp
> Version: 1.8.1-1
> Severity: important
>
> Hello,
>
> after yesterdays update I'm unable to use msmtp because of new apparmor
> profile.
>
> Error:
>
> msmtp: cannot create temporary file: Permission denied
>
> It looks like apparmor profile is expecting msmtp to create temporary files
> with name
> staring with "msmtp" which is not true (at least I can't see it in msmtp
> source
> code).
>
> Changing line to:
>
> owner /tmp/* rw,
>
> fixes problem for me.
In my tests with 1.6.6-1, it always created files like /tmp/msmtpMjeJLc
which is why I hardcoded that msmtp prefix. I'm afraid that I had
forgotten about #883354 so the actual profile evolved in parallel. I was
kind of caught by surprise by it's inclusion, my bad and sorry Emmanuel.
> Second issue is that I have log files in ~/.msmtp*.log which is maybe specific
> to my
> setup but it is widely used at least from various wikis and docs I saw.
>
> I suggest to add line to fix this issue as well.
>
> owner @{HOME}/.msmtp*.log rwk,
Sounds good to me.
> Btw. I think this is major change and should be announced through news
> mechanism,
> especially because many users have their own paths. I could save at least an
> hour
> when trying to find source of problem.
I agree, I should have thought of that. How about adding the text from
README.Debian as a NEWS entry?
I will do some testing with 1.8.1-1 but in the meantime, please find
attached a more up to date profile that received more testing and also
incorporates your feedback (thanks!).
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/secret-toolPUx,
/usr/bin/gpg{,2}PUx,
#include
}
Bug#913918: systemd improvements
Package: nsd Version: 4.1.25-3 Hello, I noticed the switch to Type=notify (yay!) and when playing with the unpublished version (4.1.25-3), I found some things that could be improved which lead me to open this merge request [1]. Regards, Simon 1: https://salsa.debian.org/dns-team/nsd/merge_requests/1 signature.asc Description: OpenPGP digital signature
Bug#867187: update chroot script to mount bind systemd notify socket
Hello Timo, On 2018-11-09 8:13 a.m., Timo Sigurdsson wrote: > However, I believe the patch is not fully correct. With the proposed > patch, mounting of the notify socket is done unter the condition that > $CHROOT_DIR and $UNBOUND_BASE_DIR are *not* equal. This means that > the socket will not be mounted if you define chroot: /etc/unbound in > your unbound configuration. So, mounting of the notify socket should > be moved outside of the existing if clause and moved into a separate > "if [ -d "$CHROOT_DIR" ]; then" clause. I don't remember testing with a chroot dir set to /etc/unbound so your point may be valid. However, please note that since Unbound writes to files inside its chroot (auto-trust-anchor-file) it may be best to avoid chroot'ing anywhere under /etc. /var/lib/unbound is a nice candidate IMHO. > This is not the only issue with the current package-helper and chroot > environtments though. The chroot should also contain /dev/random as > the documentation emphasizes Good point. I haven't had the time to actually look at the code itself to confirm if the doc is current or would need to be refreshed (like for /dev/log). If you have the time it would be great! > and the apparmor profile is missing the > capability sys_chroot. I will submit seperate bug reports For those > two issues. AFAIK, this capability has always been part of the apparmor profile [1]. Regards, Simon 1: https://salsa.debian.org/dns-team/unbound/blob/master/debian/apparmor-profile
Bug#913265: update-resolv-conf: use systemd-resolve if it's available
Package: openvpn Version: 2.4.6-1 Hello, On machines using systemd-resolved, the recommended way to configure per-link DNS and search domains is via the systemd-resolve command. As such, I sent a merge request to implement this [1]. I'd be happy if you could take a look at the merge request. I'll be pleased to address any comments you may have about it. Regards, Simon 1: https://salsa.debian.org/debian/openvpn/merge_requests/2
Bug#912569: openssh-client: openssh 7.8p1-1 and higher fail to connect to any host, "packet_write_wait: Broken pipe"
On 2018-11-01 10:40 a.m., Timo Rothenpieler wrote: > I don't have a ~/.ssh/config, only an ed25519 and rsa4096 key pair > without passwords. > /etc/ssh is untouched one from the packaged files. > > This whole setup is running in a VMWare Workstation VM, Windows 10 is > the host. Could this be https://communities.vmware.com/thread/590825
Bug#594175: Bug#712859: Bug#594175: openssh-server: support generation of ssh host keys in init script
On 2018-09-19 05:18 AM, Guido Günther wrote: > Hi, > On Wed, Jan 10, 2018 at 10:36:51AM +0100, Guido Günther wrote: >> Hi, >> On Wed, Jul 13, 2016 at 10:27:11AM +0200, Guido Günther wrote: >>> On Tue, Aug 24, 2010 at 12:23:52PM +0200, Michael Prokop wrote: Package: openssh-server Version: 1:5.5p1-4 Severity: wishlist I mentioned this issue in my talk "State of Debian (based) Linux live systems in 2010" at Debconf10. Colin suggested to talk about it later on, so I'm reporting this as a wishlist item. It would be nice if the sshd init script would support generation of ssh host keys - iff there aren't any keys present yet. The (main) use case for this feature are live systems where you usually don't want to ship pre-generated keys on one hand, on the other hand not everyone wants to generate the host keys automatically on each boot (consuming time and ressources). Taking care of key generation as someone invokes '/etc/init.d/ssh start' works fine for the Grml live systems and its users. What we're doing is something as simple as: , [ relevant snipped of Grml's ssh initscript ] | RSA1_KEY=/etc/ssh/ssh_host_key | RSA_KEY=/etc/ssh/ssh_host_rsa_key | DSA_KEY=/etc/ssh/ssh_host_dsa_key | | case "$1" in | start) | [...] | if ! test -f $RSA1_KEY ; then | log_action_msg "Generating SSH1 RSA host key..." | $KEYGEN -t rsa1 -f $RSA1_KEY -C '' -N '' || exit 1 | fi | | if ! test -f $RSA_KEY ; then | log_action_msg "Generating SSH RSA host key..." | $KEYGEN -t rsa -f $RSA_KEY -C '' -N '' || exit 1 | fi | | if ! test -f $DSA_KEY ; then | log_action_msg "Generating SSH2 DSA host key..." | $KEYGEN -t dsa -f $DSA_KEY -C '' -N '' || exit 1 | fi | [...] ` Would be great if that feature would be available in Debian/Ubuntu based (live) systems as well. :) >>> >>> I wonder if we should just create a openssh-host-keys package that ships >>> a systemd unit/init script to create the keys (as (I think it was >>> Christian) suggested at debconf. >>> >>> This just came up here as well >>> >>> https://www.redhat.com/archives/libguestfs/2016-July/msg00090.html >>> >> >> Michael is grml working around this somehow? If so can you attach a >> link? > > I have moved things into a Debian package now: > > https://source.puri.sm/Librem5/gen-sshd-host-keys Have you tried "ssh-keygen -A" ? I believe it would be the simplest way to generated the missing host keys. Regards, Simon
Bug#855539: patch for this
On Mon, 25 Sep 2017 09:52:17 +0200 Herman van Rink wrote:
> On Wed, 12 Jul 2017 17:38:10 +1000 Russell Coker
> wrote:
> > I've attached the patch I use to deal with this. While this patch may
> not be
> > suitable for a Debian package I think that it's worth sharing so other
> users
> > can make a custom version to fix this problem. It's really a big deal
> when
> > you have 30,000 logins per day...
>
> Thanks, that patch works.
Please find a slightly improved patch that also ignores IPv6 connections.
Regards,
Simon
Index: logwatch-7.4.3+git20161207/scripts/services/sshd
===
--- logwatch-7.4.3+git20161207.orig/scripts/services/sshd
+++ logwatch-7.4.3+git20161207/scripts/services/sshd
@@ -390,6 +390,10 @@ while (defined(my $ThisLine = ))
} elsif ( my ($Host,$Reason) = ($ThisLine =~ /^Received disconnect from ([^
]*)(?: port [^ ]*)?: (.*)$/)) {
# Reason 11 (SSH_DISCONNECT_BY_APPLICATION) is expected, and logged at
severity level INFO
if ($Reason != 11) {$DisconnectReceived{$Reason}{$Host}++;}
+ } elsif ($ThisLine =~ /^Disconnected from [0-9a-f:.]+ port [0-9]+$/) {
+ # annoying second message about disconnect
+ } elsif ($ThisLine =~ /^Close session: user .+ from [0-9a-f:.]+ port [0-9]+
id 0$/) {
+ # annoying message closing session
} elsif ( my ($Host) = ($ThisLine =~ /^ROOT LOGIN REFUSED FROM ([^ ]*)$/)) {
$RootLogin{$Host}++;
} elsif ( my ($Error) = ($ThisLine =~ /^Cannot release PAM
authentication\[\d\]: (.*)$/)) {
signature.asc
Description: OpenPGP digital signature
Bug#900241: no root.key provided by libunbound2
On Sun, 27 May 2018 18:01:01 -0400 Simon Deziel wrote: > A possible solution would be to have libunbound2 depend on > unbound-anchor and have the unbound-anchor package ship a cron job (or > systemd.timer unit) to periodically refresh the root.key file. After some research, Fedora/Red Hat adopted a very similar approach based on systemd [1]. > If the proposed solution makes sense to you, I'd be happy to work on the > implementation. That offer still holds! Regards, Simon 1: https://archive.fedoraproject.org/pub/fedora/linux/releases/28/Everything/source/tree/Packages/u/unbound-1.7.0-4.fc28.src.rpm
Bug#900241: no root.key provided by libunbound2
Package: unbound Version: 1.7.1-1 TL;DR: applications using libunbound2 should have access to a fresh root.key If one installs unbound-anchor or unbound-host or any other application using libunbound2, they will be missing a fresh copy of the root.key for DNSSEC validation. This is because /var/lib/unbound/root.key is managed by a helper script provided by the unbound package only. Ideally, installing libunbound2 should provide a root.key that is kept up to date for root KSK rollovers. A possible solution would be to have libunbound2 depend on unbound-anchor and have the unbound-anchor package ship a cron job (or systemd.timer unit) to periodically refresh the root.key file. If the proposed solution makes sense to you, I'd be happy to work on the implementation. Regards, Simon P.S: This problem was initially reported to Ubuntu https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1771545 signature.asc Description: OpenPGP digital signature
Bug#883349: Acknowledgement (/etc/msmtprc should not be world readable)
On Sat, 2 Dec 2017 14:39:00 -0500 Simon Deziel <si...@sdeziel.info> wrote: > Please find attached a patch that: > > * Removes world read access to /etc/msmtprc and chgrp to "mail". > * Installs the msmtp binary as setgid and owned by "root:mail". Seth Arnold from the Ubuntu security team quickly reviewed my patch and found a blatant problem. Here's the IRC log sarnold: sdeziel: hrm, not sure I love that patch :/ ... normally most tools aren't written robustly enough to be setgid sarnold: sdeziel: if a user config file asks to log to something writable by group mail, what happens? ... sarnold: a dedicated group would definitely be safer So when I'll have more time, I'll propose an updated patch that creates a dedicated group to use with setgid. Regards, Simon
Bug#894907: [thunderbird] apparmor denies access to ~/.gnupg/tofu.db
Hi Carsten, On 2018-04-05 11:22 AM, Carsten Schoenert wrote: > could you please have a look at this? > I can't overview any side effects if the suggested change would be > applied. Thanks! The revised patch looks good and legitimate. Regards, Simon
Bug#891705: [Pkg-dns-devel] Bug#891705: Apparmor policy prevents chown/chmod of the Unix control socket
Hi Robert, On 2018-02-28 01:08 PM, Simon Deziel wrote: > I couldn't find a way to do the merge proposal through the WebUI of > salsa (maybe because I'm a -guest). Please see the refreshed Apparmor > profile at [1]. Feedback is welcome of course! > > 1: https://salsa.debian.org/sdeziel-guest/unbound/tree/apparmor-refresh Please let me know if you have questions or would prefer to get email patches for the above branch. Regards, Simon
Bug#891705: [Pkg-dns-devel] Bug#891705: Bug#891705: Apparmor policy prevents chown/chmod of the Unix control socket
> I get a 404 on that URL, and your repository doesn't show up under: > > https://salsa.debian.org/users/sdeziel-guest/projects > > Maybe your GitLab visibility settings are misconfigured. Yes indeed. Projects default to private, fixed and tested. Sorry for the back and forth it's my first steps with salsa. Simon
Bug#891705: [Pkg-dns-devel] Bug#891705: Apparmor policy prevents chown/chmod of the Unix control socket
On 2018-02-28 11:48 AM, Simon Deziel wrote: > Yes, I'm working on a pull request/merge proposal via salsa.debian.org. > I'll be proposing a fix for all 3 Apparmor related bugs with the Unbound > profile. Shouldn't be too long. Thanks! I couldn't find a way to do the merge proposal through the WebUI of salsa (maybe because I'm a -guest). Please see the refreshed Apparmor profile at [1]. Feedback is welcome of course! Regards, Simon 1: https://salsa.debian.org/sdeziel-guest/unbound/tree/apparmor-refresh
Bug#891705: [Pkg-dns-devel] Bug#891705: Apparmor policy prevents chown/chmod of the Unix control socket
Hello Robert, On 2018-02-28 11:31 AM, Robert Edmonds wrote: > Did you mean to include the fix in your bug report? Yes, I'm working on a pull request/merge proposal via salsa.debian.org. I'll be proposing a fix for all 3 Apparmor related bugs with the Unbound profile. Shouldn't be too long. Thanks! Regards, Simon
Bug#891705: Apparmor policy prevents chown/chmod of the Unix control socket
Package: unbound Version: 1.6.7-1 Dear maintainer, An Ubuntu user reported an issue [1] with the unbound's Apparmor profile that prevents unbound from chown'ing and chmod'ing the Unix control socket if used (non-default). To reproduce: # cat << EOF > /etc/unbound/unbound.conf.d/remote-control.conf remote-control: control-enable: yes control-interface: /run/unbound.ctl EOF # service unbound restart # ls -l /run/unbound.ctl Without the fix, ls -l returns this: srw-rw 1 root root 0 Feb 23 18:40 /run/unbound.ctl= But should return: srw-rw 1 unbound unbound 0 Feb 23 18:38 /run/unbound.ctl= Regards, Simon 1: https://bugs.launchpad.net/ubuntu/+source/unbound/+bug/1749931
Bug#890139: fallback to setuid apps.plugin when setcap fails
Package: netdata Version: 1.9.0+dfsg-1 Dear maintainer, When installing netdata in a (LXD) container I noticed the setcap call would fail during postinst. I believe this is because file capabilities can only be set in the original namespace unless you run a 4.14+ kernel which includes [1]. Please consider the attached patch that will gracefully fallback to setuid apps.plugin in case of setcap failure. Upstream does something similar [2]. Regards, Simon 1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8db6c34f1dbc8e06aa016a9b829b06902c3e1340 2: https://github.com/firehol/netdata/blob/master/netdata-installer.sh#L822 diff -Nru netdata-1.9.0+dfsg/debian/netdata.postinst.in netdata-1.9.0+dfsg/debian/netdata.postinst.in --- netdata-1.9.0+dfsg/debian/netdata.postinst.in 2018-01-26 23:57:51.0 + +++ netdata-1.9.0+dfsg/debian/netdata.postinst.in 2018-01-28 23:20:51.0 + @@ -23,7 +23,8 @@ fi chown -R root:netdata /usr/lib/@DEB_HOST_MULTIARCH@/netdata/plugins.d -setcap cap_dac_read_search,cap_sys_ptrace+ep /usr/lib/@DEB_HOST_MULTIARCH@/netdata/plugins.d/apps.plugin +setcap cap_dac_read_search,cap_sys_ptrace+ep /usr/lib/@DEB_HOST_MULTIARCH@/netdata/plugins.d/apps.plugin || \ + chmod 4754 /usr/lib/@DEB_HOST_MULTIARCH@/netdata/plugins.d/apps.plugin chown netdata:adm /var/log/netdata chmod 02750 /var/log/netdata signature.asc Description: OpenPGP digital signature
Bug#888982: unusual mode used when creating /var/run subdir via systemd service
Package: tor Version: 0.3.3.1-alpha-1 Severity: minor Hi Peter, While looking at the systemd units, I noticed an unusual (to me) mode used by install when creating the directory under /var/run: ExecStartPre=/usr/bin/install -Z -m 02755 -o ... -d /var/run/... When looking in chmod(1) and install(1), I only saw the letters, 3 and 4 digits mode being documented. I don't know if the leading 0 is meant to specify octal mode (as the chmod(2) system call argument). It doesn't cause any actual problem as the resulting dir has the intended permissions (2755) but it just caught my attention and might be noticed by others so I though I'd mention it. Regards, Simon P.S: it is entirely possible that I'll learn that this "unusual to me" thing is in fact perfectly correct and valid. If that's the case, I apologize for the noise ;) signature.asc Description: OpenPGP digital signature
Bug#882731: [Pkg-dns-devel] Bug#882731: apparmor policy only accepts root.key in /var/lib/unbound
On 2018-01-30 03:40 PM, Robert Edmonds wrote: > Simon Deziel wrote: >> On 2017-11-27 09:22 AM, Peter Palfrader wrote: >>> On Mon, 27 Nov 2017, Simon Deziel wrote: >>> >>>> On 2017-11-26 03:31 AM, Peter Palfrader wrote: >>>>> The apparmor policy for unbound allows access to >>>>> /var/lib/unbound/root.key*, but it does not allow access to any >>>>> other dynamically updated key the admin might have put there, >>>>> such as debian.org.key on DSA infrastructure. >>>>> >>>>> Please allow access to all key files. >>>> >>>> Please see the attached patch. >>> >>>># chrooted paths >>>>/var/lib/unbound/** r, >>>> + owner /var/lib/unbound/*.key* rw, >>>>owner /var/lib/unbound/**/*.key* rw, >>> >>> This would allow /var/lib/unbound/root.key "twice", once via root.key, >>> once via *.key. >> >> Indeed, this patch should be better, thanks Peter. > > Hi, > > I'm a little bit confused here. The unbound daemon runs as user > 'unbound', thus it should have read-write permission to the directory > /var/lib/unbound/, because that's what the permission on the directory > is. Is the apparmor policy intentionally overriding this? Yes. > There's no requirement that an auto-trust-anchor-file be configured with > a filename that ends in ".key". Does the apparmor policy break unbound > if a sysadmin doesn't follow this convention? Yes. Preventing writes in /etc/unbound made sense (to me) and it was carried over to /var/lib/unbound. I agree that such restrictions for /var/lib/unbound are not warranted and breaks the principle of least surprise. Feel free to scrap those restrictions, I can provide a patch/updated profile if that's easier [*]. I think there is still some value in keeping the "audit deny" rules to alert an admin if something fishy is done on the cert/key used by the control channel. Regards, Simon *: I could also bundle the tiny fix for bug 867186 in it signature.asc Description: OpenPGP digital signature
Bug#863841: Enable systemd hardening options for named
Hi, In addition to what Russ proposed to add, I've been running with those additional restrictions: SystemCallArchitectures=native # note: AF_NETLINK is needed for getifaddrs(3) RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK They are available on older systemd versions so they shouldn't cause problems with backports. I tested with systemd 229 (Xenial). Regards, Simon P.S: flags=(attach_disconnected) is still needed for Apparmor. signature.asc Description: OpenPGP digital signature
Bug#888169: [Pkg-dns-devel] Bug#888169: seccomp support for bind9
Alright, makes sense, thanks for the quick update. signature.asc Description: OpenPGP digital signature
