This is an updated request for comments on a proposed integrity
service framework and dummy provider, along with SLIM, a low
water-mark mandatory access control LSM module which utilizes the
integrity services as additional input to the access control decisions.
In this version:
- We have further slimmed down the code by removing the secrecy checks
to focus on only the integrity model at this time. The secrecy code had
several parts that were still in development and only had comments
indicating where they would eventually be and the policy was only using
one secrecy level. Hopefully, this will remove an element of review
confusion
- The file revocation code was removed in favor of denying access when a
process has open shared file descriptors b/c file revocation has too
many corner cases.
- Fixed the situation where shared physical memory could cause a problem
if one thread was demoted. Currently access is denied in the situation
we are working on a way to allow the access and demote all the threads.
- SLIM boot parameter
- INTEGRITY config parameter (which SLIM depends on)
Where we are going:
- dummy integrity subsystem (included)
- integrity-only slim (included)
- secrecy slim
- tcg-based integrity subsystem
Later we will be submitting EVM as a specific integrity service
provider under this proposed framework. By separating the submissions,
we hope that the integrity framework and its relationship to SLIM
(and potentially to selinux) will be clearer and easier to review.
Since this integrity provider is a dummy, it has no requirements for
TPM hardware, or for LSM stacking, again making the review simpler.
A corresponding userspace utility package is available at
http://www.research.ibm.com/gsal/tcpa
Patch 1/7 is a tiny patch to make mprotect available for revocation.
Patch 2/7 provides the integrity service API with dummy provider.
Patch 3-7 provide SLIM, and a more detailed description of
its changes, and points out its use of the integrity service.
These patches have no prerequisites for stacker or TPM related patches.
On Tue, 12 Sep 2006 10:57:25 -0700
Kylene Jo Hall <[email protected]> wrote:
> This is an updated request for comments on a proposed integrity
> service framework and dummy provider, along with SLIM, a low
> water-mark mandatory access control LSM module which utilizes the
> integrity services as additional input to the access control decisions.
Having carefully reviewed your code I have come to the firm conclusion that
it is written in C. The next step is to put it all in -mm and see if
anyone shouts at me.
I'll need help on the upstream-merge decision.
A convincing statement of interest (or, better, intent) from vendors (ie:
the people who will deliver and support this into the target users) would
help a lot. Where do we stand with that?
Thanks.
On Thu 2006-09-14 16:51:13, Andrew Morton wrote:
> On Tue, 12 Sep 2006 10:57:25 -0700
> Kylene Jo Hall <[email protected]> wrote:
>
> > This is an updated request for comments on a proposed integrity
> > service framework and dummy provider, along with SLIM, a low
> > water-mark mandatory access control LSM module which utilizes the
> > integrity services as additional input to the access control decisions.
>
> Having carefully reviewed your code I have come to the firm conclusion that
> it is written in C. The next step is to put it all in -mm and see if
> anyone shouts at me.
Hmmm, "it is written in C" does not seem like good enough reason to
merge it... right?
I tried to understand what it is good for, but it seems that in
current state it is not much good for anything.
Will IBM work at splitting ssh so that trusted/untrusted portions are
separated?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, 2006-09-19 at 21:02 +0200, Pavel Machek wrote:
> On Thu 2006-09-14 16:51:13, Andrew Morton wrote:
> >
> > Having carefully reviewed your code I have come to the firm conclusion that
> > it is written in C. The next step is to put it all in -mm and see if
> > anyone shouts at me.
>
> Hmmm, "it is written in C" does not seem like good enough reason to
> merge it... right?
He did go on to say:
>> I'll need help on the upstream-merge decision.
>>
>> A convincing statement of interest (or, better, intent) from vendors
>> ie: the people who will deliver and support this into the target
>> users) would help a lot. Where do we stand with that?
which makes it clear that we also have to show value, interest, and
support. (And, yes, we are working on showing that...)
> I tried to understand what it is good for, but it seems that in
> current state it is not much good for anything.
Part of the problem is that this patch set is just one small part
of the overall architecture, which includes an additional kernel
module to implement the integrity service used by SLIM, and user
space libraries and tools to implement/manage the trusted boot,
integrity mandatory access control, and secure authentication features.
We were asked to submit this in small pieces to make the review easier,
and what you see so far is just the first piece, with the others
coming shortly.
We deeply appreciate all the review and comments that happened
along the path of getting into -mm. It has made the code much better,
and makes it easier to work with our partners to start to show long
term interest and support.
>
> Will IBM work at splitting ssh so that trusted/untrusted portions are
> separated?
The trousers project at sourceforge already has provided TPM support
for openSSL, and ssh uses the openSSL crypto library - I'm not sure
if this directly translates to TPM support for ssh, but that's
certainly something we want to enable, and I'll check into it.
dave