Re: [Linux-ha-dev] New OCF RA: symlink
On 2011-05-04 15:19, Florian Haas wrote: On 2011-04-20 14:37, Florian Haas wrote: Dominik doesn't have a github repo yet, so I added this to a separate branch in mine. The current revision is here: https://github.com/fghaas/resource-agents/blob/symlink/heartbeat/symlink Please comment freely. Thanks! I've just responded to two comments from Lars and Alan and I'd appreciate more. As of right now I don't see any show stoppers and I wouldn't like to hold up Dominik's contribution much longer. Unless I hear any valid objections, I intend to merge this new RA next Monday. Thanks! OK. I believe we did stir up some valuable discussion here, but I haven't seen anyone identify a real show stopper. Merged. Thanks Dominik! https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/symlink Cheers, Florian signature.asc Description: OpenPGP digital signature ___ 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/
Re: [Linux-ha-dev] New OCF RA: symlink
On Wed, May 4, 2011 at 4:36 PM, Lars Ellenberg lars.ellenb...@linbit.com wrote: 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. Exactly. If the cluster (or access to it) has been compromised, you're in for so much pain that a symlink RA is the least of your problems. A generic cluster manager is, by design, a way to run arbitrary scripts as root - there's no coming back from there. ___ 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/
Re: [Linux-ha-dev] New OCF RA: symlink
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? Cheers, Florian signature.asc Description: OpenPGP digital signature ___ 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/
Re: [Linux-ha-dev] New OCF RA: symlink
On 2011-04-22 14:25, Alan Robertson wrote: Drbdlinks was never converted to an OCF RA, that I recall. It handles cases of needing to restart the logging system when you changed symlnks around - mainly for chroot services. I've used it for many years. You can find the source for it here: http://www.tummy.com/Community/software/drbdlinks/ It's pretty well thought out, and works quite well. I'd certainly look it over before reinventing the wheel. AFAICS drbdlinks does some things on its own which in a Pacemaker cluster would be under Pacemaker control (restarting daemons, for example). The symlink RA does none of this, it's simple and effective and ties in quite well with Pacemaker management. Cheers, Florian signature.asc Description: OpenPGP digital signature ___ 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/
Re: [Linux-ha-dev] New OCF RA: symlink
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/
Re: [Linux-ha-dev] New OCF RA: symlink
Am I too paranoid? I don't think you are. Some non-root pratically being able to remove any file is certainly a valid concern. Thing is: I needed an RA that configured a cronjob. Florian suggested writing the symlink RA instead, that could manage symlink. Apparently there was an IRC discussion a couple weeks ago that I was not a part of. So while the symlink RA could also do what I needed, I tried to write that instead of the cronjob RA (which will also come since it will cover some more functions than this one, but that's another story). So anyway, maybe those involved in the first discussion can comment on this, too and share thoughts on how to solve things. Maybe they had already addressed these situations. Regards Dominik ___ 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/
Re: [Linux-ha-dev] New OCF RA: symlink
On 2011-04-20 19:00, Lars Ellenberg wrote: On Wed, Apr 20, 2011 at 06:49:48PM +0200, Lars Ellenberg wrote: [a lot] I know I'm paranoid. Am I too paranoid? Patches welcome. Cheers, Florian signature.asc Description: OpenPGP digital signature ___ 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/
Re: [Linux-ha-dev] New OCF RA: symlink
On 2011-04-20 11:41, Dominik Klein wrote: Hi I wrote a new RA that can manage a symlink. Configuration: primitive mylink ocf:heartbeat:symlink \ params link=/tmp/link target=/tmp/target \ op monitor interval=15 timeout=15 This will basically ln -s /tmp/target /tmp/link hth Dominik Dominik doesn't have a github repo yet, so I added this to a separate branch in mine. The current revision is here: https://github.com/fghaas/resource-agents/blob/symlink/heartbeat/symlink Please comment freely. Thanks! Cheers, Florian signature.asc Description: OpenPGP digital signature ___ 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/
Re: [Linux-ha-dev] New OCF RA: symlink
On Wed, Apr 20, 2011 at 02:37:00PM +0200, Florian Haas wrote: On 2011-04-20 11:41, Dominik Klein wrote: Hi I wrote a new RA that can manage a symlink. Configuration: primitive mylink ocf:heartbeat:symlink \ params link=/tmp/link target=/tmp/target \ op monitor interval=15 timeout=15 This will basically ln -s /tmp/target /tmp/link hth Dominik There used to be something called drbdlinks. Never really looked at it, though, so I'm not sure what exactly it does or does not do. In any case I suggest using ln -nvsTf, and add comments as to why. the -n is in case it points to a directory already. try this: mkdir symlink-test cd symlink-test mkdir a mkdir b ln -sv b current # (outch) ln -nsvf b current # (better now) rm current mkdir current ln -nsvf b current # (outch) ln -nsvfT b current # (better now, at least cleanly errors out) Not sure about the portability of all those flags. Not sure about security implications (symlink races in world writeable directories) Maybe you want to at least allow (or even default) to enforce certain permissions (root:root 0755 as a minimum?) on the directory the symlink is located in? Maybe nothing can go wrong anyways? Lars ___ 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/
Re: [Linux-ha-dev] New OCF RA: symlink
On Wed, Apr 20, 2011 at 06:49:48PM +0200, Lars Ellenberg wrote: On Wed, Apr 20, 2011 at 02:37:00PM +0200, Florian Haas wrote: On 2011-04-20 11:41, Dominik Klein wrote: Hi I wrote a new RA that can manage a symlink. Configuration: primitive mylink ocf:heartbeat:symlink \ params link=/tmp/link target=/tmp/target \ op monitor interval=15 timeout=15 This will basically ln -s /tmp/target /tmp/link hth Dominik There used to be something called drbdlinks. Never really looked at it, though, so I'm not sure what exactly it does or does not do. In any case I suggest using ln -nvsTf, and add comments as to why. the -n is in case it points to a directory already. try this: mkdir symlink-test cd symlink-test mkdir a mkdir b ln -sv b current # (outch) ln -nsvf b current # (better now) rm current mkdir current ln -nsvf b current # (outch) ln -nsvfT b current # (better now, at least cleanly errors out) Not sure about the portability of all those flags. Not sure about security implications (symlink races in world writeable directories) Maybe you want to at least allow (or even default) to enforce certain permissions (root:root 0755 as a minimum?) on the directory the symlink is located in? Maybe nothing can go wrong anyways? 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. I know I'm paranoid. Am I too paranoid? Lars ___ 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/
