Re: [exim-dev] Candidate patches for privilege escalation

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: David Woodhouse
Ημερομηνία:  
Προς: Phil Pennock
Υ/ο: exim-dev
Αντικείμενο: Re: [exim-dev] Candidate patches for privilege escalation
On Sun, 2010-12-12 at 05:28 -0500, Phil Pennock wrote:
> > - Don't use config files as root if they're writeable by non-root
> > users/groups. Including the Exim user/group.
>
> This appears to be a mis-leading statement. Really, you're removing the
> Exim user/group from being permitted owners by default. But if instead
> we look at what you wrote as the goal, then this is awkward.


What I wrote is definitely the goal. If a config file can be written by
a non-root user, then that user can trivially gain root privs. That's
the lesson we learned this week.

Fixing that issue may be inconvenient, certainly. We need to find ways
to *cope* with that inconvenience.

> If I'm editing config files I'm doing so in a non-root svn checkout, so
> that I avoid editing things as root with no audit trail. I will then,
> as root, run some tests based upon those checkouts. That's now broken;
> okay, it's "just" an extra cp, but it adds hoops to jump through.
>
> OTOH, that shouldn't work right now, since I don't set CONFIGURE_OWNER.
> But it clearly does.


Yeah, we don't do the permission checks right now if the config file was
specified with -C. I figured we should fix that too, so we do the check
on *all* configs which are going to be executed as root.

It's not *you* who has to jump through the extra hoop to use your config
file with root privs. It's *root* who has to jump through the extra
hoop. And that's kind of the point.

> Aren't there environments which distribute config files and data as a
> non-privileged user, distinct from the user used for serving? None come
> to mind right now, but I can well believe that one of the admin UI panel
> interfaces for basic sysadmin will be creating the files as non-root.


They can add that user to CONFIGURE_USER/CONFIGURE_GROUP then.

Hell, if you really want, you can add the Exim user that way. But don't
come crying to me if the Exim user on your system can trivially obtain
root privs in an attack :)

The only functionality you're really losing with this patch is the
ability to have the Exim user/group *and* another user/group be
permitted to own these config files. You can add Exim back, but you
can't then add another.

--
dwmw2