rsync as root (Was: [CentOS-mirror] New Mirror)

Le mercredi 30 juillet 2008, mirror-maintainer at mirror.averse.net a écrit :
> On Tue, 29 Jul 2008, Olivier Thauvin wrote:
> >>> Your rsync user - don't run rsync as root!  And don't run it as your
> >>> web/ftp service account either.
> >>
> >> I can understand not running rsync in daemon mode as root but what is
> >> the problem with running the rsync client as root?
> >
> > There is many reasons:
>
> [snip]
>
> Thanks Olivier.  Although this question wasn't asked, I'd add a reason not 
> to run as the web/ftp service account, which is to ensure that the web/ftp
> service is unable to access the content if it isn't world readable; eg
> when content is made available to mirrors before public announcements, and
> a permission bitflip is used to make the content available on the release
> date.
>
> Ironically, I do run rsync --daemon as root for a few reasons:
> - use chroot=true

chroot does not prevent from privilege gain, it just limit access to the 
filesystem. IIRC, rsync has suffer in past of bug allowing write access 
regardless chroot settings. Real exploit rarelly occurs though.

> - listen on port 873

rsync does not have any code to listen on a socket. The only way it has to 
communicate is using pipe with STDIN/STDOUT. Network connection are done 
either by ssh/rsh, either by (x)inetd.
This make as a possible setup starting rsync as normal user, xinetd listening 
as root on port 873
But rsync need root privileges to perform chroot(), or to perfrom setuid() in 
case you need to run rsync as different user according share configuration 
for some reasons.

> - specify per-module uid, gid
>
> Admittedly, I could manually chroot the daemon to the entire mirror
> tree before running it as a regular user, and I could do some port
> forwarding or iptables stuff and run rsyncd on a high port, and use a
> common nobody-like account for all modules...

Yes it is possible, of course, but useless, honestly. As all serious server 
rsync do the best to run a very short time as root. And first things done are 
chroot && setuid.

Moreover, rsync probably need some /dev entry (null, zero, maybe random), 
you'll have to copy few lib. Well at the end this make the computer hardest 
to hack, but probably not impossible, remember the kernel is same, kernel can 
have exploit too.

finally it can be safer to let rsync loading all libs in memory and performing 
itself the chroot over data only tree.

>
> What do you guys do?

I have xinetd, starting rsync as root (for chroot(), not a big deal, rsync 
switch to normal user as soon root personnality is not need anymore), and in 
my rsyncd.conf I have:

read only = yes
uid = nobody
gid = nogroup
use chroot = yes

As default setting.

Some of my exported module need others user/group permissions (incoming 
share), these specific modules have an uid/gid explicitely configured.

ps clearly show rsync perform a setuid to become a simple user:
14170 nobody    25   5 23468 3560 1080 D   10  0.0   1:13.25 rsync

ftp run as 'nobody' user, web server as 'apache' server.

All mirrors are done by a 'distrib' user. So, except upstream setup 777 
permissions on some files (FYI: can be override with rsync when you're doing 
your mirror, see --chmod option), no chance an attackers can write on the 
mirror tree.
In the case a part of the tree is not readable by everyone, I assume it is an 
upstream choice (the reason you explain at the beginning of the mail).

Notice the bitflip can be problematic for tier 2 mirrors, eg mirrors rsyncing 
from tier 1, they will not have access to the hidden tree, and get an error. 
In such case, rsync refuse to delete old files. Such situation should shorter 
as possible, otherwise tier 2 can see their tree growing (usually the tree of 
a distro stop to move during the release step, developers prefer to sleep 
after the hard work ;)

The mirror I am talking about is http://mirror.ipsl.fr/, often know as 
distrib-coffee.ipsl.jussieu.fr (but the first name is really shorter :)

Best regards.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.centos.org/pipermail/centos-mirror/attachments/20080730/999d5380/attachment.sig>