$queue_directory/private permissions

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

$queue_directory/private permissions

Simon Deziel-2
Hello,

I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I
noticed the tlsproxy process is apparently trying to connect to tlsmgr's
Unix socket while still running as root.

Since tlsmgr's socket is stored under $queue_directory/private that has
perms set to 0700 and owned by postfix:root, the tlsproxy process needs
to override the DAC checks using the CAP_DAC_READ_SEARCH capability.

I can think of 2 ways to workaround this. One is to tell Apparmor to
grant the tlsproxy process the needed capability and the other is to
have the $queue_directory/private directory perms set to 0710 with the
same owner/group.

Tuning the private directory perms removes the need for the capability
so that's my current workaround [*] but I'm looking for feedback on the
possible ramifications of this diversion from the default perms.

Regards,
Simon


*: I created postfix-files.d/private-group-search.files with
   "$queue_directory/private:d:$mail_owner:-:710:uc"

P.S: while testing further, I also noticed that smtpd processes need the
same cap to access proxymap's Unix socket also under
queue_directory/private.
Reply | Threaded
Open this post in threaded view
|

Re: $queue_directory/private permissions

Wietse Venema
Simon Deziel:
> I can think of 2 ways to workaround this. One is to tell Apparmor to
> grant the tlsproxy process the needed capability and the other is to
> have the $queue_directory/private directory perms set to 0710 with the
> same owner/group.

Sorry, changes to Postfix permissions are not supported.

You are welcome to configure AppArmor etc. so that they will not
break legitimate operation of Postfix, but such configuration is
considered platform-specific, and outside the scope of Postfix.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: $queue_directory/private permissions

Viktor Dukhovni
In reply to this post by Simon Deziel-2
> On Mar 24, 2019, at 4:33 PM, Simon Deziel <[hidden email]> wrote:
>
> I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I
> noticed the tlsproxy process is apparently trying to connect to tlsmgr's
> Unix socket while still running as root.

The premise is false.  On all the systems I've used, the "private" directory
belongs to the "$mail_owner" user:

  $ ls -ld /var/spool/postfix/private/
  drwx------  2 postfix  wheel  24 Mar  3 02:49 /var/spool/postfix/private/

and connections to peer services (e.g. to tlsmgr(8)) often happen after privs
are dropped.  Some requests may happen before that, but the directory must be
generally readable by $mail_owner.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: $queue_directory/private permissions

Simon Deziel-2
On 2019-03-24 6:02 p.m., Viktor Dukhovni wrote:

>> On Mar 24, 2019, at 4:33 PM, Simon Deziel <[hidden email]> wrote:
>>
>> I am running postfix (3.3.0-1ubuntu0.2) confined by Apparmor and I
>> noticed the tlsproxy process is apparently trying to connect to tlsmgr's
>> Unix socket while still running as root.
>
> The premise is false.  On all the systems I've used, the "private" directory
> belongs to the "$mail_owner" user:
>
>   $ ls -ld /var/spool/postfix/private/
>   drwx------  2 postfix  wheel  24 Mar  3 02:49 /var/spool/postfix/private/

Sorry, I should have included that as it look the same here:

 $ ls -ld /var/spool/postfix/private/
 drwx------ 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/

> and connections to peer services (e.g. to tlsmgr(8)) often happen after privs
> are dropped.

Agreed, but I'm not concerned about the after.

> Some requests may happen before that, but the directory must be
> generally readable by $mail_owner.

I was not clear because my issue is indeed with those accesses before
privs get dropped. I noticed that tlsproxy accesses tlsmgr's socket
while still running as root so it depends on its CAP_DAC_READ_SEARCH
capability. My workaround to not need that cap was to change the perms
to be like:

 $ ls -ld /var/spool/postfix/private/
 drwx--x--- 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/

And with that group search bit on, the tlsproxy process no longer
depends on the CAP_DAC_READ_SEARCH cap to get to tlsmgr's socket.

In other words, this group search bit allows to _not_ depend on the
CAP_DAC_READ_SEARCH which sounded like an improvement to me. That's what
I wanted to validate with the mailing list.

Thanks,
Simon
Reply | Threaded
Open this post in threaded view
|

Re: $queue_directory/private permissions

Simon Deziel-2
In reply to this post by Wietse Venema
On 2019-03-24 5:46 p.m., Wietse Venema wrote:

> Simon Deziel:
>> I can think of 2 ways to workaround this. One is to tell Apparmor to
>> grant the tlsproxy process the needed capability and the other is to
>> have the $queue_directory/private directory perms set to 0710 with the
>> same owner/group.
>
> Sorry, changes to Postfix permissions are not supported.
>
> You are welcome to configure AppArmor etc. so that they will not
> break legitimate operation of Postfix, but such configuration is
> considered platform-specific, and outside the scope of Postfix.

Apparmor is what highlighted the reliance on capabilities that seemed
avoidable with a group search bit on the private dir so I wanted to hear
the opinion of experts. I'm well aware that adding Apparmor or diverging
from the default perms means I'm on my own, sorry if that was off-topic
for postfix-users@.

Regards,
Simon
Reply | Threaded
Open this post in threaded view
|

Re: $queue_directory/private permissions

Viktor Dukhovni
In reply to this post by Simon Deziel-2


> On Mar 24, 2019, at 8:17 PM, Simon Deziel <[hidden email]> wrote:
>
> I was not clear because my issue is indeed with those accesses before
> privs get dropped. I noticed that tlsproxy accesses tlsmgr's socket
> while still running as root so it depends on its CAP_DAC_READ_SEARCH
> capability. My workaround to not need that cap was to change the perms
> to be like:
>
> $ ls -ld /var/spool/postfix/private/
> drwx--x--- 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/
>
> And with that group search bit on, the tlsproxy process no longer
> depends on the CAP_DAC_READ_SEARCH cap to get to tlsmgr's socket.
>
> In other words, this group search bit allows to _not_ depend on the
> CAP_DAC_READ_SEARCH which sounded like an improvement to me. That's what
> I wanted to validate with the mailing list.

Sorry, that breaks the Postfix internal access control model in unsupported
ways.  Root needs to be able to read the directory with its standard
permissions.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: $queue_directory/private permissions

Bastian Blank-3
On Mon, Mar 25, 2019 at 01:32:28AM -0400, Viktor Dukhovni wrote:
> Sorry, that breaks the Postfix internal access control model in unsupported
> ways.  Root needs to be able to read the directory with its standard
> permissions.

How exactly does "root" get permissions to read the directory?  It's DAC
permissions (0700 with owner postfix) do not provide it.

Bastian

--
Beam me up, Scotty, there's no intelligent life down here!
Reply | Threaded
Open this post in threaded view
|

Re: $queue_directory/private permissions

Wietse Venema
Bastian Blank:
> On Mon, Mar 25, 2019 at 01:32:28AM -0400, Viktor Dukhovni wrote:
> > Sorry, that breaks the Postfix internal access control model in unsupported
> > ways.  Root needs to be able to read the directory with its standard
> > permissions.
>
> How exactly does "root" get permissions to read the directory?  It's DAC
> permissions (0700 with owner postfix) do not provide it.

Root always has permission in the UNIX file permission model.
However this is off-topic for a Postfix mailing list.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: $queue_directory/private permissions

Simon Deziel-2
In reply to this post by Viktor Dukhovni
On 2019-03-25 1:32 a.m., Viktor Dukhovni wrote:

>> On Mar 24, 2019, at 8:17 PM, Simon Deziel <[hidden email]> wrote:
>>
>> I was not clear because my issue is indeed with those accesses before
>> privs get dropped. I noticed that tlsproxy accesses tlsmgr's socket
>> while still running as root so it depends on its CAP_DAC_READ_SEARCH
>> capability. My workaround to not need that cap was to change the perms
>> to be like:
>>
>> $ ls -ld /var/spool/postfix/private/
>> drwx--x--- 2 postfix root 4096 Mar 24 16:54 /var/spool/postfix/private/
>>
>> And with that group search bit on, the tlsproxy process no longer
>> depends on the CAP_DAC_READ_SEARCH cap to get to tlsmgr's socket.
>>
>> In other words, this group search bit allows to _not_ depend on the
>> CAP_DAC_READ_SEARCH which sounded like an improvement to me. That's what
>> I wanted to validate with the mailing list.
>
> Sorry, that breaks the Postfix internal access control model in unsupported
> ways.  Root needs to be able to read the directory with its standard
> permissions.

OK, thank you.

Regards,
Simon