Re: Secure-linux and standard kernel

Vadim E. Kogan (vadim@vadim.gem.net)
Sat, 27 Jun 1998 12:26:25 -0700

Andrej Presern wrote:
> * Don't put authority (that a capability conveys) in the binary and
> don't trust processes to not use the authority that they are given. You
> want security because you don't want to trust in the first place. Giving
> a process the whole authority and hoping that it will drop what it
> doesn't need is like giving your housekeeper the key to the safe and
> hoping that she'll only clean the house, and not also steal the money in
> the safe (and while the housekeeper may be fair and honest and trustable
> and all, someone else who could enter the house with her may not).
agree
>
> * There have been some thoughts that the information about authority
> that the program has should be as easily obtainable as possible. If
> security is at stake, programs should _not_ by default be able to
> determine their true authority because that makes operation of troyan
> binaries easy (check if you have enough authority; exploit if you do,
> don't do anything to arouse suspicion if you don't). Obtaining the
> information itself should be a capability that can selectively be given
> to or revoked from individual objects.
Yes, but in secure world you don't care as you know who is responsible
and nobody can break everything from one program, as no program has all
power. I personally prefer not only limit "what you can", but also "what
you see". And it seems absolutely correct to me that you don't see files
in the dir if you don't have per-file rights to see them. But some argue
that it isn't helping security. I say, that it isn't helping security a
lot, but it does help a little bit. And it's a good method to use to
protect yourself from some idiots, who will try to crack your system.

> * (as Vadim E. Kogan already pointed out) From security point of view,
> all objects in the system are equal: they all have some rights that they
> can excercise (but no other), even though those rights can differ
> greatly. This diversity is one of the reasons why capability lists won't
> cut it, and it doesn't matter if the list is now 64 (I think the
> original proposal was 32) bits long - in time, this list will only grow
> longer and the system will become less efficient and more complex (mind
> you that complexity and security don't go along very well).
Well, here I can say that with right a approach it can still be
efficient and powerfull at the same time, where powerfull is to allow
complex configurations. Simplicity can be archieved via reasonable
defaults, which can be tuned in one place. For real security these
defaults should be "no rights" at all, which will make admin/user give
all rights he wants to give in a separate "order". And to do this you
have to know exactly what you need and how the system works, plus it
takes some time. I guess that's what makes people be afraid of "complex"
:)
>
> * You can't make a (good security) pie without breaking the (POSIX)
> eggs..
Agree. And in a perfect system, user defines not only permissions, but
also rules to use these permissions. But this is not me or other people
I know want. And this kind of system will be inefficient for practical
purposes. So we're stuck with more simple and less general solutions,
but POSIX seems to be too simple and too "specific" or "non-abstract".

>
> Andrej
>
> --
> Andrej Presern, andrejp@luz.fe.uni-lj.si
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu

Vadim

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu