On Tue, Nov 12, 2019 at 9:12 AM Sage Weil <sweil@xxxxxxxxxx> wrote: > I have a feeling distros/products will have a packaged ceph-daemon > available for bootstrapping, and perhaps 'ceph-daemon shell'. > > But IMO using a packaged version for mgr/ssh is a fragile/broken approach > because the ceph cluster will be upgrading itself, and part of that > upgrade will invitably involve updated versions of ceph-daemon. And we > don't want ceph to have to learn about package managers. > > Again, the only reason we'd write ceph-daemon to disk on the remote node > *at all* is so that we can sudo run it. > > ... > > The problem with this, now that I think about it, is that $cephuser can > sudo /home/$cephuser/ceph-daemon and also rewrite it, which makes it > useless as a security barrier. I think ceph-daemon has to be root-owned > and in a root-owned directory (/root/ceph-daemon?) in order for sudo to be > potentially useful here. > > But then in order for the script to be updateable, mgr/ssh sshing in as > $cephuser needs to be able to update it. Which means that if someone has > that ssh key they can always update ceph-daemon to run /bin/bash (or > whatever) and circumvent any protection. So I think ability to have > mgr/ssh keep ceph-daemon in sync with itself is fundamentally incompatible > with providing any meaningful protection. > > Sigh... This is just a specific instance of a generalized problem, right? If the Ceph cluster has the ability to update itself, then anybody who pwns it can update to arbitrary code and do whatever they want. The best we can do is narrow attack surfaces so that an attacker needs to get more than a trivial level of access. So it seems to me like the right way to handle this is by putting in break points where the cluster admin can trade off convenience for security as they see fit, but given your statements I guess we default to convenience. One way might be to 1) always create both a ceph and ceph-admin user account on the remote nodes when provisioning them, using an ssh key with root access. But let the cluster admin do this step for us if they don't want to hand out that root-accessible key. 2) grant all the managers easy access to the ceph account, but don't give it write access to ceph-daemon.sh 3) use the ceph-admin user account solely to update ceph-daemon.sh, and grant access in circumstances as limited as possible. We can probably make it possible to require cluster admin intervention before the ceph-admin key is unlocked, eg by requiring a passphrase that Ceph doesn't store? _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
