linux-kernel - Re: [PATCH] Add in_execve flag into task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200901080617.n086HtWN019551@www262.sakura.ne.jp>
Date:	Thu, 08 Jan 2009 15:17:55 +0900
From:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:	serue@...ibm.com
Cc:	sds@...ho.nsa.gov, spotter@...columbia.edu, dhowells@...hat.com,
	linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add in_execve flag into task_struct.

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/