Silktree
Silktree updates the /etc/passwd and /etc/group files on a list of child nodes via SSH. At the lowest level, six Debian system utilities are employed: {add,del}{user,group}, {user,group}mod. The information is transferred from the head-node to the child-nodes. Several sudo-capable mini-scripts on the child nodes ensure limitations while committing the changes. End-to-end checking ensures a reliable update.
| Tags | Networking LDAP Security |
|---|---|
| Licenses | GPLv3 |
| Operating Systems | Debian |
| Implementation | Ruby |
Recent releases
- 06 Feb 2009 22:13
Changes: Almost everything was refactored. The propogation script is much more robust now: it does updates with usermod and groupmod, recognizes changes in the group member list, and makes fine-grained updates.
- 06 May 2008 04:03
No changes have been submitted for this release.
- All comments
Recent commentsRe: Is Silk Tree secure?
> The answer is no.
>
> Silk Tree is an attempt to isolate the
> receiver side from the sending side
> (master host), so that if the sending
> side is compromised then the other side
> stays unaffected.
>
> This goal is not archived because if the
> adversary is able to ssh into the
> receiving side as the silktree user then
> the adversary is able to push anything
> into the /etc/passwd and /etc/group of
> the receiver.
>
> The sending side is isolated from the
> receiving side because of the one-way
> design of SSH and I am careful not to
> start executing any data that is
> gathered from the receiving side.
>
> Having this said, I would still prefer
> Silk Tree over the SSHing-as-root
> method.
This has been fixed in the 0.2 release.
Is Silk Tree secure?
The answer is no.
Silk Tree is an attempt to isolate the receiver side from the sending side (master host), so that if the sending side is compromised then the other side stays unaffected.
This goal is not archived because if the adversary is able to ssh into the receiving side as the silktree user then the adversary is able to push anything into the /etc/passwd and /etc/group of the receiver.
The sending side is isolated from the receiving side because of the one-way design of SSH and I am careful not to start executing any data that is gathered from the receiving side.
Having this said, I would still prefer Silk Tree over the SSHing-as-root method.