Re: Feature request for 1.2 (or for 2.0)

From: janos.milus@dataware.debis.hu
Subject: Re: Feature request for 1.2 (or for 2.0)
Date: Thu, 29 Mar 2001 12:28:38 +0200

Next Article (by Subject): Re: Feature request for 1.2 (or for 2.0) Amon Ott
Previous Article (by Subject): Re: Feature request for 1.2 (or for 2.0) 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) Amon Ott
Articles sorted by: [Date] [Author] [Subject]

At first I appologise for that I didn't use the archivum before I ask.

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.

>   - 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.

> - No internal kernel variables are ever changed by decision, except
return
> values.

Agree. It is really a 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.

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.

Regards
Janos Milus


-
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.