[gentoo-hardened] to chroot or not to chroot

[gentoo-hardened] to chroot or not to chroot

[Jan Klod]

Hello,
I would like to see some opinions on chrooting - 

1) how big are possible risks of hardened gentoo system compromise, if apache 
is run normally, therefore a need of chrooting? 

2) suppose I chroot Apache: what chances it still has to harm something in the 
outside OS? My knowledge about various system capabilities, network etc is 
too little, so enlighten me... And how big is an Apache chroot?

And by the way, how big are the risks for sshd and ntpd to open up a way into 
the hardened gentoo system? Can that recent ntp glsa be ignored, if its 
hardened with memory protections?

Jan

Re: [gentoo-hardened] to chroot or not to chroot

[Michał Janke]

Hi,
I'm no expert but since you ask for opinions, here are some of mine :)
(Please, anyone, correct me, where I'm wrong.)


> 2) suppose I chroot Apache: what chances it still has to harm something in the
> outside OS? My knowledge about various system capabilities, network etc is
> too little, so enlighten me... And how big is an Apache chroot?

Starting with the last question - this, to my knowledge, seems to be
irrelevant. Chrooting (at least the simple cases I know and use) does
not require any additional or dedicated disk space. It is, in its
basic nature, an operation of changing the environment so that it
seems as if some chosen path (say /usr/chroot) was actually the root
(/) path. And as such, it is visible to all the programs run in this
env.
I'm not sure I understand the first part of the question - do you
mean, "what chances" of:
1) the chroot itself harming your OS,
2) you harming your OS by possible administrative mistakes - chroot confusions,
or
3) a potential attacker harming your OS after having compromised the Apache?

All of these are _some_ threats. If I were to try and order them
according to probabilities of mishaps, it'd be 2-1-3. That's assuming
you know not-too-much of how the system is structured. But it all
depends on really many, many, (...) things. For instance, if you just
hang on to some tutorial, then any of the first two is the more
possible, the more you decide to do your own way. But generally, I'd
bet the first is far less probable than 2, while both are quite
unlikely once you understand the idea of chroot and be careful to keep
it in mind at all times.
Still, I must say I know no details of "typical" Apache chroot
scenarios. As far,as I can imagine, there shouldn't be a place for
many tricky parts of it. But I'd be pleased to hear someone more
experienced in these matters.
The no. 3 is probably by far the least probable, as, firstly - the
chance of a random, small, non-production http server on the web being
attacked is very little. That is, the_http_server_itself. I believe it
is a few times more likely for a _box_ being attacked in other ways,
just because it showed itself to the web (running a http server),
rather than the http server itself being targeted against. And
secondly, once the Apache server is chrooted, the probability of the
system being harmed in _direct_ consequence of the fact that http got
compromised is greatly lessened thanks to chroot. Mind the "direct"
though, as it refers to the previous comment.

>
> And by the way, how big are the risks for sshd and ntpd to open up a way into
> the hardened gentoo system? Can that recent ntp glsa be ignored, if its
> hardened with memory protections?

At this point, again, I have to admit my ignorance, as I don't know in
what ways sshd, ntpd or any-d at all is actually hardened in h-g. Yet
I can just bet, that no matter how brilliant ideas of the h-g team are
brought into effect, potential ssh access being the most looked for by
the attackers, will be the one that, once gained, would pose the
greatest threat to the system. (NOW I get to be yelled at ;D)
I'm not saying it is easy to break into - certainly, in its
architecture, it isn't! I just mean that, in its nature, it can expose
the weakest points of your configuration and provide the most
convenient way of accessing the box, once compromised. Just keep this
in mind.

Ok, as I probably have made a fool (and ignorant) of myself anyway by
now, I'll add just one more stupid sentence: I haven't read the glsa
you refer to, but I would bet there would be many easier ways for an
attacker to get into a newly-and-n00bly setup server than compromising
ntpd.

Done. Now I get the laughs, please...

Re: [gentoo-hardened] to chroot or not to chroot

[Patrick Grieshaber]

Hi,

