pcp
[Top] [All Lists]

pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sock

To: pcp@xxxxxxxxxxx
Subject: pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Thu, 20 Feb 2014 15:18:34 -0500
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <530612EC.8020206@xxxxxxxxxx> (Dave Brolley's message of "Thu, 20 Feb 2014 09:36:28 -0500")
References: <52FE5058.4030702@xxxxxxxxxx> <53023D4E.1060504@xxxxxxxxxx> <y0mmwhoqu69.fsf@xxxxxxxx> <757832688.10280462.1392753861578.JavaMail.zimbra@xxxxxxxxxx> <896174788.10421447.1392770006295.JavaMail.zimbra@xxxxxxxxxx> <5304D039.9010708@xxxxxxxxxx> <1347098955.12246278.1392874951684.JavaMail.zimbra@xxxxxxxxxx> <530612EC.8020206@xxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
Hi -


Dave and I got talking about why we're doing AF_UNIX comms for
pmlc<->pmlogger at all: it's primarily for securing pmlogger against
hostile users.  The current patchset doesn't address that aspect, so
let's discuss some possibilities while our mental caches are fresh.

To secure pmlogger across AF_UNIX, it's not enough to put the sockets
into variously owned owned directories.  /var/lib/pcp/tmp is currently
world-readable, and the socket's own permissions may or may not be
factored by the kernel, so potentially any local joe can attach.
That's no better than tcp/localhost.

With AF_UNIX, we get the connecting client's uid/gid/pid for free,
which we pass along for PMAPI authentication purposes within PMCD.  I
propose pmlogger also use that information to extend the pmlogger ACL
language to assert simple predicates like

         allow unix-uidmatch : all;
         # allow unix-gidmatch : all; # probably not a good default
         allow unix : enquire;

which we could then put into the default / pmlogconf-generated files.


As an aside, the pmlogger acl system has a nice separation of
"enquire" vs "all" operations.  However, some mutative operations are
in the enquire category, but probably shouldn't be: namely "new
volume" and "flush".  Both these could be misused for denial-of-service,
so should be restricted.


- FChE

<Prev in Thread] Current Thread [Next in Thread>