From: mor...@transmeta.com (Andrew Morgan)
Subject: [patch 2.1.97] more capabilities support
Date: 1998/04/19
Message-ID: <199804191017.DAA12937@blighty.transmeta.com>
X-Deja-AN: 345611699
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
Newsgroups: muc.lists.linux-kernel
Linus,
Appended is some more capability code. It:
* heads off the use of cap_t (which is defined in the POSIX.1e draft
as something else) and adds some more infrastructure to
<linux/capabilities.h> and a little code "clean"(?) up.
* adds some proc/<PID>/status lines to display process capabilities
(tested)
* adds some sys_*() calls [i386 unistd.h bindings only] for getting
and setting process capabilities (not yet tested).
FYI: There is some old 'libcap', library code for a user space API for
getting/setting capabilities in a POSIX-like way here:
http://linux.kernel.org/pub/linux/libs/security/linux-privs/capabilities
it was written a while back when we put together some working patches
for 2.0.32 (It contained some experimental ext2 filesystem support for
capabilities...) I will rearrange it to work with the "official"
kernel code.
Anyway, time for bed.
Cheers
Andrew
[PS: Linus, this patch is also in ~morgan/kernel/caps.patch ;^) ]
Patch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: as...@guardian.no (Alexander Kjeldaas)
Subject: Re: [patch 2.1.97] more capabilities support
Date: 1998/04/19
Message-ID: <19980419173829.29209@lucifer.guardian.no>
X-Deja-AN: 345667872
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199804191017.DAA12937@blighty.transmeta.com>
Newsgroups: muc.lists.linux-kernel
On Sun, Apr 19, 1998 at 03:17:54AM -0700, Andrew Morgan wrote:
> + 1.1.2 File capabilities
> +
> + WARNING: there is currently no support for file capabilities
> +
> + Each file has three sets of capabilities, when the file is exec()'d
> + these three capabilities combine with those of the exec()'ing process
> + to establish the newly exec()'d process' capabilities.
> +
> + 1.1.2.1 Inheritable
> +
> + This is a mask against which the Inheritable capabilities of the
> + exec()'ing process are filtered. Only capabilities in this set may be
> + inherited by the exec()'d process.
> +
This is the "allowed" set. [I use this term since it is much clearer
in order to understand what is going on].
> + Note, on filesystems that do not support capabilities, all executables
> + are assumed to have { ~0 } Inheritable capabilities.
No, this is not correct. On file systems without capability support,
files are assumed to have a { 0 } inheritable (allowed) set. We
_could_ do the above, maybe we should, but we don't _do_ this
currently. Some reasons:
* The draft says so :-)
* You get a kind of inverse protection. A file system without
capabilities will grant an executable more capabilities than the
same executable executed from a different file system. This is a
"threat" that will always be there since we live in a world with
lots of other file systems than ext2. I think this collides
somewhat with the principle of least surprise.
* Since we have a CAP_SETPCAP capability (set process' capabilities)
we can implement file-system capability support using a daemon.
* It would arguably be better to have it as a per file system mount
option.
> +
> + 1.1.2.2 Effective
> +
> + This set must have either all capabilities raised or all capabilities
> + lowered. It is used to indicate whether the program knows about
> + capabilities. If this set has capabilities raised, the program will
> + start with all of its Permitted capabilities in its Effective set. If
> + this set is empty, the program will start with an empty Effective set,
> + and will have to explicitly raise the capabilities it needs.
> +
This is a single bit saying whether the executable knows about
capabilities (internally it's represented as a bit mask however).
> + 1.1.2.3 Permitted
> +
> + This set is the set of capabilities required by the executable in
> + order to do its job. These will appear in the Permitted set of the
> + process after exec()ing this executable.
This is the "forced" set. It is also read as { 0 } on a file system
without capabilities support.
> +
> + 1.2 Capability inheritance
> +
> + Following a sys_exec() call, the process' capability sets are modified
> + in the following way:
> +
> + pI' = pI
> + pP' = fP | (fI & pI)
> + pE' = pP' & fE [NB. fE is 0 or ~0]
> +
> + Key: I=Inheritable, P=Permitted, E=Effective // p=process, f=file
> + ' indicates post-exec().
> +
> + Note, the Inheritable set is fully preserved across a sys_exec()
> + call.
> +
> + Process capabilities are _not_ modified on fork (clone).
> +
> + 1.3 Compatibility mode
> +
> + The historical situation, of the superuser being omnipotent, is
> + partially preserved following a system call to sys_exec(). This
..and on set*uid calls.
> + backward compatibility is preserved only in the case that
> + (issecure(SECURE_NOROOT) == 0).
> +
> + 1.3.1 Details
> +
> + Backward compatibility takes the following form:
> +
> + 1 setuid-root binaries, automatically have their Effective
> + and Permitted capabilities raised to equal the Inheritable
> + capabilities of the process that calls sys_exec().
> +
Yes.
> + 2 setuid-NON-root binaries, automatically have their Effective
> + capabilities cleared. If the UID of the process calling
> + sys_exec() is 0, the Permitted capabilities are raised to
> + equal the Inheritable capabilities of the process that called
> + sys_exec(). Such processes become "capability smart".
> +
Yes.
> + 3 non-setuid binaries directly inherit the capabilities of the
> + process that sys_exec()s them.
> +
No! What happens is the following:
1. When the effective uid or real uid of the resulting process is 0
[ execing a suid-root binary, normal exec by root, or
exec by root who has done a setreuid operation ]
then the allowed set is set to { ~0 }.
2. When the effective uid of the resulting process is 0
[ exec of a suid-root binary or normal exec by root ]
then the forced set is set to { ~0 }.
After the above operations, the capability laws described in 1.2 are
used. This means that as long as the allowed set is read as { 0 } from
the file system, we don't inherit any capabilities at all except for
the inheritable ones. We don't need to in order to be backward
compatible.
A very important part of backward compatibility that should be
mentioned is dealing with the set*uid functions. Current software
relies on losing privileges on a setuid or setreuid operation. This
compatibility is in effect if issecure(SECURE_NO_SETUID_FIXUP) ==
0. It works by letting the effective set be a reflection of the
current effective uid. The permitted set is a reflection of the
current effective/real/saved uid. The following rules are used.
1. When set*uiding _from_ one of {r,e,s}uid == 0 _to_ all of
{r,e,s}uid != 0, the permitted and effective capabilities are
cleared.
2. When set*uiding _from_ euid == 0 _to_ euid != 0, the effective
capabilities of the process are cleared.
3. When set*uiding _from_ euid != 0 _to_ euid == 0, the effective
capabilities are set to the permitted capabilities.
4. When setfsuiding _from_ fsuid == 0 _to_ fsuid != 0, the effective
capabilities of the process are filtered for fs-specific capabilities
5. When setfsuiding _from_ fsuid != 0 _to_ fsuid == 0, the fs-specific
parts of the effective capabilities of the process are copied from
the permitted capabilities.
> + 1.3.2 Discussion
> +
> + Firstly, we note that this backward compatibility has only one effect
> + on systems that are not capability aware:
> +
> + Point 2, of section 1.3.1, implies that such binaries
> + inherit the EUID of root, but none of root's kernel level
> + privileges.
> +
No this is not correct. When root runs a non-root setuid program, the
effective uid of the resulting process is _not_ 0. However, the real
uid is 0. Letting the permitted set of the resulting program be set
but not the effective makes perfect sense.
> + Secondly, on a system that runs binaries which are capability aware,
> + without setting SECURE_NOROOT mode, it is possible to further restrict
> + the root account:
> +
> + Point 1, of section 1.3.1, implies that a parent process
> + can reduce its Inheritable capabilities and thus prevent any
> + of its children from _ever_ acquiring all/any of root's kernel
> + level privileges. An immediate consequence of this is that it
> + becomes possible to implement escape proof sys_chroot() cells.
> +
This does not depend on the SECURE_NOROOT setting. The only way you
can increase your effective capabilities beyond your inheritable ones
is if you somehow, through exec or other means, get "forced"
capabilities. "Forced" capabilities can either come from a
capability-aware file system during exec (which we don't have
currently), or from another process having the SETPCAP capability.
[ patch.. ]
> +/*
> + * The restrictions on setting capabilities are specified by POSIX:
> + *
> + * I: any raised capabilities must be a subset of the (old) Permitted
> + * P: permitted capabilities can only be removed and never added.
> + * E: must be set to a subset of (new) Permitted
> + */
I'd like to see an additional restriction. Many programs do privilege
checking at the beginning and don't correctly check all return values
on system calls. On a capability-system this can probably be exploited
in ways not possible on a normal Linux system by using the inheritable
set. If a normally suid program needs several capabilities to perform
a task, you can engineer an inheritable set which will make a system
call fail that would succeed on a normal system and possibly exploit a
buffer overrun condition. On some systems it is therefore desirable to
be unable to _clear_ capabilities in the inheritable set unless you
are privileged. This also has the effect that you cannot selectively
delegate capabilities to your own child processes unless you are
privileged. When raising capabilities in the inheritable set, this
argument doesn't apply since the process would already be "trusted" by
having some forced capabilities.
The above rules should be disregarded for a process having the
CAP_SETPCAP capability. This makes it possible for a
"capability-daemon" to do some interesting things such as raising a
capability only in the effective capability set of a process. This
makes it possible for the daemon to grant a _non-transferable_
capability, something which is not possible with the POSIX rules
(unless you limit setting capabilities in the inheritable set as
well).
Another point is that the system calls in your patch doesn't support
setting capabilities on other processes. This is needed to implement
the "capability-daemon".
astor
--
Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
http://www.guardian.no/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: mor...@transmeta.com (Andrew Morgan)
Subject: Re: [patch 2.1.97] more capabilities support
Date: 1998/04/19
Message-ID: <199804192022.NAA12988@blighty.transmeta.com>
X-Deja-AN: 345738775
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <19980419173829.29209@lucifer.guardian.no>
Newsgroups: muc.lists.linux-kernel
Alexander Kjeldaas writes:
> On Sun, Apr 19, 1998 at 03:17:54AM -0700, Andrew Morgan wrote:
> > + 1.1.2 File capabilities
> > + 1.1.2.1 Inheritable
>
> This is the "allowed" set. [I use this term since it is much clearer
> in order to understand what is going on].
I have just copied the names out of the POSIX draft (section 25.1.1.3).
> > + are assumed to have { ~0 } Inheritable capabilities.
> No, this is not correct. On file systems without capability support,
This was a stupid typo.. I clearly wrote this part of the doc without
thinking. The patch does not enforce what I have documented -- I have
not changed the symantics which continue to do what you say. In this
area, I only cleaned up that code to abstract the form of the
capability sets (this will make it easier to increase the size of the
capability sets without rewriting code).
> * Since we have a CAP_SETPCAP capability (set process' capabilities)
> we can implement file-system capability support using a daemon.
This is a _very_ broken hack! POSIX does _not_ define CAP_SETPCAP for
a good reason. This capability should be removed. With out of bounds
elevation of priorities it is very hard to demonstrate that your
security model has no holes. Without this hack process capabilities
are _only_ set in well defined ways: with a system call from the
to-be-affected process and when a file is exec()'d.
I would strongly urge that this capability is removed.
> * It would arguably be better to have it as a per file system mount
> option.
The compatability stuff seems to require that the filesystem is not
mounted setuid for an exec to "increase" the number of capabilities a
process acquires. Obviously, it makes sense that any filesystem that was
capable of storing capabilities could have these attributes regulated
with a mount option -- much like you can turn suid off.
> > + This set must have either all capabilities raised or all capabilities
> > + lowered. It is used to indicate whether the program knows about
> > + capabilities. If this set has capabilities raised, the program will
> > + start with all of its Permitted capabilities in its Effective set. If
> > + this set is empty, the program will start with an empty Effective set,
> > + and will have to explicitly raise the capabilities it needs.
> > +
>
> This is a single bit saying whether the executable knows about
> capabilities (internally it's represented as a bit mask however).
> This is the "forced" set. It is also read as { 0 } on a file system
> without capabilities support.
Again, this is non-POSIX speak. If you want to use these words it is
fine -- especially if it makes things clearer. I have added them to
my working draft.
> > + 1.3 Compatibility mode
> > +
> > + The historical situation, of the superuser being omnipotent, is
> > + partially preserved following a system call to sys_exec(). This
>
> ..and on set*uid calls.
Whilst this is probably the correct thing to do, this is not yet
implemented in the kernel.
> > + 3 non-setuid binaries directly inherit the capabilities of the
> > + process that sys_exec()s them.
Agreed, this is incorrect, it was late last night... I should say I
wrote all of the text without looking much at the code. Then I went
to work on the code and worked out what it was doing. but, of course,
forgot to fix the documentation.
> > + 1.3.2 Discussion
> > + Firstly, we note that this backward compatibility has only one effect
> > + on systems that are not capability aware:
> > +
> > + Point 2, of section 1.3.1, implies that such binaries
> > + inherit the EUID of root, but none of root's kernel level
> > + privileges.
> > +
>
> No this is not correct. When root runs a non-root setuid program, the
> effective uid of the resulting process is _not_ 0. However, the real
> uid is 0. Letting the permitted set of the resulting program be set
> but not the effective makes perfect sense.
This is actually what I am saying. It is equivalent to what you say
because of the statement that preceeds the paragraph in question. The
important words are "systems that are not capability aware" -- which
means no executables on the system know how to raise permitted
capabilities to become effective capabilities as well as no filesystem
support for capabilities. The point I am trying to make is
that if a process does not have "effective" capabilities then it is
unable to excercise any privileges.
> > + Secondly, on a system that runs binaries which are capability aware,
> > + without setting SECURE_NOROOT mode, it is possible to further restrict
> > + the root account:
> > +
> > + Point 1, of section 1.3.1, implies that a parent process
> > + can reduce its Inheritable capabilities and thus prevent any
> > + of its children from _ever_ acquiring all/any of root's kernel
> > + level privileges. An immediate consequence of this is that it
> > + becomes possible to implement escape proof sys_chroot() cells.
> This does not depend on the SECURE_NOROOT setting. The only way you
> can increase your effective capabilities beyond your inheritable ones
> is if you somehow, through exec or other means, get "forced"
> capabilities. "Forced" capabilities can either come from a
Obviously this text was not clear. On a system without filesystem
support for capabilities, the maximum number of capabilities that a
setuid-root binary can obtain in any way is equal to the "Inheritable"
set of capabilities. This is a feature (I am ignoring the broken
CAP_SETPCAP idea).
It depends critically on SECURE_NOROOT being unset since when it is
set, setuid-root binaries do not get their capabilities automatically
raised. Without filesystem support for capabilities setting
SECURE_NOROOT is a VERY BAD idea ;^)
> capability-aware file system during exec (which we don't have
> currently), or from another process having the SETPCAP capability.
I've already stated that the SETPCAP capability is a broken idea.
[lots of text condensed to the following]:
> Another point is that the system calls in your patch doesn't support
> setting capabilities on other processes. This is needed to implement
> the "capability-daemon".
Again, this is a broken idea. There is no value in having such a
scheme. The whole POSIX model is carefully crafted to avoid the
potential for "holes" of this type. I strongly feel that building
this in, undermines the integrity of the excellent capabilities model.
Best wishes
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: [patch 2.1.97] more capabilities support
Date: 1998/04/19
Message-ID: <Pine.LNX.3.95.980419144052.18616D-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 345757306
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <199804192022.NAA12988@blighty.transmeta.com>
Newsgroups: muc.lists.linux-kernel
On Sun, 19 Apr 1998, Andrew Morgan wrote:
>
> I have just copied the names out of the POSIX draft (section 25.1.1.3).
Without looking into the patch further, I do want to warn you that this is
one fairly certain way to not get things accepted into the kernel.
This is not a POSIX thing or anything like that: I intensely dislike the
notion of "copying from standards". It's a certain way to madness, and I
much prefer if people think a bit first.
For example, the POSIX standard is an API standard. As such, it lists data
structures and functions that the _user_ sees. Anybody who blindly copies
such things into kernel space is just asking for trouble. I ask that
people think about the deeper meaning of things and _not_ necessarily just
copy interfaces.
One good example of this is threading. Yes, I could have sat down with a
spec of POSIX threads, and I could have implemented that interface
directly in the kernel. But the point is that threading really is a
_concept_, and I want to make sure that the kernel gets the _concepts_
right. The API is just an implementation detail of a much larger picture.
With respect to capabilities, I don't ever want to see patches that don't
have the whole picture. And quite frankly, going by past experience, the
POSIX committee has never had a big picture in their life (which is ok:
the POSIX standard wasn't about "getting the big picture", it was
expressly about very small pictures indeed. But it does imply that POSIX
is not a good guide to kernel internals).
Also Morgan, you mentioned that you want to get rid of the capability to
set capabilities because you worry that it is a security risk. Sorry, but
that's the kind of prison mentality that I refuse to have in the kernel.
In my very strong opinion, the kernel should _allow_ things, and never
restrict things.
As such, we should _allow_ the capability to raise other capabilities. If
you don't like that capability, you can just make sure that it is cleared
at boot for everybody, and then nobody can inherit it and nobody can ever
get it any other way either (as nobody has the capability to raise the
capability).
The whole UNIX philosophy is to give the user a powerful tool. Yes, giving
people such a tool does imply that people can hurt themselves. But I'd
still prefer to be given the choice, instead of getting the "yes, dear,
these are the safe and approved interfaces, and if you don't like them,
tough, you're stuck with them" mentality.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: [patch 2.1.97] more capabilities support
Date: 1998/04/19
Message-ID: <Pine.LNX.3.95.980419145708.19065A-100000@penguin.transmeta.com>#1/1
X-Deja-AN: 345770976
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980419144052.18616D-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
On Sun, 19 Apr 1998, Linus Torvalds wrote:
>
> Without looking into the patch further, I do want to warn you that this is
> one fairly certain way to not get things accepted into the kernel.
[ Side note: having looked at the patch, the patch itself looks fine. It's
just the discussion you two had that made me nervous ]
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: mor...@transmeta.com (Andrew Morgan)
Subject: Re: [patch 2.1.97] more capabilities support
Date: 1998/04/19
Message-ID: <199804192250.PAA30749@blighty.transmeta.com>#1/1
X-Deja-AN: 345775100
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980419144052.18616D-100000@penguin.transmeta.com>
Newsgroups: muc.lists.linux-kernel
Linus Torvalds writes:
> Also Morgan, you mentioned that you want to get rid of the capability to
> set capabilities because you worry that it is a security risk. Sorry, but
> that's the kind of prison mentality that I refuse to have in the kernel.
> In my very strong opinion, the kernel should _allow_ things, and never
> restrict things.
Having read the POSIX.1e draft I can say you are also correct in so
far as it is mostly a mess! :^)
However, the capability part of the draft is IMHO extremely well
thought out.
They decide on a need for file attributes to specify the capabilities
that a program can acquire as this is the most straightforward way for
the sysadmin(s) to keep control of the system: in general, the model
assumes that the security/reliability of "trusted" filesystems is
guaranteed.
My problem with things like CAP_SETPCAP is that it is ill defined: it
places a large hole in the security model of the kernel and leaves it
up to a user application to fill. I can see that in your language,
this can also be read as "open to a world of possibility..." :^)
Currently, the software security perimeter of the Linux kernel is the
system call API. Adding CAP_SETPCAP for the express purpose of giving
arbitrary capability control to a user space daemon seems like a
really dramatic change.
Perhaps it is just semantics, but this sort of ability seems to be
much more appropriate to a "security module" than a user-space daemon.
> As such, we should _allow_ the capability to raise other capabilities. If
> you don't like that capability, you can just make sure that it is cleared
> at boot for everybody, and then nobody can inherit it and nobody can ever
> get it any other way either (as nobody has the capability to raise the
> capability).
By definition, your opinion is the one that counts.
I guess if I have to concede on this can I suggest that, at the very
least, this should be a global is_secure(ALLOW_SETPCAP) condition?
Otherwise, the "nobody can inherit it" part is only good as long as
there is no executable sitting on a trusted filesystem that has this
Permitted (Forced) bit raised. (Some protection against the equivalent
of the current "setuid-root shell" that people like to have lying
around... :^)
Cheers
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: andr...@luz.fe.uni-lj.si (Andrej Presern)
Subject: Re: [patch 2.1.97] more capabilities support
Date: 1998/04/21
Message-ID: <353C7192.44E6F6C1@luz.fe.uni-lj.si>
X-Deja-AN: 346267078
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980419144052.18616D-100000@penguin.transmeta.com>
Organization: Capable Systems & Technologies
Newsgroups: muc.lists.linux-kernel
Linus Torvalds wrote:
>
> On Sun, 19 Apr 1998, Andrew Morgan wrote:
> >
> > I have just copied the names out of the POSIX draft (section 25.1.1.3).
>
> Without looking into the patch further, I do want to warn you that this is
> one fairly certain way to not get things accepted into the kernel.
>
> This is not a POSIX thing or anything like that: I intensely dislike the
> notion of "copying from standards". It's a certain way to madness, and I
> much prefer if people think a bit first.
>
> For example, the POSIX standard is an API standard. As such, it lists data
> structures and functions that the _user_ sees. Anybody who blindly copies
> such things into kernel space is just asking for trouble. I ask that
> people think about the deeper meaning of things and _not_ necessarily just
> copy interfaces.
>
> One good example of this is threading. Yes, I could have sat down with a
> spec of POSIX threads, and I could have implemented that interface
> directly in the kernel. But the point is that threading really is a
> _concept_, and I want to make sure that the kernel gets the _concepts_
> right. The API is just an implementation detail of a much larger picture.
It is intresting what you say here. I have tried to explain a concept
much securer than what is being presented here to some people, but have
failed in doing so because of being unable to provide the complete
implementation details due to my lack of Linux internals knowledge.
If you are interested, I would very much like to explain it again to
you.
> With respect to capabilities, I don't ever want to see patches that don't
> have the whole picture. And quite frankly, going by past experience, the
> POSIX committee has never had a big picture in their life (which is ok:
> the POSIX standard wasn't about "getting the big picture", it was
> expressly about very small pictures indeed. But it does imply that POSIX
> is not a good guide to kernel internals).
>
> Also Morgan, you mentioned that you want to get rid of the capability to
> set capabilities because you worry that it is a security risk. Sorry, but
> that's the kind of prison mentality that I refuse to have in the kernel.
> In my very strong opinion, the kernel should _allow_ things, and never
> restrict things.
The model that I tried to present does not even have a notion of
denying, it only has a notion of allowing. That is, there are no "you
can't do that" responses (because that itself is a leak of information -
the program can try different privileged operations to determine the
power that it has, which is a bad thing if, for example, the program was
modified by the attacker and the attacker does not know the actual
authority of the program).
> As such, we should _allow_ the capability to raise other capabilities. If
> you don't like that capability, you can just make sure that it is cleared
> at boot for everybody, and then nobody can inherit it and nobody can ever
> get it any other way either (as nobody has the capability to raise the
> capability).
>
> The whole UNIX philosophy is to give the user a powerful tool. Yes, giving
> people such a tool does imply that people can hurt themselves. But I'd
> still prefer to be given the choice, instead of getting the "yes, dear,
> these are the safe and approved interfaces, and if you don't like them,
> tough, you're stuck with them" mentality.
Don't give authority to people, give it to objects in the system. A
person doesn't have to be able to perform an action on /etc/passwd, a
system object does! (ie it's not really the person who accesses a file,
the program is, so you should control the program, not the person ->
separate authority from identity)
Also, programs should not be able to hurt other objects without explicit
permission to do that. The person who makes the program decides what the
program should be able to do, so the program should only have as little
authority as absolutely necessary to perform the action that a person
designed it to do. Any more authority than that is a risk, because it
can be abused by people who want the program to also do things that the
program _wasn't_ designed to do (ie, a weapon is a tool with superfluous
power that can be abused to hurt people).
It's never the interface that is the main issue because it can be made
one way or another. It's the concept that is behind the interface that
matters.
I hope any of what I stated above will at least be considered before
concepts that have _proven_ to be wrong are implemented in the kernel.
In the last 30 years, a lot was learned about information security. I
hope its time that some of that knowledge is actually used in mainstream
operating systems.
Andrej
--
Andrej Presern, andr...@luz.fe.uni-lj.si
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu
From: torva...@transmeta.com (Linus Torvalds)
Subject: Re: [patch 2.1.97] more capabilities support
Date: 1998/04/21
Message-ID: <6hildc$66p$1@palladium.transmeta.com>#1/1
X-Deja-AN: 346363972
Approved: g...@greenie.muc.de
Sender: muc.de!l-linux-kernel-owner
References: <Pine.LNX.3.95.980419144052.18616D-100000@penguin.transmeta.com>
Organization: Transmeta Corporation, Santa Clara, CA
Newsgroups: muc.lists.linux-kernel
In article <353C7192.44E6F...@luz.fe.uni-lj.si>,
Andrej Presern <andr...@luz.fe.uni-lj.si> wrote:
>
>It is intresting what you say here. I have tried to explain a concept
>much securer than what is being presented here to some people, but have
>failed in doing so because of being unable to provide the complete
>implementation details due to my lack of Linux internals knowledge.
>
>If you are interested, I would very much like to explain it again to
>you.
This concept was using segments to give very low-level access rights on
a per-object basis?
I think I saw it, and never looked closer for a few reasons:
- segments do not exist on anything but a i386+ (even i286- "segments"
are just abominations, and have nothing to do with real segments) in
any popular hardware.
- even where they exist, they are slow.
- protection that finegrained is theoretically nice, but a maintenance
nightmare. In theory it is the best kind of protection, in practice
you won't find anybody who will program a non-trivial program using
them correctly and securely (I claim that even ACL's have this
problem, and ACL's are much simpler)
I personally do not believe in object orientation as a security model
(nor as a general programming paradigm), but feel free to try to
convince me.
[ Or maybe I confuse you with somebody else and some other posting ]
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.rutgers.edu