Hi,
As commented yesterday, I was going to release a few more hooks for some
*critical* syscalls, this one adds a hook to sys_chmod(), and makes us
able to apply checks and logics before releasing the operation to
sys_chmod().
The main goal is to provide a simple way to handle chmod() calls and
apply security restrictions & checks to them, and also add add auditing
capabilities (ie.: log chmod() calls in chroot()'ed environments, etc).
Patch attached and available at:
http://pearls.tuxedo-es.org/patches/sys_chmod_lsm-hook-2.6.11-rc3.patch
I would like to see this merged, Chris should decide :)
An user of this will be, as commented in my past emails, vSecurity 0.2
release, and any other LSM module that wants to have control over
chmod()'ing.
I will make available another hook for sys_fchmod() ASAP.
Cheers and thanks in advance,
--
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:
> As commented yesterday, I was going to release a few more hooks for some
> *critical* syscalls, this one adds a hook to sys_chmod(), and makes us
> able to apply checks and logics before releasing the operation to
> sys_chmod().
This is exactly the kind of hook we've tried to avoid. This is really
asking for permission to alter inode attribute data. This type of
hook is incomplete because there are other ways to alter this data,
and this access is already controlled by the inode_setattr hook (as
Tony mentioned). So this is a no go.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
El mar, 08-02-2005 a las 16:15 -0800, Chris Wright escribi?:
> * Lorenzo Hern?ndez Garc?a-Hierro ([email protected]) wrote:
> > As commented yesterday, I was going to release a few more hooks for some
> > *critical* syscalls, this one adds a hook to sys_chmod(), and makes us
> > able to apply checks and logics before releasing the operation to
> > sys_chmod().
>
> This is exactly the kind of hook we've tried to avoid. This is really
> asking for permission to alter inode attribute data. This type of
> hook is incomplete because there are other ways to alter this data,
> and this access is already controlled by the inode_setattr hook (as
> Tony mentioned). So this is a no go.
Right, the patch is no longer available as notify_change grabs the
inode_setattr hook returned data.
Did you checked the other one on sys_chroot()? (I've updated it a day or
so ago).
Cheers, thanks for commenting on it.
--
Lorenzo Hern?ndez Garc?a-Hierro <[email protected]>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]