there are multiple ways to break out of a chroot-jail (example:
http://www.bpfh.net/simes/computing/chroot-break.html). So don't rely
on chroot's "security".

In my opinion I can't recommend chrooting a apache because:
  - time (chrooting apache costs a lot of time)
  - complexity -> unstable (if you forget to cpy a lib to the chroot  
env apache crashes during usage)
  - obsecurity

If you need a webserver with a good protection you should consider  
using SELinux for example. This is a bit better security. But of  
course - the complexity is far more harder then a chroot...
If SELinux is too much for you, use a virtual machine and secure the  
apache with nice settings, mod_security, php-ids and similiar  
technologies. I think I'd do it like that... just my 2 cents.

sysspoof


> Hello,
> I would like to see some opinions on chrooting -
>
> 1) how big are possible risks of hardened gentoo system compromise,
if apache
> is run normally, therefore a need of chrooting?
>
> 2) suppose I chroot Apache: what chances it still has to harm   
> something in the
> outside OS? My knowledge about various system capabilities, network
etc is
> too little, so enlighten me... And how big is an Apache chroot?
>
> And by the way, how big are the risks for sshd and ntpd to open up
a way into
> the hardened gentoo system? Can that recent ntp glsa be ignored, if
its
> hardened with memory protections?
>
> Jan
>
>

Re: [gentoo-hardened] to chroot or not to chroot

[Christian Affolter]

Hi Jan

> there are multiple ways to break out of a chroot-jail (example:
> http://www.bpfh.net/simes/computing/chroot-break.html). So don't rely
> on chroot's "security".
> 
> In my opinion I can't recommend chrooting a apache because:
>  - time (chrooting apache costs a lot of time)
>  - complexity -> unstable (if you forget to cpy a lib to the chroot env
> apache crashes during usage)
>  - obsecurity
> 
> If you need a webserver with a good protection you should consider using
> SELinux for example. This is a bit better security. But of course - the
> complexity is far more harder then a chroot...
> If SELinux is too much for you, use a virtual machine and secure the
> apache with nice settings, mod_security, php-ids and similiar
> technologies. I think I'd do it like that... just my 2 cents.

Yes, if you would like to have a secure and easy manageable chroot, use
Linux-VServer [1] & [2] or OpenVZ [3]. As far as I know at least the
Linux-VServer works with a "hardened" Kernel.


> sysspoof
> 
> 
>> Hello,
>> I would like to see some opinions on chrooting -
>>
>> 1) how big are possible risks of hardened gentoo system compromise,
> if apache
>> is run normally, therefore a need of chrooting?
>>
>> 2) suppose I chroot Apache: what chances it still has to harm 
>> something in the
>> outside OS? My knowledge about various system capabilities, network
> etc is
>> too little, so enlighten me... And how big is an Apache chroot?
>>
>> And by the way, how big are the risks for sshd and ntpd to open up
> a way into
>> the hardened gentoo system?

If you use one of the mentioned virtualization approaches above, the
sshd and ntpd daemons are running on the host and aren't
required/recommended to run within the chroot (vserver).


> Can that recent ntp glsa be ignored, if its
>> hardened with memory protections?
>>
>> Jan


[1]http://linux-vserver.org
[2]http://www.gentoo.org/proj/en/vps/vserver-howto.xml
[3]http://wiki.openvz.org

regards
Chris

Re: [gentoo-hardened] to chroot or not to chroot

[Jan Klod]

On Wednesday 10 June 2009 07:09:20 Patrick Grieshaber wrote:
> there are multiple ways to break out of a chroot-jail (example:
> http://www.bpfh.net/simes/computing/chroot-break.html). So don't rely
> on chroot's "security".
Did I missed something, if I assume, it doesn't concerns me, because I'll 
delete root from /chroot/etc/{passwd,group}? Well, there still remain other, 
rather indirect possibilities, I know. 

Re: [gentoo-hardened] to chroot or not to chroot

[RB]

On Tue, Jun 9, 2009 at 14:44, Jan Klod<janklodvan@gmail.com> wrote:
> 1) how big are possible risks of hardened gentoo system compromise, if apache
> is run normally, therefore a need of chrooting?

