Re: [PATCH] Add in_execve flag into task_struct.

From: Tetsuo Handa
Date: Thu Jan 08 2009 - 01:19:46 EST


Serge E. Hallyn wrote:
> > > Note btw that in the DAC case the dumpable flag gets cleared if the
> > > caller lacks read access to the program, so TOMOYO should do likewise if
> > > they are going to support this "execute-without-read" mode.
> > That's this "in_execve" flag.
>
> So you refuse to dump if in_execve is set?

No. TOMOYO refuses to check read permission in security_dentry_open()
if current->in_execve is set.

To utilize existing LSM hooks as much as possible, TOMOYO uses
security_dentry_open() for checking permissions when a file is opened for
reading and/or writing.

There is one exception. TOMOYO doesn't use security_dentry_open() for checking
permissions when a file is opened for executing.
TOMOYO uses security_bprm_check_security() instead.

Therefore, I need to make it possible to tell whether security_dentry_open()
was called by do_execve() or not.
Unfortunately, as I describe later, there are no LSM hooks which receive
sufficient information for telling whether security_dentry_open() was called by
do_execve() or not. As a result, I'm proposing 'in_execve' flag.

In TOMOYO, security_dentry_open() becomes a no-op function if
current->in_execve flag is set.

If you want TOMOYO not to access current->in_execve flag, it will be possible
to store "whether I'm inside do_execve() or not" into a private hash; but that
will require introduction of new LSM hooks for recording and erasing.

> There is already a security_bprm_committed_creds() hook. So you
> could hook abort_creds() and prepare_exec_creds(), and use them
> to set a flag in your tomoyo task->security state. Is that what
> David nacked in favor of this flag?

First of all, task->security no longer exists, and I'm not allowed to
set a flag in task->cred->security because task->cred is shared.

Next, I have no methods for knowing whether security_creds_prepare() was
called from prepare_exec_creds() or not. Examining function call stack is
far from clean approach. Introducing security_prepare_exec_creds() hook makes
no difference from introducing security_start_execve() hook.

Also, I have no methods for knowing whether security_creds_free() was called
by failure of an execve() operation or not. Introducing
security_free_exec_creds() hook makes no difference from introducing
security_finish_execve() hook.

So, I still believe this 'in_execve' flag is the tops.

> It's ugly, you can't get me to say it isn't ugly :) , and it sets a scary
> bad precedent. But if David insists (in a reply to this msg) that this
> flag really is tops, then just ignore me. Anyway my point wasn't to
> block the patch but to raise discussion (so someone else could decide to
> block it :) on both the flag and security implications of these
> semantics.

I'd like to listen to the David's opinion.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/