Re: [LTP] [PATCH] securebits: add secure_keepcaps testcases
Hi Serge, Some comments about your provided code. Thanks! -Garrett On Wed, Sep 29, 2010 at 6:56 AM, Serge E. Hallyn se...@hallyn.com wrote: This adds basic tests of the keepcaps securebits settings. Lots more securebits tests to come (see my email from one or 1.5 years ago, and, heck, write them if you have time :). Signed-off-by: Serge E. Hallyn serge.hal...@canonical.com --- m4/ltp-securebits.m4 | 24 +++ runtest/securebits | 2 + testcases/kernel/security/Makefile | 5 +- testcases/kernel/security/securebits/Makefile | 28 .../kernel/security/securebits/check_keepcaps.c | 161 .../kernel/security/securebits/run_securebits.sh | 20 +++ 6 files changed, 239 insertions(+), 1 deletions(-) create mode 100644 m4/ltp-securebits.m4 create mode 100644 runtest/securebits create mode 100644 testcases/kernel/security/securebits/Makefile create mode 100644 testcases/kernel/security/securebits/check_keepcaps.c create mode 100644 testcases/kernel/security/securebits/run_securebits.sh diff --git a/m4/ltp-securebits.m4 b/m4/ltp-securebits.m4 new file mode 100644 index 000..6407eb8 --- /dev/null +++ b/m4/ltp-securebits.m4 @@ -0,0 +1,24 @@ +dnl +dnl Copyright (c) Serge Hallyn (2010) +dnl +dnl This program is free software; you can redistribute it and/or modify +dnl it under the terms of the GNU General Public License as published by +dnl the Free Software Foundation; either version 2 of the License, or +dnl (at your option) any later version. +dnl +dnl This program is distributed in the hope that it will be useful, +dnl but WITHOUT ANY WARRANTY; without even the implied warranty of +dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See +dnl the GNU General Public License for more details. +dnl +dnl You should have received a copy of the GNU General Public License +dnl along with this program; if not, write to the Free Software +dnl Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +dnl + + +AC_DEFUN([LTP_CHECK_SECUREBITS], +AC_CHECK_HEADERS(linux/securebits.h,[ + LTP_SECUREBITS=yes +]) +) Some checks should probably be added for versioning as well as symbols that get passed to prctl(2) (I'm not sure if checking for the symbols that get passed to prctl(2) here is the correct way to go about things though). diff --git a/runtest/securebits b/runtest/securebits new file mode 100644 index 000..d78a66f --- /dev/null +++ b/runtest/securebits @@ -0,0 +1,2 @@ +#DESCRIPTION:securebits tests +Securebits run_securebits.sh diff --git a/testcases/kernel/security/Makefile b/testcases/kernel/security/Makefile index 52b8d06..a877836 100644 --- a/testcases/kernel/security/Makefile +++ b/testcases/kernel/security/Makefile @@ -27,11 +27,14 @@ include $(top_srcdir)/include/mk/env_pre.mk # For broken compilers and toolchains, like Montavista, that improperly detect # system headers when running autoconf -_-... bleh. ifeq ($(strip $(CAP_LIBS)),) -FILTER_OUT_DIRS := cap_bound filecaps +FILTER_OUT_DIRS := cap_bound filecaps securebits endif ifeq ($(HAVE_SETCAP),false) FILTER_OUT_DIRS += filecaps endif +ifeq ($(LTP_SECUREBITS),false) +FILTER_OUT_DIRS += securebits +endif # XXX (garrcoop): avoid compilation failures on RHEL 5.4, as reported by # Mitani-san, because of policy versioning issues... diff --git a/testcases/kernel/security/securebits/Makefile b/testcases/kernel/security/securebits/Makefile new file mode 100644 index 000..a76f2e0 --- /dev/null +++ b/testcases/kernel/security/securebits/Makefile @@ -0,0 +1,28 @@ + +## ## +## Copyright (c) International Business Machines Corp., 2009 ## +## ## +## This program is free software; you can redistribute it and#or modify ## +## it under the terms of the GNU General Public License as published by ## +## the Free Software Foundation; either version 2 of the License, or ## ## (at your option) any later version. ## +## ## +## This program is distributed in the hope that it will be useful, but ## +## WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY ## +## or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License ## +## for more details. ## +## ## +## You
Re: [LTP] ltp_clone alignment issues.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/1/2010 6:06 AM, Hannu Heikkinen wrote: On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote: On 9/30/2010 3:31 PM, Hannu Heikkinen wrote: On 29/09/10 15:34 +0200, ext Carmelo AMOROSO wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/27/2010 3:34 PM, Carmelo AMOROSO wrote: Folks, I want to reopen an old discussion on ltp_clone and stack alignment issue (see http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com). Indeed recently a commit has partially fixed a problem on ARM (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be extended to all archs that have stack that grows downwards. Indeed, as Jiri replied in that old thread, the value passed to clone as child stack should be never accessed, because it is the topmost address of the memory allocated for the child process (it's the previous stack pointer). So, in archs that do not like unaligned stack, using (stack - size - 1 ) will cause the process to be killed by a SIGBUS, on other archs, we are just wasting one byte of the malloc-ed stack. On my SH4 arch, the stack must be 4byte aligned (as in ARM). Please, find attached a patch against master branch Best regards, Carmelo Hi, any feedback on this ? Cheers, Carmelo Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com --- lib/cloner.c | 9 +++-- 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/lib/cloner.c b/lib/cloner.c index 6ad4a00..e53c9cf 100644 --- a/lib/cloner.c +++ b/lib/cloner.c @@ -59,16 +59,13 @@ ltp_clone(unsigned long clone_flags, int (*fn)(void *arg), void *arg, ret = clone(fn, stack, clone_flags, arg); #elif defined(__ia64__) ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL, NULL); -#elif defined(__arm__) +#else /* - * Stack size should be a multiple of 32 bit words - * stack limit must be aligned to a 32 bit boundary + * For archs where stack grows downwards, stack points to the topmost address + * of the memory space set up for the child stack. */ ret = clone(fn, (stack ? stack + stack_size : NULL), clone_flags, arg); -#else - ret = clone(fn, (stack ? stack + stack_size - 1 : NULL), - clone_flags, arg); #endif return ret; -- Hi, Acked-by Hannu Heikkinen ext-hannu.m.heikki...@nokia.com Br, Hannu -- Hannu Heikkinen http://www.nixu.com Thanks, Hannu Hi, I was thinking your patch once again, and I think it would be wiser if we would have something like: --- ../tmp2/ltp-full-20100630/lib/cloner.c 2010-07-03 21:29:04.0 +0300 +++ lib/cloner.c 2010-09-03 14:48:20.0 +0300 @@ -43,6 +43,16 @@ pid_t *parent_tid, void *tls, pid_t *child_tid); #endif +/* + * Most arch really want to have stack aligned to some sane boundary. + */ +#ifdef __arm__ +#define ALIGN_STACK(stack) \ + ((void *)(((unsigned long)stack) ~((sizeof(void *)) - 1))) +#else +#define ALIGN_STACK(stack) (stack) +#endif + /*** * ltp_clone: wrapper for clone to hide the architecture dependencies. * 1. hppa takes bottom of stack and no stacksize (stack grows up) @@ -60,7 +70,7 @@ #elif defined(__ia64__) ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL, NULL); #else - ret = clone(fn, (stack ? stack + stack_size - 1 : NULL), + ret = clone(fn, (stack ? ALIGN_STACK(stack + stack_size - 1) : NULL), clone_flags, arg); #endif The above patch iis in use in our ARM based LTP test suite. Note that -1 is needed for not clobbering eg possibly malloced area after child stack. Could u please change that prev patch a bit, for ensuring that child stack is in proper size etc. Above patch is not sufficient, because ALIGN_STACK in that is only used for arm archs. br, Hannu Hannu, I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation. Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter. I would just leave the LTP_clone passing the argument to the clone as they came from the caller. Regards, Carmelo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyp0OsACgkQoRq/3BrK1s+TPwCgnoZlDNW0yMjfLZAu6gKzywP7 Bp4AoLpYpxtqjtd+tL4+ZpxNhnQv7fpF =VGJo -END PGP SIGNATURE- -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better
Re: [LTP] [PATCH] Compilation Error Fixed in filecaps.
Quoting Garrett Cooper (yaneg...@gmail.com): So I'm not sure what Serge was looking at... Not me. -serge -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] ltp_clone alignment issues.
On Mon, Oct 4, 2010 at 6:04 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/1/2010 6:06 AM, Hannu Heikkinen wrote: On 30/09/10 12:42 +0200, Carmelo AMOROSO wrote: On 9/30/2010 3:31 PM, Hannu Heikkinen wrote: On 29/09/10 15:34 +0200, ext Carmelo AMOROSO wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/27/2010 3:34 PM, Carmelo AMOROSO wrote: Folks, I want to reopen an old discussion on ltp_clone and stack alignment issue (see http://sourceforge.net/mailarchive/message.php?msg_name=4B421480.1040400%40petalogix.com). Indeed recently a commit has partially fixed a problem on ARM (0056e395170eb8fc3ffbb22d7bd364fe47c2013e), but I think this should be extended to all archs that have stack that grows downwards. Indeed, as Jiri replied in that old thread, the value passed to clone as child stack should be never accessed, because it is the topmost address of the memory allocated for the child process (it's the previous stack pointer). So, in archs that do not like unaligned stack, using (stack - size - 1 ) will cause the process to be killed by a SIGBUS, on other archs, we are just wasting one byte of the malloc-ed stack. On my SH4 arch, the stack must be 4byte aligned (as in ARM). Please, find attached a patch against master branch Best regards, Carmelo Hi, any feedback on this ? Cheers, Carmelo Signed-off-by: Carmelo Amoroso carmelo.amor...@st.com --- lib/cloner.c | 9 +++-- 1 files changed, 3 insertions(+), 6 deletions(-) diff --git a/lib/cloner.c b/lib/cloner.c index 6ad4a00..e53c9cf 100644 --- a/lib/cloner.c +++ b/lib/cloner.c @@ -59,16 +59,13 @@ ltp_clone(unsigned long clone_flags, int (*fn)(void *arg), void *arg, ret = clone(fn, stack, clone_flags, arg); #elif defined(__ia64__) ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL, NULL); -#elif defined(__arm__) +#else /* - * Stack size should be a multiple of 32 bit words - * stack limit must be aligned to a 32 bit boundary + * For archs where stack grows downwards, stack points to the topmost address + * of the memory space set up for the child stack. */ ret = clone(fn, (stack ? stack + stack_size : NULL), clone_flags, arg); -#else - ret = clone(fn, (stack ? stack + stack_size - 1 : NULL), - clone_flags, arg); #endif return ret; -- Hi, Acked-by Hannu Heikkinen ext-hannu.m.heikki...@nokia.com Br, Hannu -- Hannu Heikkinen http://www.nixu.com Thanks, Hannu Hi, I was thinking your patch once again, and I think it would be wiser if we would have something like: --- ../tmp2/ltp-full-20100630/lib/cloner.c 2010-07-03 21:29:04.0 +0300 +++ lib/cloner.c 2010-09-03 14:48:20.0 +0300 @@ -43,6 +43,16 @@ pid_t *parent_tid, void *tls, pid_t *child_tid); #endif +/* + * Most arch really want to have stack aligned to some sane boundary. + */ +#ifdef __arm__ +#define ALIGN_STACK(stack) \ + ((void *)(((unsigned long)stack) ~((sizeof(void *)) - 1))) +#else +#define ALIGN_STACK(stack) (stack) +#endif + /*** * ltp_clone: wrapper for clone to hide the architecture dependencies. * 1. hppa takes bottom of stack and no stacksize (stack grows up) @@ -60,7 +70,7 @@ #elif defined(__ia64__) ret = clone2(fn, stack, stack_size, clone_flags, arg, NULL, NULL, NULL); #else - ret = clone(fn, (stack ? stack + stack_size - 1 : NULL), + ret = clone(fn, (stack ? ALIGN_STACK(stack + stack_size - 1) : NULL), clone_flags, arg); #endif The above patch iis in use in our ARM based LTP test suite. Note that -1 is needed for not clobbering eg possibly malloced area after child stack. Could u please change that prev patch a bit, for ensuring that child stack is in proper size etc. Above patch is not sufficient, because ALIGN_STACK in that is only used for arm archs. br, Hannu Hannu, I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation. Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter. I would just leave the LTP_clone passing the argument to the clone as they came from the caller. I believe this is already handled to some degree with the clone testcases. If not that should be added and I'll review patches which add this testing to LTP. On a semi-unrelated note could you guys please test out the attached patch to make sure that there isn't a functional difference if you have access to ia64, s390, etc? Thanks, -Garrett remove-clone-platform.diff Description: Binary data -- Virtualization is moving to the mainstream
Re: [LTP] patch to define PTRACE_KILL and PTRACE_CONT
On Mon, Oct 4, 2010 at 6:08 AM, Yi Xu y...@suse.de wrote: Hi, this patch solves compiling error that appears with certain GCC version. Hi Yi, You most likely need to fix your headers or your compiler: [gcoo...@bayonetta /scratch/ltp]$ grep -r __PTRACE_KILL__ . [gcoo...@bayonetta /scratch/ltp]$ grep -r __PTRACE_CONT__ . [gcoo...@bayonetta /scratch/ltp]$ Nowhere in the sourcebase are those symbols defined / used (at least not directly). Furthermore, rwatson@'s search indexer returns NIL for the symbol: http://fxr.watson.org/fxr/trackident?v=linux-2.6;i=__PTRACE_KILL__ If you provided your error logs we might be able to help you... Thanks, -Garrett -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] [PATCH] securebits: add secure_keepcaps testcases
On Wed, 2010-09-29 at 20:32 +0530, Subrata Modak wrote: On Wed, 2010-09-29 at 08:56 -0500, Serge E. Hallyn wrote: This adds basic tests of the keepcaps securebits settings. Lots more securebits tests to come (see my email from one or 1.5 years ago, and, heck, write them if you have time :). Signed-off-by: Serge E. Hallyn serge.hal...@canonical.com Great, i get the following output on my machine: # uname -a Linux 2.6.35.4 #2 SMP Tue Sep 28 16:07:27 IST 2010 ppc64 ppc64 ppc64 GNU/Linux # cat /etc/issue Fedora release 13 (Goddard) # ./runltp -f securebits Running tests... test_start tag=Securebits stime=1285772204 cmdline=run_securebits.sh contacts= analysis=exit test_output incrementing stop testing keepcaps keepcaps1 TPASS : dropped privs as expected keepcaps1 TPASS : kept privs as expected keepcaps1 TPASS : kept privs as expected execution_status initiation_status=ok duration=0 termination_type=exited termination_id=0 corefile=no cutime=0 cstime=0 test_end INFO: ltp-pan reported all tests PASS LTP Version: LTP-20100831 ### Done executing testcases. LTP Version: LTP-20100831 ### Looks fine to be,i just need a little documentation file which would say: What securebits is all about (some pointers/links)? Any specific configuration required to run these tests, etc ? Serge, Can you also provide me this ? Regards-- Subrata Regards-- Subrata --- m4/ltp-securebits.m4 | 24 +++ runtest/securebits |2 + testcases/kernel/security/Makefile |5 +- testcases/kernel/security/securebits/Makefile | 28 .../kernel/security/securebits/check_keepcaps.c| 161 .../kernel/security/securebits/run_securebits.sh | 20 +++ 6 files changed, 239 insertions(+), 1 deletions(-) create mode 100644 m4/ltp-securebits.m4 create mode 100644 runtest/securebits create mode 100644 testcases/kernel/security/securebits/Makefile create mode 100644 testcases/kernel/security/securebits/check_keepcaps.c create mode 100644 testcases/kernel/security/securebits/run_securebits.sh diff --git a/m4/ltp-securebits.m4 b/m4/ltp-securebits.m4 new file mode 100644 index 000..6407eb8 --- /dev/null +++ b/m4/ltp-securebits.m4 @@ -0,0 +1,24 @@ +dnl +dnl Copyright (c) Serge Hallyn (2010) +dnl +dnl This program is free software; you can redistribute it and/or modify +dnl it under the terms of the GNU General Public License as published by +dnl the Free Software Foundation; either version 2 of the License, or +dnl (at your option) any later version. +dnl +dnl This program is distributed in the hope that it will be useful, +dnl but WITHOUT ANY WARRANTY; without even the implied warranty of +dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See +dnl the GNU General Public License for more details. +dnl +dnl You should have received a copy of the GNU General Public License +dnl along with this program; if not, write to the Free Software +dnl Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA +dnl + + +AC_DEFUN([LTP_CHECK_SECUREBITS], +AC_CHECK_HEADERS(linux/securebits.h,[ + LTP_SECUREBITS=yes +]) +) diff --git a/runtest/securebits b/runtest/securebits new file mode 100644 index 000..d78a66f --- /dev/null +++ b/runtest/securebits @@ -0,0 +1,2 @@ +#DESCRIPTION:securebits tests +Securebits run_securebits.sh diff --git a/testcases/kernel/security/Makefile b/testcases/kernel/security/Makefile index 52b8d06..a877836 100644 --- a/testcases/kernel/security/Makefile +++ b/testcases/kernel/security/Makefile @@ -27,11 +27,14 @@ include $(top_srcdir)/include/mk/env_pre.mk # For broken compilers and toolchains, like Montavista, that improperly detect # system headers when running autoconf -_-... bleh. ifeq ($(strip $(CAP_LIBS)),) -FILTER_OUT_DIRS:= cap_bound filecaps +FILTER_OUT_DIRS:= cap_bound filecaps securebits endif ifeq ($(HAVE_SETCAP),false) FILTER_OUT_DIRS+= filecaps endif +ifeq ($(LTP_SECUREBITS),false) +FILTER_OUT_DIRS+= securebits +endif # XXX (garrcoop): avoid compilation failures on RHEL 5.4, as reported by # Mitani-san, because of policy versioning issues... diff --git a/testcases/kernel/security/securebits/Makefile b/testcases/kernel/security/securebits/Makefile new file mode 100644 index 000..a76f2e0 --- /dev/null +++ b/testcases/kernel/security/securebits/Makefile @@ -0,0 +1,28 @@ + +##
Re: [LTP] [PATCH] securebits: add secure_keepcaps testcases
Quoting Subrata Modak (subr...@linux.vnet.ibm.com): Looks fine to be,i just need a little documentation file which would say: What securebits is all about (some pointers/links)? Any specific configuration required to run these tests, etc ? Serge, Can you also provide me this ? I don't know where you'd want that documentation file, but for contents I think it should just read: For more information on securebits, see the capabilities.7 manpage, specifically the section entitled The securebits flags: establishing a capabilities-only environment To run these tests there are no kernel configuration requirements, but your kernel must be at least Linux 2.6.32-rc7, and you must have a /usr/include/linux/securebits.h which defines SECBIT_NOROOT. You also need the libcap v2 development libraries installed. thanks, -serge -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
[LTP] patch to define PTRACE_KILL and PTRACE_CONT
Hi, this patch solves compiling error that appears with certain GCC version. Regards, Yi -- Yi Xu y...@suse.de SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --- testcases/kernel/syscalls/ptrace/ptrace.h.orig 2010-09-13 15:46:24.145591000 +0200 +++ testcases/kernel/syscalls/ptrace/ptrace.h 2010-09-13 16:18:40.732974000 +0200 @@ -4,6 +4,15 @@ #ifndef __LTP_PTRACE_H__ #define __LTP_PTRACE_H__ +#endif + +#ifndef __PTRACE_KILL__ +#define __PTRACE_KILL__ +#endif + +#ifndef __PTRACE_CONT__ +#define __PTRACE_CONT__ +#endif #ifdef HAVE_SYS_PTRACE_H # include sys/ptrace.h @@ -30,4 +39,3 @@ typedef struct pt_regs ptrace_regs; typedef struct user_regs_struct ptrace_regs; #endif -#endif -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d___ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] [PATCH] securebits: add secure_keepcaps testcases
Quoting Garrett Cooper (yaneg...@gmail.com):
Hi Serge,
Some comments about your provided code.
Thanks.
+AC_DEFUN([LTP_CHECK_SECUREBITS],
+AC_CHECK_HEADERS(linux/securebits.h,[
+ LTP_SECUREBITS=yes
+])
+)
Some checks should probably be added for versioning as well as symbols
that get passed to prctl(2) (I'm not sure if checking for the symbols
that get passed to prctl(2) here is the correct way to go about things
though).
Not sure how we would check the versioning, bc there is no versioning
info in the interface.
...
+ case 3:
+ ret = prctl(PR_GET_SECUREBITS);
What if this call fails?
It doesn't pass or fail. The return value is simply the current
securebits.
+ ret = prctl(PR_SET_SECUREBITS, ret | SECBIT_KEEP_CAPS);
+ if (ret == -1) {
+ tst_resm(TFAIL|TERRNO, PR_SET_SECUREBITS
failed\n);
+ tst_exit();
+ }
+#!/bin/sh
+
+echo testing keepcaps
+check_keepcaps 1
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+check_keepcaps 2
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+check_keepcaps 3
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+
+exit $exit_code
What if (for instance) test 1 fails, and tests 2 or 3 pass?
Yeah, I didn't do that right, and maybe it would be best
to just shortcut on the first failure anyway.
thanks,
-serge
--
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security
easier or more difficult to achieve? Read this whitepaper to separate the
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
___
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] [PATCH] securebits: add secure_keepcaps testcases
On Mon, Oct 4, 2010 at 7:06 AM, Serge E. Hallyn
serge.hal...@canonical.com wrote:
Quoting Garrett Cooper (yaneg...@gmail.com):
Hi Serge,
Some comments about your provided code.
Thanks.
+AC_DEFUN([LTP_CHECK_SECUREBITS],
+AC_CHECK_HEADERS(linux/securebits.h,[
+ LTP_SECUREBITS=yes
+])
+)
Some checks should probably be added for versioning as well as symbols
that get passed to prctl(2) (I'm not sure if checking for the symbols
that get passed to prctl(2) here is the correct way to go about things
though).
Not sure how we would check the versioning, bc there is no versioning
info in the interface.
Just checking for the symbols used with an autoconf test would be ok,
because according to the kernel.org manpage [1] some of these symbols
have only existed for the past year or two (and thus someone like
Mitani-san will come on the list and say that RHEL 4.x or 5.x compiles
are broken by the new test :)).
...
+ case 3:
+ ret = prctl(PR_GET_SECUREBITS);
What if this call fails?
It doesn't pass or fail. The return value is simply the current
securebits.
According to the manpage [1], this syscall can fail.
+ ret = prctl(PR_SET_SECUREBITS, ret | SECBIT_KEEP_CAPS);
+ if (ret == -1) {
+ tst_resm(TFAIL|TERRNO, PR_SET_SECUREBITS
failed\n);
+ tst_exit();
+ }
+#!/bin/sh
+
+echo testing keepcaps
+check_keepcaps 1
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+check_keepcaps 2
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+check_keepcaps 3
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+
+exit $exit_code
What if (for instance) test 1 fails, and tests 2 or 3 pass?
Yeah, I didn't do that right, and maybe it would be best
to just shortcut on the first failure anyway.
That's what I thought. The only thing you lose is coverage potentially
if one of the tests is broken :/.
Thanks!
-Garrett
[1] http://www.kernel.org/doc/man-pages/online/pages/man2/prctl.2.html
--
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security
easier or more difficult to achieve? Read this whitepaper to separate the
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
___
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] [PATCH] securebits: add secure_keepcaps testcases
Quoting Garrett Cooper (yaneg...@gmail.com):
On Mon, Oct 4, 2010 at 7:06 AM, Serge E. Hallyn
serge.hal...@canonical.com wrote:
Quoting Garrett Cooper (yaneg...@gmail.com):
Hi Serge,
Some comments about your provided code.
Thanks.
+AC_DEFUN([LTP_CHECK_SECUREBITS],
+AC_CHECK_HEADERS(linux/securebits.h,[
+ LTP_SECUREBITS=yes
+])
+)
Some checks should probably be added for versioning as well as symbols
that get passed to prctl(2) (I'm not sure if checking for the symbols
that get passed to prctl(2) here is the correct way to go about things
though).
Not sure how we would check the versioning, bc there is no versioning
info in the interface.
Just checking for the symbols used with an autoconf test would be ok,
because according to the kernel.org manpage [1] some of these symbols
have only existed for the past year or two
Right, but before that the header file wouldn't have existed. The
symbols appeared with the header file's creation.
Of course someone can shoot himself in the foot with older kernel on
newer userspace. I don't mind doing the extra checks, it'll just take
me a few weeks to get the chance. The tests aren't going to go stale
in the meantime, so no big whoop.
(and thus someone like
Mitani-san will come on the list and say that RHEL 4.x or 5.x compiles
are broken by the new test :)).
My theory is that this test will suffice for older RHEL :) but
not for more experimental chaps, I guess.
...
+ case 3:
+ ret = prctl(PR_GET_SECUREBITS);
What if this call fails?
It doesn't pass or fail. The return value is simply the current
securebits.
According to the manpage [1], this syscall can fail.
I don't actually see where the syscall says it can fail (it says that
for CAPBSET_READ, but not for GET_SECUREBITS. So it can only fail
if the capability module's prctl() isn't called. I know of no ways
that can happen with current upstream, bc smack, selinux, apparmor
and tomoyo all do not define security_prctl(), which means that the
capability one will be called.
But there's really nothing preventing that situation in the future.
In which case right now we'll cache the error when SET_SECUREBITS
either returns -ENOSYS or returns an error bc of invalid bits.
In any case, an extra check won't hurt. I just felt the need to
double-check my original thinking :)
+ ret = prctl(PR_SET_SECUREBITS, ret | SECBIT_KEEP_CAPS);
+ if (ret == -1) {
+ tst_resm(TFAIL|TERRNO, PR_SET_SECUREBITS
failed\n);
+ tst_exit();
+ }
+#!/bin/sh
+
+echo testing keepcaps
+check_keepcaps 1
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+check_keepcaps 2
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+check_keepcaps 3
+tmp=$?
+if [ $tmp -ne 0 ]; then
+ exit_code=$tmp
+fi
+
+exit $exit_code
What if (for instance) test 1 fails, and tests 2 or 3 pass?
Yeah, I didn't do that right, and maybe it would be best
to just shortcut on the first failure anyway.
That's what I thought. The only thing you lose is coverage potentially
if one of the tests is broken :/.
Yup, which is probably fine - if any one of these breaks, it'll
be a huge deal imo.
-serge
--
Virtualization is moving to the mainstream and overtaking non-virtualized
environment for deploying applications. Does it make network security
easier or more difficult to achieve? Read this whitepaper to separate the
two and get a better understanding.
http://p.sf.net/sfu/hp-phase2-d2d
___
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] ltp_clone alignment issues.
On 04/10/10 15:04 +0200, Carmelo AMOROSO wrote: -clip- Hannu, I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation. Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter. I would just leave the LTP_clone passing the argument to the clone as they came from the caller. Regards, Carmelo Hi Carmelo, you've got point, yes. I was just so worried about the fact that in ARM architectures that previous eg clone02 failed due to alignment errors. But your fix of course fixed that issue, and it gives as a possiblity to make test case against alignment issues, quite right. br, Hannu -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] ltp_clone alignment issues.
On 04/10/10 06:28 -0700, Garrett Cooper wrote: On Mon, Oct 4, 2010 at 6:04 AM, Carmelo AMOROSO carmelo.amor...@st.com wrote: -clip- Hannu, I don't think that it is a good to force the alignment; we could need to write a test case that calls LTP_clone with an unaligned stack just to test the behavior of the clone implementation. Likely, it should be useful to add a check inside the C lib clone implementation (arch specific) to protect against unaligned stack, but this is a different matter. I would just leave the LTP_clone passing the argument to the clone as they came from the caller. I believe this is already handled to some degree with the clone testcases. If not that should be added and I'll review patches which add this testing to LTP. On a semi-unrelated note could you guys please test out the attached patch to make sure that there isn't a functional difference if you have access to ia64, s390, etc? Thanks, -Garrett Hi, Garret, I did git pull and applied your patch, gcc whined about missing CHILD_STACK_SIZE... is it in your some other patch? IFor the time being I added CHILD_STACK_SIZE into test.h, but is it what you wanted initially? I can test clones for arm 32-bit (BeagleBoard/Cortex A8) and AMD64 (Debian 64-bit) environments. Sadly I do not have SPARCs, nor s390... br, Hannu -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
Re: [LTP] ltp_clone alignment issues.
On 04/10/10 06:28 -0700, Garrett Cooper wrote: I believe this is already handled to some degree with the clone testcases. If not that should be added and I'll review patches which add this testing to LTP. On a semi-unrelated note could you guys please test out the attached patch to make sure that there isn't a functional difference if you have access to ia64, s390, etc? Thanks, -Garrett Hi, after that CHILD_STACK_SIZE (def for as it has been 16384) tests passed in AMD64 - Debian 64-bit and BeagleBoard 32-bit ARM (std linux-2.6 with omap3_defconfig). Test files are attached. I ran clones in /opt/ltp/testcases/bin straight. br, Hannu [hannu-debian:~:] uname -a Linux hannu-debian 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux r...@hannu-debian:/opt/ltp/testcases/bin# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ stepping: 1 cpu MHz : 2099.700 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch bogomips: 4199.40 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 107 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4000+ stepping: 1 cpu MHz : 2099.700 cache size : 512 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch bogomips: 4199.99 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc 100mhzsteps r...@hannu-debian:/opt/ltp/testcases/bin# ./clone01 clone01 1 TPASS : clone() returned 7639 r...@hannu-debian:/opt/ltp/testcases/bin# ./clone02 clone02 1 TPASS : Test Passed clone02 2 TPASS : Test Passed r...@hannu-debian:/opt/ltp/testcases/bin# ./clone03 clone03 1 TPASS : Test passed r...@hannu-debian:/opt/ltp/testcases/bin# ./clone04 clone04 1 TPASS : expected failure; Got EINVAL r...@hannu-debian:/opt/ltp/testcases/bin# ./clone05 clone05 1 TPASS : Test Passed r...@hannu-debian:/opt/ltp/testcases/bin# ./clone06 clone06 1 TPASS : Test Passed r...@hannu-debian:/opt/ltp/testcases/bin# ./clone07 clone07 1 TPASS : Use of return() in child did not cause SIGSEGV #1 Test BeagleBoard: r...@beagleboard:/opt/ltp/testcases/bin# uname -a Linux beagleboard 2.6.36-rc4-08510-g0cbe681-dirty #2 Sat Sep 18 12:54:00 EEST 2010 armv7l unknown r...@beagleboard:/opt/ltp/testcases/bin# cat /proc/cpuinfo Processor : ARMv7 Processor rev 3 (v7l) BogoMIPS: 482.11 Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x1 CPU part: 0xc08 CPU revision: 3 Hardware: OMAP3 Beagle Board Revision: 0020 Serial : r...@beagleboard:/opt/ltp/testcases/bin# ./clone01 clone01 1 TPASS : clone() returned 1957 r...@beagleboard:/opt/ltp/testcases/bin# ./clone02 clone02 1 TPASS : Test Passed clone02 2 TPASS : Test Passed r...@beagleboard:/opt/ltp/testcases/bin# ./clone03 clone03 1 TPASS : Test passed r...@beagleboard:/opt/ltp/testcases/bin# ./clone04 clone04 1 TPASS : expected failure; Got EINVAL r...@beagleboard:/opt/ltp/testcases/bin# ./clone05 clone05 1 TPASS : Test Passed r...@beagleboard:/opt/ltp/testcases/bin# ./clone06 clone06 1 TPASS : Test Passed r...@beagleboard:/opt/ltp/testcases/bin# ./clone07 clone07 1 TPASS : Use of return() in child did not cause SIGSEGV -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding.
Re: [LTP] ltp_clone alignment issues.
On Mon, Oct 4, 2010 at 1:00 PM, Hannu Heikkinen hann...@iki.fi wrote: On 04/10/10 06:28 -0700, Garrett Cooper wrote: I believe this is already handled to some degree with the clone testcases. If not that should be added and I'll review patches which add this testing to LTP. On a semi-unrelated note could you guys please test out the attached patch to make sure that there isn't a functional difference if you have access to ia64, s390, etc? Thanks, -Garrett Hi, after that CHILD_STACK_SIZE (def for as it has been 16384) tests passed in AMD64 - Debian 64-bit and BeagleBoard 32-bit ARM (std linux-2.6 with omap3_defconfig). Test files are attached. I ran clones in /opt/ltp/testcases/bin straight. Good catch :). It's always fun making changes when your primary box isn't linux anymore, dealing with VMs in a minor pain, and you miss an important minor detail :/. The point of the proposed change was to remove all duplicate macros from the LTP clone header because I noticed some were defined twice, and over time bitrotted code tends to negatively affect tests in the source base (in particular because someone changes one bit of code and completely ignores/overlooks N-1 other copies of that exact piece of duplicated code -- I've been known to do this by accident as well)... Thanks for testing! -Garrett -- Virtualization is moving to the mainstream and overtaking non-virtualized environment for deploying applications. Does it make network security easier or more difficult to achieve? Read this whitepaper to separate the two and get a better understanding. http://p.sf.net/sfu/hp-phase2-d2d ___ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
[LTP] network-stress tests
Hi, I m running LTP on arm armv7 architechture. I have configured my system acoording to the requiremeints of network-stress testcases as mentioned in README and INSTALL(section 6) files. but still the problem in same ie. LHOST_HWADDRS is not set. :( please tell me why this is happening, is there any way to make them pass? -- Regards, Arjit Sharma. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
