Re: kernel BUG at kernel/cred.c:434!

From: Yang Yingliang
Date: Sat Apr 20 2019 - 03:39:11 EST




On 2019/4/20 0:13, Paul Moore wrote:
On Fri, Apr 19, 2019 at 10:34 AM Yang Yingliang
<yangyingliang@xxxxxxxxxx> wrote:
On 2019/4/19 21:24, Paul Moore wrote:
On Thu, Apr 18, 2019 at 10:42 PM Yang Yingliang
<yangyingliang@xxxxxxxxxx> wrote:
On 2019/4/19 10:04, Paul Moore wrote:
On Wed, Apr 17, 2019 at 10:50 PM Yang Yingliang
<yangyingliang@xxxxxxxxxx> wrote:
On 2019/4/18 8:24, Casey Schaufler wrote:
On 4/17/2019 4:39 PM, Paul Moore wrote:
Since it looks like all three LSMs which implement the setprocattr
hook are vulnerable I'm open to the idea that proc_pid_attr_write() is
a better choice for the cred != read_cred check, but I would want to
make sure John and Casey are okay with that.

John?

Casey?
I'm fine with the change going into proc_pid_attr_write().
The cred != real_cred checking is not enough.

Consider this situation, when doing override, cred, real_cred and
new_cred are all same:

after override_creds() cred == real_cred == new1_cred
I'm sorry, you've lost me. After override_creds() returns
current->cred and current->real_cred are not going to be the same,
yes?
It's possible the new cred is equal to current->real_cred and
current->cred,
so after overrides_creds(), they have the same value.
Both task_struct.cred and task_struct.real_cred are pointer values,
assuming that one uses prepare_creds() to allocate/initialize a new
cred struct for use with override_creds() then the newly created cred
should never be equal to task_struct.real_cred. Am I missing
something, or are you thinking of something else?
In do_acct_process(), file->f_cred may equal to current->real_cred, I
confirm
it by adding some debug message in do_acct_process() like this:
I would expect that; real_cred is the task's objective DAC
credentials, so using it for f_cred makes sense.

What we are now talking about is the task's subjective credentials,
which can be overridden via override_creds(), and are what the LSMs
change via proc_pid_attr_write().
I'm not sure you got my point.

I was saying cred != real_cred check is not quite right, because the cred can
be overridden by a same pointer as my print messages showing.

"cred != real_cred" means override_creds() is called, but "cred == real_cred"
doesn't mean override_creds() is not called.

When we use "cred != real_cred" check, we may lost the situation that cred
is overridden by a same pointer. In this case, we will do override_creds() =>
commit_creds() => revert_creds(), this make cred != real_cred, when a new
commit_creds() is called, it also will trigger a BUG_ON().

--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -481,6 +481,7 @@ static void do_acct_process(struct bsd_acct_struct
*acct)
flim = current->signal->rlim[RLIMIT_FSIZE].rlim_cur;
current->signal->rlim[RLIMIT_FSIZE].rlim_cur = RLIM_INFINITY;
/* Perform file operations on behalf of whoever enabled
accounting */
+ pr_info("task:%px new cred:%px real cred:%px cred:%px\n",
current, file->f_cred, current->real_cred, current->cred);
orig_cred = override_creds(file->f_cred);