* Re: [LTP] Failure of get_robust_list01 test case in LTP for kernels 3.4-c3 and 3.3.3
2012-04-27 7:23 ` [LTP] Failure of get_robust_list01 test case in LTP for kernels 3.4-c3 and 3.3.3 Shyju PV
@ 2012-06-27 3:54 ` Wanlong Gao
0 siblings, 0 replies; 2+ messages in thread
From: Wanlong Gao @ 2012-06-27 3:54 UTC (permalink / raw)
To: shyju.pv
Cc: ltp-list, 'Shubham Goyal', nagamani.mantha,
'Sanil kumar'
On 04/27/2012 03:23 PM, Shyju PV wrote:
> Issue description:
> -------------------
> Kernel Version : 3.4-rc3
> System call : get_robust_list
> LTP Testcase : get_robust_list01
> LTP Version : 20100401
> Platform : x86_64 ( ATCA Board )
> Testcase Description : Verifies whether the get_robust_list() returns the
> proper errno for various failure cases
> Previous kernel version in which testcase passed : 3.2.9
>
Hi Shyju,
Sorry for late reply.
Thank you for your investigation.
I committed a patch to fix this test case to match with the kernel now,
please refer to,
https://github.com/linux-test-project/ltp/commit/d28ecfa1f14b62ad779db38164ce54d3adfc7425
As this syscall will be removed 2013, after then, we will mark this syscall
test as deprecated, too.
Thanks,
Wanlong Gao
> while Executing the syscall as given below
> if (seteuid(1) == -1)
> tst_brkm(TBROK|TERRNO, cleanup, "seteuid(1) failed");
> TEST(retval = syscall(__NR_get_robust_list, 1,(struct robust_list_head
> *)&head,&len_ptr));
>
> The return value of the code is expected to be -1 but 0 is returned and
> hence the LTP test failed.
>
> A detailed analysis revealed below observations.
> The failure details?
> The testcase tries to seteuid to a non-root user and tries to get the
> futex
> list of init process. A failure(EPERM) is expected from the system call.
> While
> in 3.2.9, the call behaved as per the expectation and failed, in 3.4-rc3
> the
> system call is successful causing the failure of the LTP test case.
>
> History of the problem:
> The issue was first discussed in grsecurity forum
> (http://forums.grsecurity.net/viewtopic.php?t=2916&p=11579), quoting the
> given
> LTP test. At that time test used to pass in vanilla kernel and used to fail
> in
> grsecurity kernel.
>>From the discussion:
> "It's correct that it (permission checking of grsecurity) doesn't match
> exactly
> the vanilla permission check, but the vanilla check is broken in serious
> ways."
> The thread died with the reporter saying that there are no real application
> which hits the scenario apart from the LTP test suite.
>
> For vanilla 3.2.16, a patch was submitted (signed off by Kees Cook
> <keescook@chromium.org>)
> making the permission check implementation of the system call same as that
> of grsecurity
> (https://lkml.org/lkml/2012/3/19/717, title: futex: Do not leak robust list
> to
> unprivileged process). Thomas Gleixner and Ingo Molnar was part of the
> discussion. It was decided to remove the system call in 2013 and was marked
> deprecated. The patch 'changes the permission checks to be the same as
> those
> used for similar info that comes out of /proc.'
>
> While initially the code was just checking for euid and uid check,
> the latest patch calls ptrace_may_access() bring in some extra checks as
> well.
> Now, if the user has access to the /proc of the process, it has
> access to the futext list, else not.
>
> ptrace_may_access() which is the additional new check:
>
> int dumpable = 0;
> /* Don't let security modules deny introspection */
> if (task == current)
> return 0;
> rcu_read_lock();
> tcred = __task_cred(task);
> if (cred->user->user_ns == tcred->user->user_ns &&
> (cred->uid == tcred->euid &&
> cred->uid == tcred->suid &&
> cred->uid == tcred->uid &&
> cred->gid == tcred->egid &&
> cred->gid == tcred->sgid &&
> cred->gid == tcred->gid))
> goto ok;
> if (ns_capable(tcred->user->user_ns, CAP_SYS_PTRACE))
> goto ok;
> rcu_read_unlock();
> return -EPERM;
> ok:
> rcu_read_unlock();
> smp_rmb();
> if (task->mm)
> dumpable = get_dumpable(task->mm);
> if (!dumpable && !task_ns_capable(task, CAP_SYS_PTRACE))
> return -EPERM;
>
> return security_ptrace_access_check(task, mode);
>
> Looking at the history and the changes that is introduced by the patch,
> shall we remove the test case
> from LTP which fails on the latest open source kernels.
>
> Shyju
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 2+ messages in thread