[users@httpd] security: fully blown chroot environment vs chrootdir

[SYBA <si...@jakilinux.org>]

Hello,

I was running apache for a number of years using fully blown chroot
environment, mostly on RHEL (using "chroot" binary as a base). Recently, I
have faced a requirement to wrap it up into rpm, which is not an easy task,
considering all up to date libs, dependencies, etc.

As chrootdir directive seems to appeared only in 2.2.9 (?), part of
mod_unixd, my question is how one could compare it to fully blown chroot
environment, looking at it from security point of view. Would that be the
same or are there any drawbacks on "chrootdir" side?

Also, I used to see information about mod_chroot, module, but this seem to
disappeared at some point. I believe this module is not maintained any more
for this purpose (at least google does not seem to know about it any more)?

All comments on this would be most appreciated.

Cheers.

S.

Re: [users@httpd] security: fully blown chroot environment vs chrootdir

[SYBA <si...@jakilinux.org>]

Thanks for that Dave.Current environment requirements do not let me use
SELinux hence I was wondering id there are any more comments on ChrootDir
directive ?

Thanks.

S.

On 17 November 2010 08:37, David (Dave) Donnan <david.donnan@thalesgroup.com
> wrote:

>  Just a thought recommended to me by RedHat last year.
>
> Run SELinux :
>
> SELinux can enforce the access rights of every user, application, process,
> and file
> within a Red Hat system to a degree previously unavailable in enterprise
> operating
> systems. It ensures that any application behaves as intended with very low
> performance overhead. (For more Information, see Red Hat Enterprise Linux
> Security
> Series: SELinux)
>
> Link: http://www.redhat.com/f/pdf/RHEL_Security_WP_web.pdf
>
>  Cdlt, Dave
> --------
>
> YBA wrote:
>
> Hello,
>
> I was running apache for a number of years using fully blown chroot
> environment, mostly on RHEL (using "chroot" binary as a base). Recently, I
> have faced a requirement to wrap it up into rpm, which is not an easy task,
> considering all up to date libs, dependencies, etc.
>
> As chrootdir directive seems to appeared only in 2.2.9 (?), part of
> mod_unixd, my question is how one could compare it to fully blown chroot
> environment, looking at it from security point of view. Would that be the
> same or are there any drawbacks on "chrootdir" side?
>
> Also, I used to see information about mod_chroot, module, but this seem to
> disappeared at some point. I believe this module is not maintained any more
> for this purpose (at least google does not seem to know about it any more)?
>
> All comments on this would be most appreciated.
>
> Cheers.
>
> S.
>
>
>

Re: [users@httpd] security: fully blown chroot environment vs chrootdir

["David (Dave) Donnan" <da...@thalesgroup.com>]

Just a thought recommended to me by RedHat last year.

Run SELinux :

        SELinux can enforce the access rights of every user,
        application, process, and file
        within a Red Hat system to a degree previously unavailable in
        enterprise operating
        systems. It ensures that any application behaves as intended
        with very low
        performance overhead. (For more Information, see Red Hat
        Enterprise Linux Security
        Series: SELinux)

        Link: http://www.redhat.com/f/pdf/RHEL_Security_WP_web.pdf

Cdlt, Dave
--------
YBA wrote:
> Hello,
>
> I was running apache for a number of years using fully blown chroot 
> environment, mostly on RHEL (using "chroot" binary as a base). 
> Recently, I have faced a requirement to wrap it up into rpm, which is 
> not an easy task, considering all up to date libs, dependencies, etc.
>
> As chrootdir directive seems to appeared only in 2.2.9 (?), part of 
> mod_unixd, my question is how one could compare it to fully blown 
> chroot environment, looking at it from security point of view. Would 
> that be the same or are there any drawbacks on "chrootdir" side?
>
> Also, I used to see information about mod_chroot, module, but this 
> seem to disappeared at some point. I believe this module is not 
> maintained any more for this purpose (at least google does not seem to 
> know about it any more)?
>
> All comments on this would be most appreciated.
>
> Cheers.
>
> S.