Mildly less than that a non-hardened system.  All the stack-smashing
and memory protections in the world won't protect you against a
poorly-configured system.  A hardened system would reduce the
probability of a remote Apache compromise, but does little to prevent
damage once the compromise has been made.

> 2) suppose I chroot Apache: what chances it still has to harm something in the
> outside OS? My knowledge about various system capabilities, network etc is
> too little, so enlighten me... And how big is an Apache chroot?

Less chance if you've turned on the hardened kernel's chroot()
protections (see http://www.grsecurity.net/features.php for the list).
 In a nutshell, said restrictions address the known set of jailbreak
tricks, helping keep a chroot() really a chroot().  There's still the
[very] outside chance that a kernel 0-day or previously unknown
jailbreak may pop up, but your attack surface is definitely lessened.

Size is variable - basically, you need the binary that's going to run,
all its libraries, and the on-disk data it will need to access (static
pages, etc.).  I'm seeing 2.7M taken up by my basic apache-2.2.11
install, of which ~2.1M is the actual binaries, modules, etc.  Add in
the ~3.8M of objects the apache2 binary links against, various bits of
configuration, and you're looking at roughly 6M for an unoptimized
chroot.  Look at one of the many chroot() preparation tools available
in portage (emerge -S chroot) for easy ways to set up clean chroot()
environments without any missing libraries.

> And by the way, how big are the risks for sshd and ntpd to open up a way into
> the hardened gentoo system? Can that recent ntp glsa be ignored, if its
> hardened with memory protections?

The NTP GLSA was a very specific one, addressing users that had not
only compiled net-misc/ntp against OpenSSL, but had also configured
the non-default 'autokey' authentication mechanism.  I've not examined
this particular compromise further to see whether the hardened stack
would protect against it, but it has before in similar situations.
SSH always increases your risk, but large portions of that may be
mitigated with ACLs, strong authentication, and restrictive
configurations.

The suggestions of virtual machines are good, but are much more
heavyweight solutions, resulting in good separation at the expense of
resources.  Even so, they cannot protect against poor configuration
(nothing does) and may add complexity you're not willing to engage.

SELinux (rather, a mandatory access control or MAC) is another option,
but more augments chroot or virtualization mechanisms rather than
replaces them.  If you choose to pursue this route, I highly suggest
at least looking at the grsecurity RBAC that is built into (and
supported in) the hardened-sources kernel.

Re: [gentoo-hardened] to chroot or not to chroot

[Jan Klod]

On Wednesday 10 June 2009 14:24:44 RB wrote:
> If you choose to pursue this route, I highly suggest
> at least looking at the grsecurity RBAC that is built into (and
> supported in) the hardened-sources kernel.
Well, I have such a kernel right now and quite likely, there is no need to 
rebuild it. I only lack some good information about how to set that Apache 
chroot up properly. Honestly I now tend to assume, my server is and will be 
only a mortal one, so I even consider just running it plainly. But if thats 
not an overkill, I'd like to jail Apache! Maybe you have some link...?

Chris, maybe I don't really need v-server? And yes, virtualisation is too 
heavy.

Jan

Re: [gentoo-hardened] to chroot or not to chroot

[RB]

On Wed, Jun 10, 2009 at 14:19, Jan Klod<janklodvan@gmail.com> wrote:
> only a mortal one, so I even consider just running it plainly. But if thats
> not an overkill, I'd like to jail Apache! Maybe you have some link...?

If you'll note:

On Wed, Jun 10, 2009 at 08:24, RB<aoz.syn@gmail.com> wrote:
> chroot.  Look at one of the many chroot() preparation tools available
> in portage (emerge -S chroot) for easy ways to set up clean chroot()
> environments without any missing libraries.

The three that stand out to me are app-admin/chroot_safe,
app-misc/jail, and dev-util/schroot (which is only in Sunrise at this
time).  I have zero experience with any of them, (I run no chrootable
services), so I can't really speak to which is better than the others.

Re: [gentoo-hardened] to chroot or not to chroot

[Mansour Moufid]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jun 10, 2009 at 4:19 PM, Jan Klod<janklodvan@gmail.com> wrote:
> Well, I have such a kernel right now and quite likely, there is no need to
> rebuild it. I only lack some good information about how to set that Apache
> chroot up properly. Honestly I now tend to assume, my server is and will be
> only a mortal one, so I even consider just running it plainly. But if thats
> not an overkill, I'd like to jail Apache! Maybe you have some link...?

This may or may not be what you're looking for, but Portage does have
the new "mod_chroot" (www-apache/mod_chroot) [1]:

  "mod_chroot allows you to run Apache in a chroot jail with no
additional files. The chroot() system call is performed at the end of
startup procedure - when all libraries are loaded and log files open."

[1] http://packages.gentoo.org/package/www-apache/mod_chroot?full_cat

- --
Mansour Moufid
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x95BBC25F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.5)

