On Wed, May 04, 2011 at 03:06:27PM +0200, Florian Haas wrote:
> Coming back to this one, as the discussion seems to have died down.
> 
> On 2011-04-20 19:00, Lars Ellenberg wrote:
> > Oh, well, thinking about non-roots that may have cibadmin karma,
> > they now can configure a resource that will remove /etc/passwd.
> > I'm not sure if I like that.
> > 
> > How about a staged system? Double symlinks?
> > Similar to the alternatives system in Debian or others.
> > 
> > The RA will force a single directory that will contain the indirection
> > symlinks, and will sanitize (or force) link names to not contain slashes.
> > 
> > The real symlinks will point to that indirection symlink, which will
> > point to the end location.
> > 
> > /etc/postfix/main.cf
> >    -> /var/lib/wherever-indirection-dir/postfix_main.cf <<<===
> >       -> /mnt/somewhere/you/want/to/point/to/main.cf
> > 
> > And <<<=== will be managed by the resource agent.
> 
> Considering we have an "anything" resource agent which, well, lets us do
> anything, I consider this pointless cluttering of the resource agent
> which creates a false sense of security. Thoughts?

Trying to think out loud...
There are a few aspects.

* if we don't have ACLs, anyone with write access to the CIB
  is de facto root on the cluster nodes.  Which makes privilege
  escalation bugs non-existent by definition ;-)

* potential privilege escalation

  Well, to make this an issue, we would need to establish that
   * the cib ACL system is in place,
   * and used,
   * and "properly" configured,
  which would probably also mean that access would be limited to only
  certain resource agent types.

  Most likely the ACL will be short as well: one role that can do
  "cleanup" and otherwise only view things,
  one role that can do everything (equivalent to root).

  Services running under Pacemaker control are probably "critical",
  so a malicious person with even only "stop" access on the CIB
  can do a DoS. I guess we have to assume people with any write access
  at all to the CIB are "trusted", and not malicious.

  Adding more "insecure" RAs would just keep the white list shorter.
  No problem with me.

  White list would probably be really short anyways.

  Still we may want to try and limit the potential damage
  that can be done by roles that have only limited rights
  (start/stop/reconfigure existing).

  /me not sure about all this ACL stuff anyways,
  I'd try to avoid it where ever possible ;-)

* limit potential damage on "accidental carelessness"

  Well, yes, I think that is something we could aim for, too.

And a some more thoughts, but I would probably need a few beers to make
them appear coherent even to myself ;-)

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to