On Tue, Apr 28, 2020 at 09:43:31AM +0100, Andrew C Aitchison wrote:
> On Tue, 28 Apr 2020, Russell King via Exim-users wrote:
>
> >On Mon, Apr 27, 2020 at 09:11:18PM +0100, Jeremy Harris via Exim-users wrote:
> >>On 27/04/2020 20:52, Russell King via Exim-users wrote:
> >>>I'm running debian stable on my machines, and I've noticed that when
> >>>one of my scripts sends email,
> >>
> >>I'm hoping that means you can trigger it on demsnd?
> >
> >I believe so - exim is being called from a perl script running as the
> >user stated in the log line thusly:
> >
> > /usr/sbin/sendmail -oi -t
> >
> >>>I get a spurious and unexplained
> >>>"Permission denied" error:
>
> Does changing that to
> /usr/sbin/sendmail -oi -t -v
> give you any clues ?
>
> "exim -v" doesnt give as much information as "exim -d" but should
> be available as any user.
Good suggestion, but alas no:
LOG: MAIN
<= patchd@??? U=patchd P=local S=377
patchd@xxxx:~/test$ delivering 1jTMBH-0005BJ-F0
Connecting to pandora.armlinux.org.uk [xxxx:xxxx:xxxx:xxxx:214:fdff:fe10:1be6]:25 ... failed: Permission denied
LOG: MAIN
H=pandora.armlinux.org.uk [xxxx:xxxx:xxxx:xxxx:214:fdff:fe10:1be6] Permission
denied
Connecting to pandora.armlinux.org.uk [yyyy:yyyy:yyyy:yyyy:214:fdff:fe10:1be6]:25 ... connected
Interestingly, the IPv6 prefix is different on the actual delivery this
time around from the line with the error (I have several IPv6 prefixes
internally, a 2001: and a private prefix.)
> >The protection on setuid processes means that while you can do this:
> >
> > strace /usr/sbin/sendmail -oi -t
> >
> >as an unprivileged user, the process will no longer be executed setuid,
> >and it definitely will not be able to access a bunch of files (such as
> >those giving it the credentials for the smarthost.)
>
> The output of
> strace -f -eopen,openat -o /tmp/exim.strace /usr/sbin/sendmail -oi -t
> should be small and include the name of the file that cannot be read
> (unless there is another unreadable file that stops exim reaching the
> problem access).
That gives me:
2020-04-28 10:01:51 1jTM7j-0005A1-Na Failed to create spool file /var/spool/exim4//input//1jTM7j-0005A1-Na-D: Permission denied
2020-04-28 10:01:51 1jTM7j-0005A1-Na Failed to create spool file /var/spool/exim4//input//1jTM7j-0005A1-Na-D: Permission denied
2020-04-28 10:01:51 1jTM7j-0005A1-Na Failed to create spool file /var/spool/exim4//input//1jTM7j-0005A1-Na-D: Permission denied
and grepping the strace output for errors:
19841 openat(AT_FDCWD, "/var/spool/exim4//input//1jTM7j-0005A1-Na-D", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0640) = -1 EACCES (Permission denied)
19841 openat(AT_FDCWD, "/var/log/exim4/mainlog", O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = -1 EACCES (Permission denied)
19841 openat(AT_FDCWD, "/var/log/exim4/paniclog", O_WRONLY|O_APPEND|O_LARGEFILE|O_CLOEXEC) = -1 EACCES (Permission denied)
So we're not getting anywhere near delivery (which is where the permission
denied error is happening). This is entirely obvious (at least to me with
25+ years experience of Linux kernel, having ported it to the ARM
architecture back in the 1990s) because running strace _prevents_ the OS
from honouring the setuid bit on exim.
I think the *only* way to find this is to build a custom version of exim
with the internal security checking for the -d option removed, or to audit
the source code.
--
Russell King
