Spool directories on ext4 with encryption

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Spool directories on ext4 with encryption

Christian Rößner
Hi,

today I tried to use ext4 encryption for /var/spool/postfix*

1. Create static salt with:
head -c 16 /dev/urandom | xxd -p >~/tmp-salt.txt
echo 0x`cat ~/tmp-salt.txt` >~/.cryptoSalt

2. Adding key:
/usr/sbin/e4crypt add_key -S f:/root/.cryptoSalt

3. Stopping postfix
4. Create /var/spool/old
5. mv /var/spool/postfix* /var/spool/old/
6. mkdir -p /var/spool/postfix /var/spool/postfix-relay /var/spool/postfix-submission

7. Set policies:
e4crypt set_policy XXXXX /var/spool/postfix
e4crypt set_policy XXXXX /var/spool/postfix-relay
e4crypt set_policy XXXXX /var/spool/postfix-submission

8. Copy back stuff:
cp -a /var/spool/old/postfix/* /var/spool/postfix/
cp -a /var/spool/old/postfix-relay/* /var/spool/postfix-relay/
cp -a /var/spool/old/postfix-submission/* /var/spool/postfix-submission

9. Starting postfix

Result:

Aug 20 15:02:34 mx postfix/submission/cleanup[28091]: warning: mail_queue_enter: create file incoming/648259.28091: Required
key not available
Aug 20 15:02:35 mx postfix/submission/cleanup[28035]: warning: mail_queue_enter: create file incoming/167770.28035: Required
key not available
Aug 20 15:02:35 mx postfix/submission/cleanup[27787]: warning: mail_queue_enter: create file incoming/765542.27787: Required
key not available
Aug 20 15:02:44 mx postfix/submission/cleanup[28091]: warning: mail_queue_enter: create file incoming/648610.28091: Required
key not available
Aug 20 15:02:45 mx postfix/submission/cleanup[28035]: warning: mail_queue_enter: create file incoming/168137.28035: Required
key not available
Aug 20 15:02:45 mx postfix/submission/cleanup[27787]: warning: mail_queue_enter: create file incoming/765920.27787: Required
key not available

Moving back to unencrypted, everything works again. Any ideas, what I can do? Am I missing something?

postconf mail_version
mail_version = 3.3.1

Kind regards

Christian
--
Rößner-Network-Solutions
Karl-Bröger-Str. 10, 36304 Alsfeld
T: +49 6631 9110725, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://roessner-network-solutions.com


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spool directories on ext4 with encryption

Wietse Venema
Christian Ro??ner:
> Aug 20 15:02:34 mx postfix/submission/cleanup[28091]: warning: mail_queue_enter: create file incoming/648259.28091: Required
> key not available

Can you check if the cleanup daemon runs chrooted?

$ postconf -F cleanup/unix/chroot

If the output says 'yes' then you may want to try:

# postconf -F cleanup/unix/chroot=no
# postfix reload

(ditto for other Postfix daemons).

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Spool directories on ext4 with encryption

Christian Rößner


> Am 20.08.2018 um 16:17 schrieb Wietse Venema <[hidden email]>:
>
> Christian Ro??ner:
>> Aug 20 15:02:34 mx postfix/submission/cleanup[28091]: warning: mail_queue_enter: create file incoming/648259.28091: Required
>> key not available
>
> Can you check if the cleanup daemon runs chrooted?
>
> $ postconf -F cleanup/unix/chroot

rns root@mx  ~ # postconf -F cleanup/unix/chroot
cleanup/unix/chroot = n
rns root@mx  ~ # postconf -c /etc/postfix-relay -F cleanup/unix/chroot
cleanup/unix/chroot = n
rns root@mx  ~ # postconf -c /etc/postfix-submission -F cleanup/unix/chroot
cleanup/unix/chroot = n

Was already non-chrooted.

What key is the log message talking about?

Christian
--
Rößner-Network-Solutions
Karl-Bröger-Str. 10, 36304 Alsfeld
T: +49 6631 9110725, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://roessner-network-solutions.com


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spool directories on ext4 with encryption

Wietse Venema
Christian Ro??ner:
> What key is the log message talking about?

Postfix asks the kernel to create a queue file, and the kernel
returns the ENOKEY error code. Postfix is not responsible for
eCryptfs key management.

Maybe there is a problem with the startup order, where Postfix
starts before eCryptfs? Easy enough to check by stopping and staring
Postfix by hand after the system is up.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Spool directories on ext4 with encryption

Christian Rößner


> Am 20.08.2018 um 18:10 schrieb Wietse Venema <[hidden email]>:
>
> Christian Ro??ner:
>> What key is the log message talking about?
>
> Postfix asks the kernel to create a queue file, and the kernel
> returns the ENOKEY error code. Postfix is not responsible for
> eCryptfs key management.

It is ext4 encrypted directory with e4crypt. Anyways:

If I have copied over all files and directories from .../old/postfix* as explained step by step, then why does that work and if Postfix wants to create a file, it fails?

It is not chroot.

> Maybe there is a problem with the startup order, where Postfix
> starts before eCryptfs? Easy enough to check by stopping and staring
> Postfix by hand after the system is up.

My plan is to not put Postfix (and Dovecot) into the runlevels. So system boots and I enter the passphrase. After that I want to start the services.

Could it be some ext4 feature that Postfix misses? I had to add encrypt with tune2fs to the partition:

tune2fs -O encrypt /dev/vg01/lv_var

I have tested the encryption stuff with a test-folder under /var/spool/test. The same way, as described for the Postfix-spool directories. I can create files under this test folder and edit them. So in principal all is working. Only Postfix seems to have trouble. So the reason for asking here on the list. I also could not find anything related with Google.

Is there nobody, who could reproduce this?

Christian
--
Rößner-Network-Solutions
Karl-Bröger-Str. 10, 36304 Alsfeld
T: +49 6631 9110725, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://roessner-network-solutions.com


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spool directories on ext4 with encryption

Viktor Dukhovni
See http://man7.org/linux/man-pages/man8/e4crypt.8.html

Access to content is session based, with keys in the session keyring.
This access control model may not be compatible with Postfix running
multiple services under various user ids.  If you want to use such
filesystems, you have to figure out how to make it work.

> On Aug 20, 2018, at 1:21 PM, Christian Rößner <[hidden email]> wrote:
>
> It is ext4 encrypted directory with e4crypt. Anyways:
>
> If I have copied over all files and directories from .../old/postfix* as explained step by step, then why does that work and if Postfix wants to create a file, it fails?
>
> It is not chroot.
>
>> Maybe there is a problem with the startup order, where Postfix
>> starts before eCryptfs? Easy enough to check by stopping and staring
>> Postfix by hand after the system is up.
>
> My plan is to not put Postfix (and Dovecot) into the runlevels. So system boots and I enter the passphrase. After that I want to start the services.
>
> Could it be some ext4 feature that Postfix misses? I had to add encrypt with tune2fs to the partition:
>
> tune2fs -O encrypt /dev/vg01/lv_var
>
> I have tested the encryption stuff with a test-folder under /var/spool/test. The same way, as described for the Postfix-spool directories. I can create files under this test folder and edit them. So in principal all is working. Only Postfix seems to have trouble. So the reason for asking here on the list. I also could not find anything related with Google.
>
> Is there nobody, who could reproduce this?

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Spool directories on ext4 with encryption

Christian Rößner

> Am 20.08.2018 um 20:59 schrieb Viktor Dukhovni <[hidden email]>:
>
> See http://man7.org/linux/man-pages/man8/e4crypt.8.html
>
> Access to content is session based, with keys in the session keyring.
> This access control model may not be compatible with Postfix running
> multiple services under various user ids.  If you want to use such
> filesystems, you have to figure out how to make it work.

Thank you very much. I missed this. I will think about how to solve this.

Christian
--
Rößner-Network-Solutions
Karl-Bröger-Str. 10, 36304 Alsfeld
T: +49 6631 9110725, F: +49 6631 78823409, M: +49 171 9905345
USt-IdNr.: DE225643613, https://roessner-network-solutions.com


smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Spool directories on ext4 with encryption

Postfix Mail System

Last night, it would appear that zen.spamhaus.org started blacklisting a
number of IPs assigned to Spectrum consumers, of which I am one.

When I tried telnetting to port 25 of my mail server and manually sending
a message to one of our virtual mailboxes, I got this error:

554 5.7.1 Service unavailable; Client host [<my-ip-address>] blocked using zen.spamhaus.org


I tried putting a bunch of /8's that I know to be assigned to Spectrum,
one of which my own IP was definitely within, into rbl_override. I then
ran postmap rbl_override and restarted postfix.

No dice. Still got the error.

For the time being, I had to go into main.cf and comment out reference to
zen.spamhaus.org completely for now, but I would still prefer a more
granular solution.

BTW the smtpd_client_restrictions contains:

check_client_access hash:/usr/local/etc/postfix/rbl_override


This precedes all the reject references to specific blacklists.

I believe rbl_override has worked in the past. Any ideas why it's not
working in this case? This is what my Spectrum IP section looks like:

# Spectrum
23.0.0.0/8 OK
24.0.0.0/8 OK
50.0.0.0/8 OK
63.0.0.0/8 OK
64.0.0.0/8 OK
65.0.0.0/8 OK
66.0.0.0/8 OK
67.0.0.0/8 OK
68.0.0.0/8 OK
69.0.0.0/8 OK
70.0.0.0/8 OK
71.0.0.0/8 OK
72.0.0.0/8 OK
73.0.0.0/8 OK
74.0.0.0/8 OK
75.0.0.0/8 OK
76.0.0.0/8 OK
96.0.0.0/8 OK
97.0.0.0/8 OK
98.0.0.0/8 OK
99.0.0.0/8 OK
100.0.0.0/8 OK
104.0.0.0/8 OK
107.0.0.0/8 OK
108.0.0.0/8 OK
173.0.0.0/8 OK
174.0.0.0/8 OK
184.0.0.0/8 OK
199.0.0.0/8 OK
204.0.0.0/8 OK
205.0.0.0/8 OK
206.0.0.0/8 OK
207.0.0.0/8 OK
208.0.0.0/8 OK
209.0.0.0/8 OK
216.0.0.0/8 OK



TIA!