Serge, Are you considering to submit something on this :-)
Regards-- Subrata On Tue, 2008-11-11 at 16:00 -0600, Serge E. Hallyn wrote: > Some time ago, someone (probably Subrata :) asked whether there > were any testcases for the securebits functionality. > > Nope, I haven't yet had time to write them :) What I did do in > the last few minutes was write up what I think should be tested. > There is some chance I'll have time to write these in December, > but I'm hoping someone will find themselves bored and looking for > something to do. Well look no further! > > Note: this doesn't test every possible combination (i.e. every > combination of old_resuid and new_resuid. It's intended mainly > to make sure there are no major unintended regressions when > subtle code changes are applied. (Which they are) > > Note2: wherever i say SECURE_NOSETUID, I really mean > SECURE_NOSETUID_FIXUP. I'd change it, but it's really too long > to fit in these columns that way anyway. > > Keepcaps feature: > Description: keepcaps means that a task can keep > its capabilities despite doing a setuid to non-root > userid It can be set using either the older > prctl(PR_SET_KEEPCAPS), or the newer > prctl(PR_SET_SECUREBITS, 1 << SECURE_KEEP_CAPS). > > The bit can be 'locked' on using > prctl(PR_SET_SECUREBITS, 1 << SECURE_KEEP_CAPS_LOCKED). > > Keepcaps tests: > 1. drop capabilities at setuid if KEEPCAPS is not set and > new user is nonroot > 2. keep capabilities if set and new user is nonroot > 3. SECURE_KEEP_CAPS_LOCKED (which is set using > prctl(PR_SET_SECUREBITS, SECURE_KEEP_CAPS_LOCKED) > does the right thing. > 4. re-test with prctl(PR_SET_SECUREBITS, SECURE_KEEP_CAPS) > > Securebits feature: > Description: If you look at the POSIX capability equations, > you see that on a system with no file capabilities - which > Linux was for a long time - a root user cannot get privilege. > Executing any file will clear out his capability sets. The > securebits offer a way around this. When SECURE_NOROOT is > unset, then capability sets are filled and clear at execve > based on the task and file effective userids. When > SECURE_NOSETUID is unset, then the capability sets are > filled and cleared at the setuid system call. When the > SECURE_NOSETUID_LOCKED and/or SECURE_NOROOT_LOCKED bits > are set, then the cooresponding bits can no longer be > unset. > > Securebits tests: > [bit setting behavior] > 1. can't set SECURE_NOROOT or SECURE_NOSETUID if not > capable(CAP_SETPCAP) > 2. SECURE_NOROOT and SECURE_NOSETUID (in all combinations) > are inherited at fork. > 3. can't unset SECURE_NOROOT if SECURE_NOROOT_LOCKED is set > 4. can't unset SECURE_NOSETUID if SECURE_NOSETUID_LOCKED is set > 5. can unset SECURE_NOROOT or SECURE_NOSETUID if _LOCKED is not set > > (in all of the following, no file capabilities should be on > the executable files, and I ignore pI as it is not affected) > > [secure_noroot behavior] > 1. nonroot executes setuid-root file: > a. if SECURE_NOROOT is set, resulting task has no capabilities > b. if SECURE_NOROOT is unset, resulting task has pP' and pE' filled. > 2. root executes setuid-nonroot file: > a. if SECURE_NOROOT is set, resulting task gets empty pP' and pE' > b. if SECURE_NOROOT is unset, resulting task has pP' filled, pE' > empty > 3. root executes root-owned file: > a. if SECURE_NOROOT is set, resulting task gets empty pP' and pE' > b. if SECURE_NOROOT is unset, resulting task has pP' and pE' filled. > > [secure_nosetuid behavior] > [[note, i am not listing tests for setfsuid "yet"]] > 1. root user calls setuid(500). > a. if SECURE_NOSETUID is set, resulting task keeps its pP and pE > b. if SECURE_NOSETUID is unset, resulting task has pP and pE cleared > 2. root user calls setresuid(-1,500,-1) > a. if SECURE_NOSETUID is set, pE is not cleared > b. if SECURE_NOSETUID is unset, pE is cleared > 3. (continuing from 2) now the same task calls setresuid(-1,0,-1) > a. if SECURE_NOSETUID is set, pE is not changed > b. if SECURE_NOSETUID is unset, pE is filled with pP. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Ltp-list mailing list > Ltp-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ltp-list ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