iEYEARECAAYFAkowH34ACgkQ83JwsZW7wl/wHQCdGwZfWLe+7Fvi9UjfJV+HkfQh
zeUAoOt6fuEBRKaB+2kU8fDhAJq7Daux
=HOi2
-----END PGP SIGNATURE-----

[gentoo-hardened] Re: to chroot or not to chroot

[7v5w7go9ub0o]

Jan Klod wrote:
> Hello, I would like to see some opinions on chrooting -
> 
> 1) how big are possible risks of hardened gentoo system compromise, 
> if apache is run normally, therefore a need of chrooting?
> 
> 2) suppose I chroot Apache: what chances it still has to harm 
> something in the outside OS? My knowledge about various system 
> capabilities, network etc is too little, so enlighten me... And how 
> big is an Apache chroot?
> 
> And by the way, how big are the risks for sshd and ntpd to open up a
>  way into the hardened gentoo system? Can that recent ntp glsa be 
> ignored, if its hardened with memory protections?
> 
> Jan
> 
> 

FWIW, I jail/chroot everything that connects to the net; e.g. browsers,
mail client, tor client, DNS server, nmap, snort, dhcpcd .....
everything. This because GRSecurity offers special protections to jailed
applications that don't normally exist, these in addition to specific
jail-breaking protections. This is the "openbsd" approach to business -
build stout jails. Add a layer of "linux" RBAC MAC controls, and you
should be good to go.

I can't imagine that chrooting Apache, sshd, ntpd, etc. would harm
anything. Don't know how others do it, but I create a separate directory
for each application (i.e. individual jails), copy (only) the required
executables and libraries into appropriately-named subdirectories within
the application directory, then run a wrapper which chroots, drops
privileges, and starts up the application (e.g. apache:apache) pointing
toward its individual the directory.

HTH

Re: [gentoo-hardened] Re: to chroot or not to chroot

[RijilV]

2009/6/10 7v5w7go9ub0o <7v5w7go9ub0o@gmail.com>:
> FWIW, I jail/chroot everything that connects to the net; e.g. browsers,
> mail client, tor client, DNS server, nmap, snort, dhcpcd .....
> everything.

What are you using to do your chrooting?

.r'

[gentoo-hardened] Re: to chroot or not to chroot

[7v5w7go9ub0o]

RijilV wrote:
> 2009/6/10 7v5w7go9ub0o 
> <7v5w7go9ub0o-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>> FWIW, I jail/chroot everything that connects to the net; e.g. 
>> browsers, mail client, tor client, DNS server, nmap, snort, dhcpcd 
>> ..... everything.
> 
> What are you using to do your chrooting?
> 
> .r'
> 

A man named Steve Friedl has written much about creating and breaking
out of chroot jails; I use his program "runchroot".

Here's his home page:
<http://unixwiz.net/techtips/chroot-practices.html#brkout>

I believe the script can be found in this "registerware" article: "Go
Directly to Jail. Available on all Linux and Unix systems, chroot jails
can secure untrusted applications and make trusted ones almost
impenetrable. Here’s how to build them." <http://www.linux-mag.com/id/1230>

