FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 09-16-2008, 05:29 PM
Matthias Bethke
 
Default Is there a way to automate rsync of updated portage tree across multiple boxes without each having to pull it down from a gentoo mirror

Hi Vaeth,
on Tue, Sep 16, 2008 at 07:14:48PM +0200, you wrote:
> > In addition, the default rsyncd configuration with Gentoo uses a chroot
> > jail.
>
> Also a chroot jail is not a security feature: There are several ways known
> how to break out.

Huh? In the case of NAT it's reasonable to say it's not a security
feature---it's a kludge that happens to increase security somewhat in
the standard case. But there's only one reason I can see why you'd use a
chroot environment *except* for security and that's to have more than
one set of system binaries active at the same time for different
applications. Which is normally a pretty bad kludge in itself (not that
I hadn't done it, to avoid endless library woes on a Debian system that
absolutely must be kept on Woody... :-S), I'd say the vast majority of
chroot jails are there for nothing else but security.

cheers,
Matthias
--
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665
 
Old 09-16-2008, 07:17 PM
Matthias Bethke
 
Default Is there a way to automate rsync of updated portage tree across multiple boxes without each having to pull it down from a gentoo mirror

Hi Vaeth,
on Tue, Sep 16, 2008 at 07:54:43PM +0200, you wrote:
> > I don't even see why you'd strictly need connection tracking to avoid
> > attacks made possible by grossly misconfigured ISP routers. Your router
> > knows that packets with a destination address of 10/8, 192.168/16 and
> > the like have absolutely no business on the public internet so the only
> > sensible behavior would be to just drop them.
>
> This also requires a special kind of router: Namely one which has a
> physical way of distinguishing between the "dangerous" connection to
> the net and your local network (if they are dynamic, this can also
> sometimes be tricked). Of course, combined router/modems have this
> separation practically "by definition".

I can only recall one router where this wasn't the case, my first weird
and wonderful DSL line in the Philippines Normally, why bother
routing if you can just physically connect the thwo networks and have
their traffic intermix?

> However, in any case it requires that the functionality you mention is
> implemented on the router and has no bugs and that the router cannot
> be compromised by other means.

Sure, if your router is compromised you're fuxx0red anyway. I was just
saying that in any halfway sane router these NAT problems are not an
issue. And with many routers running Linux today so you can even get a
shell and check iptables...

cheers,
Matthias
--
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665
 
Old 09-16-2008, 10:51 PM
Matthias Bethke
 
Default Is there a way to automate rsync of updated portage tree across multiple boxes without each having to pull it down from a gentoo mirror

Hi Vaeth,
on Tue, Sep 16, 2008 at 08:36:28PM +0200, you wrote:
> > > Also a chroot jail is not a security feature: There are several
> > > ways known how to break out.
> >
> > [...] But there's only one reason I can see why you'd use a
> > chroot environment *except* for security and that's to have more than
> > one set of system binaries active at the same time for different
> > applications.
>
> Or simply several systems (e.g. amd64 and x86, or gentoo and debian,
> or your boot disk and your newly installed system [the install handbook
> makes massive use of chroot]). This is exactly what chroot was made for.

Sure, that's why I kept it as general als "more than one set", be it a
different architecture/vendor/purpose/whatever.

> > I'd say the vast majority of chroot jails are there for nothing
> > else but security.
>
> Alan Cox: "chroot is not and never has been a security tool", see e.g.
> http://kerneltrap.org/Linux/Abusing_chroot

No disrespect to Mr. Cox but a silly argument stays a silly argument
even if brought forward by Alan. Programs like postfix certainly don't
use chroots for security because they were designed noobs or incompetent
people. Alan acknowledges that "Normal users cannot use chroot()
themselves so they can't use chroot to get back out" but insists on his
point, completely ignoring that doing a chroot() immediately followed by
dropping your root privileges is exactly the recommended way to use it
for security. That's not to say that setting up a vserver for each of
your programs exposed to the net wasn't *more* secure than a chroot if
you want to do it but it's certainly a whole lot more secure if used
properly than not doing it at all.

cheers,
Matthias

--
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665
 
Old 09-18-2008, 10:34 AM
Matthias Bethke
 
Default Is there a way to automate rsync of updated portage tree across multiple boxes without each having to pull it down from a gentoo mirror

Hi Vaeth,
on Wed, Sep 17, 2008 at 09:49:08AM +0200, you wrote:
> > [...] that in any halfway sane router these NAT problems are not an
> > issue. And with many routers running Linux today so you can even get a
> > shell and check iptables...
>
> We are obviously talking about a different price category of routers.
> Most routers people use here in Germany for home systems are from their
> ISP, and they are usually proprietary implementations [...]

