On Sat, 14 Apr 2001, Chris Wright wrote: > * Philippe Biondi (philippe.biondi@enst-bretagne.fr) wrote: > > Let's put the problem in place : we have the (veryveryvery) generic > > scheme: > > | > > | +---------+ > > | | Decider | > > | +---------+ > > | ^ > > | | (1) > > | V > > | +-------+ > > user space | +--| hooks |---+ > > | | +-------+ | > > App ----+-->| Syscall code | > > | +--------------+ > > > > The question is : what is the arrow (1) ? In other words what is the > > semantic behind such calls to the decider ? > > > > Your approach was to say that the decider had to answer to : > > "Can 'current' exec <syscall> with <parameters>" > > I'll prefer > > "Can 'current' do <type-of-action> with <object(s)>" > > even if it seems very MAC-oriented > > No, I think we are misunderstanding each other. I was opposing raw calls to the decider to "interpreted" calls to the decider. "Interpreted" means that some information have been processed. > I am strictly _not_ > interested in watching just syscalls. In fact, I believe only a few > syscalls will need the hooks. The fact remains that syscalls are the > user applications' interface to the kernel. We are tyring to protect > kernel objects (in my mind). Therefore, the syscall interface is a good > place to start looking at what a user app can acutally do to a kernel > object. For example, some kernel objects contain linked lists that are > used only internally. I don't think we care about protecting this kind > of kernel object data (if the user app can't change it). > > I am trying to look at the handful of kernel objects and ask "what can a > user app do to that object that we need to protect?" I think we have the > same goals. I wrote "syscall code" having in mind each piece of code executed by a syscall, or by a function called by a syscall, or by a function called by a function called by a syscall, or ... This should be in fact each piece of code which can be executed in user context (when "current" has a meaning). > It sounds to me like you are suggesting one function, something like: > > is_this_legal(action, credientials, additional data...) > > While this is a nice way to look at it, I don't think we'll be able to > implement it that way. There are so many different types of actions > that need different types of additional data. It is always possible. The question is : is it nice enough to be worth implementing ? -- Philippe Biondi Systems administrator Webmotion Inc. http://www.webmotion.com mailto:philippe.biondiat_private Fax. (613) 260-9545 _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Mon Apr 16 2001 - 07:34:02 PDT