FWIW, I run a desktop, and shortly expect to run an SSH server. Some of
the more important GRSecurity lockdowns break X server, so for a
desktop user, taking the extra step of jailing servers and other
net-connected applications seems to make sense - especially given the
wonderful jail-breaking protections afforded jails by GRSecurity
(obviously, if the Apache server is running on a separate box without X,
the full complement of GRS "hardening" would be used :-) :

  [*] Chroot jail restrictions

   [*]   Deny mounts
   [*]   Deny double-chroots
   [*]   Deny pivot_root in chroot
   [*]   Enforce chdir("/") on all chroots
   [*]   Deny (f)chmod +s
   [*]   Deny fchdir out of chroot
   [*]   Deny mknod
   [*]   Deny shmat() out of chroot
   [*]   Deny access to abstract AF_UNIX sockets out of chroot
   [*]   Protect outside processes
   [*]   Restrict priority changes
   [*]   Deny sysctl writes
   [*]   Capability restrictions

Again, the GRS RBAC program works extremely well, and is a powerful
companion to jails.

HTH

Re: [gentoo-hardened] Re: to chroot or not to chroot

[Vlad "SATtva" Miller]

7v5w7go9ub0o (11.06.2009 23:53):
> RijilV wrote:
>> 2009/6/10 7v5w7go9ub0o
>> <7v5w7go9ub0o-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>> FWIW, I jail/chroot everything that connects to the net; e.g.
>>> browsers, mail client, tor client, DNS server, nmap, snort, dhcpcd
>>> ..... everything.
>>
>> What are you using to do your chrooting?
>>
>> .r'
>>
> 
> A man named Steve Friedl has written much about creating and breaking
> out of chroot jails; I use his program "runchroot".
> 
> Here's his home page:
> <http://unixwiz.net/techtips/chroot-practices.html#brkout>
> 
> I believe the script can be found in this "registerware" article: "Go
> Directly to Jail. Available on all Linux and Unix systems, chroot jails
> can secure untrusted applications and make trusted ones almost
> impenetrable. Here’s how to build them." <http://www.linux-mag.com/id/1230>

