Hi,
Attached you can find a patch which adds a new hook for the sys_chroot()
syscall, and makes us able to add additional enforcing and security
checks by using the Linux Security Modules framework (ie. chdir
enforcing, etc).
Current user of the hook is the forthcoming 0.2 revision of vSecurity.
With it, and used within an LSM module, we can achieve the goal of
enforcing and apply some hardening to the sys_chroot() syscall.
Even if chroot jails are broken by design, in terms of security, with a
few changes to their base and some syscalls that it relies with, we can
achieve the goal of preventing some of the already known attacks against
them.
I will make available some patches for other syscalls as well
(sys_fchmod(), sys_chmod(), ...), that will add a few more hooks to the
LSM framework, in the hope that they will be useful.
The patch can be retrieved too from:
http://pearls.tuxedo-es.org/patches/sys_chroot_lsm-hook-2.6.11-rc3.patch
Thanks in advance, and, again, I will appreciate any suggestions on
which hooks are good candidates to be added.
Feel free to edit tuxedo-es.org wiki at http://wiki.tuxedo-es.org/LSM
and put suggestions & comments there.
Cheers,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
* Lorenzo Hern?ndez Garc?a-Hierro ([email protected]) wrote:
> Attached you can find a patch which adds a new hook for the sys_chroot()
> syscall, and makes us able to add additional enforcing and security
> checks by using the Linux Security Modules framework (ie. chdir
> enforcing, etc).
If you want to make a change like this, collapse the
capable(CAP_SYS_CHROOT) check behind this hook, no point having two
outcalls from same call site. What logic do you expect to put behind
the chroot() hook?
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
Hi,
If I understood you correct earlier, the only policy you needed to
enforce was to prevent double-chrooting. If that is the case, why is it
not sufficient to keep a "process-has-used-chroot" flag in
current->security which is set on the first call to
capable(CAP_SYS_CHROOT) and inherited by forked children, after which
calls to capable(CAP_SYS_CHROOT) are refused?
Of course if you need to do more, then a hook might be necessary.
-serge
El lun, 07-02-2005 a las 16:50 -0600, Serge E. Hallyn escribi?:
> Hi,
>
> If I understood you correct earlier, the only policy you needed to
> enforce was to prevent double-chrooting. If that is the case, why is it
> not sufficient to keep a "process-has-used-chroot" flag in
> current->security which is set on the first call to
> capable(CAP_SYS_CHROOT) and inherited by forked children, after which
> calls to capable(CAP_SYS_CHROOT) are refused?
>
> Of course if you need to do more, then a hook might be necessary.
Yeah, checking that process is chrooted using the current macro and
denying if capable() gets it trying to access CAP_SYS_CHROOT it's the
way that vSecurity currently does it.
But the hook will have to handle some chdir enforcing that can't be done
with current hooks, I will explain it further tomorrow.
It's too late here ;)
Cheers,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]
El lun, 07-02-2005 a las 14:34 -0800, Chris Wright escribi?:
> * Lorenzo Hern?ndez Garc?a-Hierro ([email protected]) wrote:
> > Attached you can find a patch which adds a new hook for the sys_chroot()
> > syscall, and makes us able to add additional enforcing and security
> > checks by using the Linux Security Modules framework (ie. chdir
> > enforcing, etc).
>
> If you want to make a change like this, collapse the
> capable(CAP_SYS_CHROOT) check behind this hook, no point having two
> outcalls from same call site.
Right, did it.
New patch attached and also available at:
http://pearls.tuxedo-es.org/patches/sys_chroot_lsm-hook-2.6.11-rc3.patch
> What logic do you expect to put behind
> the chroot() hook?
For example a chdir() handling function as grsec does, and also any
other check that comes up to mind.
Cheers and again thanks for the comments,
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]