On Fri, 2004-10-08 at 22:50, Niki Rahimi wrote:
> +1. Trusted user, trusted path = User is able to run the executable.
> +2. Trusted user, untrusted path = User is able to run the
> executable.
> +3. Untrusted user, trusted path = User is able to run the executable.
> +4. Untrusted user, untrusted path = User is not able to run the
> executable.
> +
> +In short, if the path and user are both untrusted, execution will be
> denied.
Can you give a practical example of how this security model is useful?
Even given a correct implementation, how does it prevent untrusted users
from executing arbitrary code via an interpreter in a trusted path?
> +static int tpe_bprm_set_security (struct linux_binprm *bprm)
> +{
> + uid_t pthuid =
> bprm->file->f_dentry->d_parent->d_inode->i_uid;
> + mode_t pthmode =
> bprm->file->f_dentry->d_parent->d_inode->i_mode;
I think you want to use dget_parent() here for safety.
> +struct security_operations tpe_security_ops = {
> + bprm_set_security: tpe_bprm_set_security,
> +};
This only handles the execve code path. What about mmap/mprotect? What
prevents an untrusted user from just performing a userland exec of
whatever code he wants?
--
Stephen Smalley <sds@private>
National Security Agency
This archive was generated by hypermail 2.1.3 : Tue Oct 12 2004 - 05:33:46 PDT