Although there is indeed a link to download the script from that page
(http://www.linux-mag.com/downloads/2002-12/jail/), unfortunately it
leads to 404. But google turned up this:
http://www.linux-mag.com/downloads/2002-12/jail/runchroot.c
Should there be anything beyond this source file?

-- 
SATtva | security & privacy consulting
www.vladmiller.info | www.pgpru.com

[gentoo-hardened] Re: to chroot or not to chroot

[7v5w7go9ub0o]

Vlad "SATtva" Miller wrote:
> 7v5w7go9ub0o (11.06.2009 23:53):
>> RijilV wrote:
>>> 2009/6/10 7v5w7go9ub0o
>>> <7v5w7go9ub0o-Re5JQEeQqe8AvxtiuMwx3w-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org>:
>>>> FWIW, I jail/chroot everything that connects to the net; e.g.
>>>> browsers, mail client, tor client, DNS server, nmap, snort, dhcpcd
>>>> ..... everything.
>>> What are you using to do your chrooting?
>>>
>>> .r'
>>>
>> A man named Steve Friedl has written much about creating and breaking
>> out of chroot jails; I use his program "runchroot".
>>
>> Here's his home page:
>> <http://unixwiz.net/techtips/chroot-practices.html#brkout>
>>
>> I believe the script can be found in this "registerware" article: "Go
>> Directly to Jail. Available on all Linux and Unix systems, chroot jails
>> can secure untrusted applications and make trusted ones almost
>> impenetrable. Here’s how to build them." <http://www.linux-mag.com/id/1230>
> 
> Although there is indeed a link to download the script from that page
> (http://www.linux-mag.com/downloads/2002-12/jail/), unfortunately it
> leads to 404. But google turned up this:
> http://www.linux-mag.com/downloads/2002-12/jail/runchroot.c
> Should there be anything beyond this source file?
> 

Nope.... that's all there is to the wrapper.

gcc runchroot.c -o runchroot
chown root runchroot
chmod u+s runchroot


HTH

Re: [gentoo-hardened] Re: to chroot or not to chroot

[different]

On 16:21 Sun 14 Jun     , 7v5w7go9ub0o wrote:
>
> [... SNIP ...]
>
> Nope.... that's all there is to the wrapper.
>
> gcc runchroot.c -o runchroot
> chown root runchroot
> chmod u+s runchroot

Ouch. Do _not_ set the setuid-bit on runchroot. 
Otherwise it would be a piece of cake for the intruder
to gain root-privileges:
diff@mallory ~ $ ls -l runchroot
-rwsr-xr-x 1 root root 7680 Jun 15 04:37 runchroot
diff@mallory ~ $ ./runchroot -u root -d / -- /bin/sh
# id
uid=0(root) gid=0(root) groups=10(wheel),18(audio),27(video),1000(diff),
1007(qemu)
# ls -l /proc/self/root
lrwxrwxrwx 1 root root 0 Jun 15 04:45 /proc/self/root -> /

/ck

[gentoo-hardened] Re: to chroot or not to chroot

[7v5w7go9ub0o]

different wrote:
> On 16:21 Sun 14 Jun     , 7v5w7go9ub0o wrote:
>> [... SNIP ...]
>> 
>> Nope.... that's all there is to the wrapper.
>> 
>> gcc runchroot.c -o runchroot chown root runchroot chmod u+s
>> runchroot
> 
> Ouch. Do _not_ set the setuid-bit on runchroot. Otherwise it would be
> a piece of cake for the intruder to gain root-privileges: 
> diff@mallory ~ $ ls -l runchroot -rwsr-xr-x 1 root root 7680 Jun 15
> 04:37 runchroot diff@mallory ~ $ ./runchroot -u root -d / -- /bin/sh 
> # id uid=0(root) gid=0(root)
> groups=10(wheel),18(audio),27(video),1000(diff), 1007(qemu) # ls -l
> /proc/self/root lrwxrwxrwx 1 root root 0 Jun 15 04:45 /proc/self/root
> -> /
> 
> /ck

Thank you! for posting this!!

TBH, I wondered about this. After updating to 64bit, I compiled
runchroot and forgot to do the setuid-bit - yet everything *appears* to
work fine; i.e. the user is changed to the designated, unprivileged
user;    However, I haven't confirmed that the privileges have also been
dropped - they *seem* to have been. So I included the setuid advice
provided in this link: <http://www.gammon.com.au/forum/?id=885>

The source code makes no mention of setuid.

Based on your note, I'll continue with a non-setuid setup. :-)

Re: [gentoo-hardened] Re: to chroot or not to chroot

[Ed W]

[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]

RijilV wrote:
> 2009/6/10 7v5w7go9ub0o <7v5w7go9ub0o@gmail.com>:
>   
>> FWIW, I jail/chroot everything that connects to the net; e.g. browsers,
>> mail client, tor client, DNS server, nmap, snort, dhcpcd .....
>> everything.
>>     
>
> What are you using to do your chrooting?
>
> .r'
>
>   

Can I recommend the excellent linux-vserver project?  It's a bit more 
heavyweight than you were looking for, but basically makes it super 
simple to spin up what feel like fully virtualised machines.  
Weight-wise it's somewhere between a full virtualisation solution and a 
chroot (in fact it's kind of a wrapper around a chroot to make it feel 
like a full machine instance).  If you are really keen though you can 
use the unification utility and effectively hard-link many jails 
together which gives you a very, very lightweight way to run up many 
instances of a process.  Personally I wouldn't boot up a server without 
using at least this...

If you just want to harden apache then also look at mod_security which 
can give you a chroot and also quite a decent "software firewall" that 
may well help.  grsecurity (or other rbac) could additionally be used to 
constrain the damage a cgi script could cause

Good luck

Ed W

[-- Attachment #2: Type: text/html, Size: 1771 bytes --]