Quoting CAI Qian ([email protected]): > Hi, > > > --- On Wed, 1/28/09, Serge E. Hallyn <[email protected]> wrote: > > > From: Serge E. Hallyn <[email protected]> > > Subject: Re: [LTP] [PATCH] proc01: SELinux with attr/* Interface - version 2 > > To: "CAI Qian" <[email protected]> > > Cc: "Kamalesh Babulal" <[email protected]>, > > [email protected], [email protected], [email protected], > > [email protected] > > Date: Wednesday, January 28, 2009, 11:50 PM > > Quoting CAI Qian ([email protected]): > > > Hi, > > > > > > > > > --- On Wed, 1/28/09, Serge E. Hallyn > > <[email protected]> wrote: > > > > > > > From: Serge E. Hallyn <[email protected]> > > > > Subject: Re: [LTP] [PATCH] proc01: SELinux with > > attr/* Interface - version 2 > > > > To: "CAI Qian" <[email protected]> > > > > Cc: "Kamalesh Babulal" > > <[email protected]>, [email protected], > > [email protected], [email protected], > > [email protected] > > > > Date: Wednesday, January 28, 2009, 10:57 PM > > > > Quoting CAI Qian ([email protected]): > > > > > Kamalesh Babulal, well, my approach is that > > anyone who > > > > cares about > > > > > AppArmor can add a list of files should work > > to the > > > > code. it is fair that if different LSMs behave > > differently, > > > > we'll need different lists > > > > > (selinux_should_work and > > apparmor_should_work) to deal > > > > with them. > > > > > > > > > > > To make it > > > > > > generic can we > > > > > > just skip reading the list of files, if > > they > > > > return EINVAL > > > > > > or else we > > > > > > have to support checking of different > > LSM's > > > > and add > > > > > > support for each of > > > > > > them individually. > > > > > > > > > > > > > > > > Yes, but then you will still need to treat > > different > > > > LSMs differently. > > > > > > > > > > > Agree that the coverage of the > > testcase is going > > > > to be > > > > > > reduced. It will be > > > > > > reduced more because the list which we > > are taking > > > > care is > > > > > > incomplete, > > > > > > > > > > Which ones are missing -- should return > > EINVAL with > > > > SELinux > > > > > disabled? > > > > > > > > > > > we could need to add other files to the > > list like > > > > nfs to be > > > > > > skipped. > > > > > > Sending another patch which will ignore > > the file > > > > if it > > > > > > returns EINVAL or else > > > > > > throw warning. > > > > > > > > > > This patch won't able to catch attr/* > > entries > > > > return > > > > > EINVAL while SELinux is enabled. It does not > > look like > > > > a good > > > > > approach to me, because it is a test > > coverage > > > > regression. > > > > > > > > > > CAI Qian > > > > > > > > So, just to try and think through this... If no > > LSM is > > > > enabled, > > > > the files should return -EINVAL. If they > > don't return > > > > -EINVAL, > > > > is that a situation we care about? What would it > > mean? > > > > > > > > > > Yes, Stephen Smalley from National Security Agency of > > U.S. told it > > > means "security modules (e.g. capability) > > don't support any of those > > > interfaces", so if another errno is returned, it > > should be brought up > > > to attention. > > > > Obviously the correct behavior depends upon the security > > subsystem, > > but you're finagling the checks into fs-specific > > checks. > > > > It seems to me that if you're going to check for > > correct return > > values from these functions, you should do so under > > testcases/kernel/security. > > Well, it is fine to put some of those checks under another separate > test, but it looks to me that it is probably easier and simpler here > to consider those two tightly coupled component all together in this > case. Because the test should not simple blindly skip those entries > due to the reasons I have stated before, and people may run this test > with SELinux on/off or AppArmor on/off (not consider other Linux > security modules) as those are all valid test environment setup, we'll > then have 3 different unique conditions: > > 1. SELinux on (attr/* read successfuly) > 2. AppArmor on (???) > 3. SELinux off and AppArmor off (attr/* read with -EINVAL) 4. TOMOYO on 5. Smack on ...
> As the result, the above checking code will need to be present in both > proc01 and a new test. Then please stick to the simple suggestion from Stephen, keeping any selinux- (or any other lsm-)specific code out of proc01.c. Which may be what you're suggesting :) -serge ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
