--- On Wed, 1/28/09, CAI Qian <[email protected]> wrote:
> From: CAI Qian <[email protected]>
> Subject: Re: [LTP] [PATCH] proc01: SELinux with attr/* Interface - version 2
> To: "Serge E. Hallyn" <[email protected]>
> Cc: [email protected], [email protected], [email protected]
> Date: Wednesday, January 28, 2009, 11:25 PM
> 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.
>
Here is the link for the email from Stephen Smalley that I was refer
to,
http://article.gmane.org/gmane.linux.ltp/7324
> CAI Qian
>
> > If that is not a situation we care about, then we
> should
> > simply
> > ignore the files if selinux is disabled. If selinux
> is
> > enabled,
> > the user can run the selinux testsuite and it can test
> for
> > proper
> > return values.
> >
> > -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
------------------------------------------------------------------------------
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