Huh? I don't have a good overview of the market here but the ISP I work
at uses only FritzBox routers which run a fine Linux, and as far as I
know so do most of T-Com's Speedport models which should be the most
widely used in Germany. Not that it was significantly cheaper than a
FritzBox or a WRT54...

cheers,
Matthias
--
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665
 
Old 09-18-2008, 11:20 AM
Matthias Bethke
 
Default Is there a way to automate rsync of updated portage tree across multiple boxes without each having to pull it down from a gentoo mirror

Hi Vaeth,
on Wed, Sep 17, 2008 at 10:40:47AM +0200, you wrote:
> > > Alan Cox: "chroot is not and never has been a security tool", see e.g.
> > > http://kerneltrap.org/Linux/Abusing_chroot
> >
> > No disrespect to Mr. Cox but a silly argument stays a silly argument
> > even if brought forward by Alan. Programs like postfix certainly don't
> > use chroots for security because they were designed noobs or incompetent
> > people.
>
> I did not cite the webpage because of the insults but because it shows
> how much the kernel programmers are interested in closing possible ways
> to break out of a chroot
as root
> : not at all, because they think it is ok.
> That's why I said that _only_ with grsecurity a chroot _might perhaps_
> be considered as a serious security measurement (but in fact, people
> which really need chroot to run binaries from two systems cannot activate
> these security enhancements).

Sure, you can't expect that the Debian-loving friend you gave root on
your Debian-chrooted-on-Gentoo system will stay confined to that chroot.
Big deal, just don't do it. That's not what any sane person would
recommend chroot for anyway.

> > Alan acknowledges that "Normal users cannot use chroot()
> > themselves so they can't use chroot to get back out"
>
> Yes, _this_ method of breaking out does not work without additional
> exploits like privilege escalation. (grsecurity closes a lot more methods;
> I did never reasearch which tricks might perhaps work as a user).
> But if everything works as it should, just running with low privileges
> does not make much of a difference than running with low privileges in
> a chroot: In any case you should only have access to those data which
> the privileges allow.

...which is usually pretty much everything in the bin directories, a lot
of stuff in /etc, and most importantly a shell. In a non-chrooted
program, an attacker who can exploit a bug can simply bind /bin/sh to a
port, run netcat, even use your compiler to prepare the next steps for
perhaps a local privilege escalation. In a chroot, nothing of the sort
is possible, you're limited to what you can do in your injected code.

> (Admittedly there is a _slight_ increase in security: You might now be
> safe of ways of privilege escalation by bugs in certain
> SUID-programms).

...plus safe from most information disclosure that would otherwise be
possible.

> > That's not to say that setting up a vserver for each of
> > your programs exposed to the net wasn't *more* secure than a chroot
>
> That's a different topic, but a vserver might also even be more
> dangerous than doing nothing, because it has to be implemented (of course)
> with the highest available privileges, and so you have an additional
> risk of bugs (i.e. possible exploits) of the vserver - and in such a
> case the attacker has immediately the highest privileges.

That's true, I just mentioned it because that's what Alan mentioned as
the true security tool.

> > but it's certainly a whole lot more secure if used
> > properly than not doing it at all.
>
> ...as is the usage of NAT as a "security feature".
> Of course, saying that using NAT or using chroot would not increase
> security at all would be a lie. But it is better to emphasize the
> dangers than to support the common misbelieve (as Alan alrady pointed
> out) that by using it there is no risk that "closed" ports can come
> through or that no other data than those in the chroot can be accessed.

Alan would probably emphasize the dangers of a seat belt and say
competent people used it only to keep their shopping bags from falling
over and not as a security tool because if you don't use it the
recommended way you can strangle yourself with it =^>

> Remember the starting point of the discussion: The statement "rsyncd uses
> chroot, so an attacker can do nothing bad" is just false.

Except that statement wasn't Neil's. To quote it correctly:
| In addition, the default rsyncd configuration with Gentoo uses a chroot
| jail. So even if you do allow connections to your portage tree, they
| won't be able to access anything else.

To summarize: for an attacker to be able to compromise a chrooted
rsyncd behind a NATting DSL router:
a) your ISP has to have a router configuration b0rked beyond belief
b) the attacker has to be aware of that and be able to distinguish
between your traffic and that of several hundred others that will
respond to his packets to 192.168.x.x
c) your router has to have a serious security hole
d) rsyncd has to be exploitable
e) your kernel needs to have a local privilege escalation bug

Now if that risk is worth the more complicated configuration using rsync
over ssh, I'm really not sure...I think I'd rather spend the time on
folding tin foil hats for the upcoming attack from Mars

cheers,
Matthias
--
I prefer encrypted and signed messages. KeyID: FAC37665
Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665
 

Thread Tools




All times are GMT. The time now is 12:35 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org