Re: Feature request for 1.2 (or for 2.0)

From: Amon Ott <ao@rsbac.org>
Subject: Re: Feature request for 1.2 (or for 2.0)
Date: Thu, 29 Mar 2001 14:33:21 +0200

Next Article (by Author): Re: About setreuid() and setresuid() Amon Ott
Previous Article (by Author): Re: About setreuid() and setresuid() Amon Ott
Top of Thread: Feature request for 1.2 (or for 2.0) janos.milus@dataware.debis.hu
Next in Thread: Re: Feature request for 1.2 (or for 2.0) janos.milus@dataware.debis.hu
Articles sorted by: [Date] [Author] [Subject]

On Don, 29 Mär 2001 janos.milus@dataware.debis.hu wrote:
> At first I appologise for that I didn't use the archivum before I ask.

Please don't. It was just to tell you that I am aware of the problem.

> Second, I disagree some point of your answer. I try to explain:
> 
> > - All modules are independent:
> >   - Once you change the target, when will what module decide about which
> > target? This could be solved by changing the target after a full run and
> then
> > rerun the decision.
> 
> As you wrote, it could be solved.

It is even a bit more complicated: If access is to be redirected, the original
target will not be touched at all. What do we do, if another module denies
access to this file - do we just take the second (rerun) result, or deny access?

Taking the last result only is probably the best way.

> >   - How do we handle conflicts: One module wants this replacement,
> another
> > that. Which one is chosen? How is the unused replacement data cleaned up
> and
> > notified to its module?
> 
> I think it is not a real problem: building a secure or a "trusted" linux is
> not
> stupid user's task. Of course, you must document, that if there is more
> than one
> "redirect" decision module in the kernel and there are conflicts between
> them,
> the result is undefined.

Well... I try to keep things simple. Just remember when you first tried to use
RSBAC, how did you feel?

> > - No internal kernel variables are ever changed by decision, except
> return
> > values.
> 
> Agree. It is really a problem.

It is my biggest problem.

> > - All programs should work without changes. What if a program writes to
> > /etc/passwd and another one has to read this info?
> 
> All programs should work without changes: that's why we need redirect. The
> most of the
> unix programmers develop their programs for the standard unix enviroment.
> They open files,
> devices, etc. without knowing (or without care) what happens with the
> program MAC level or
> MAC category etc. You have to rewrite the original program or "simulate"
> the enviroment with
> redirection (if you want to use it). The second is much more easier (and
> sometimes, when you
> have no source, the only possibilities).
> 
> Answering your question: if 2 or more programs use the same file (for
> communication), the
> security officer (and the system administrator) responsible for they see
> the same file.
> Again, building a secure enviroment is not a stupid users' task.

Yes, in the end the admins will have to get things right. I will send them over
to you then ;)

> Of course, I can accept (and I understand) that if you say "No". It is your
> program, you rule
> what is in the roadmap and what is not. I feel thankfulness even I'm
> allowed to use it.

I do not like the dictatorship principle. If you say you really need
redirection, it will be included. We can add it as an option, but I would like
to have it off as default.

Adding redirection would need a decision function interface change, and thus a
new REG version. Also, the adf_request interface and all file/dir/fifo
interceptions will have to be changed. Bugs in the interception or in the
dentry exchange can then lead to huge problems, so we must be very careful.
Really not a minor release change, so it will take some time.

Amon.
-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Go to Compuniverse LWGate Home Page.