Gregory Maxwell wrote:
> On Sun, 25 Jun 2000, David Ford wrote:
>
> > Gregory Maxwell wrote:
> >
> > > I don't understand what the purpose of having a user_immutable. Immutable
> > > was put in as some kind of fix for morons who can't comprehend the -f flag
> > > and it's consiquences. It's there as part of a system lockdown function.
> >
> > Not all morons are created equal. Some can spell. Your argument immediately loses
> > it's value when you lower yourself. If you worked in a security profession, you
> > would understand the value of layered access.
>
> I agree that my spelling is not always up to par and I seldom care or
> remember to run a spell check on my postings. However, that issue has no
> bearing on the current discussion. The fact that some may see that as an
> indicator of my level of knowledge is even more immaterial considering
> that you clearly demonstrate that you have absolutely *NO* understanding
> of the current Linux-kernel security model.
I didn't say "your spelling", I said some morons can spell implying that moron is a rude
and inappropriate term to apply to anyone.
Yes, I do understand quite a bit more than you want to acknowledge. Please keep your
'moron' comments about people elsewhere.
> > Sorry, I use it extensively for myself and clients. It is a very valuable security
> > option.
>
> Netbios is widely used on Windows networks. It has several advantages, the
> most obvious being ease of configuration. However, that has no bearing on
> the technical 'goodness' of the protocol. Netbios is a steaming piece of
> crap technology wise, it over-uses broadcasts and gets almost everything
> wrong. I am not aware of anyone who from a technical perspective would
> look at Netbios and say "Now, that is a good solution".
>
> Similarly, strange file attributes can be useful and there are people
> who want them. That fact alone can not make them a good solution.
These are not strange file attributes, they have a long history and we are not adding
them. This discussion is about the removal.
> "Add features until it breaks" is *not* the Unix philosophy. It's much
> more intelligent to design a solution framework which encompasses all of the
> common cases while not completely excluding the uncommon ones. Good
> technology has architecture.
A securelevel (or concept thereof) is implemented in numerous forms of UNIX. This
particular immutable/append-only bit usage has preserved evidence in situation after
situation, accidental or by wrong doing. These flags exist and have existed for a long
time in BSD and Linux. Normal users as well as root are accustomed to having these flags
available.
> > As I brought up in an earlier email, virtual sites have a -user- managing them, they
> > don't have root priviledges and won't get them. They should however have the
> > resources at hand to prevent their users' scripts or whatnot underneath them from
> > harming their data.
>
> Chmod o-w file. If thats not enough then the scripts are broken. If you
> implement widespread user-immutable then the same scripts that are
> ignoring the w bit will learn to ignore user-immutable.. Then
> what? User-immutable-immutable?
In a perfect world we would have perfect scripts with perfect admins and no malcontents.
Normal script usage would be great if all perl scripts and whatnot perfectly sanitized
input and operations. Unfortunately some live to make our lives more exciting. The
scripts are not ignoring 'w' bits and 'w' is worthless if the directory is owned by the
user doing the operation.
Without an immutable bit, nothing prevents a buffer overflow exploit with shell access
from doing considerable damage. By having an immutable cap, important files can be
protected, and logs cannot be truncated.
The idea Viro presented is excellent and trivial.
> > Linux supports root or !root users. Linux doesn't have varying
> > levels of access. Group permissions again is not sufficient for varying levels of
> > access.
>
> This is completely untrue and demonstrates beyond any doubt why you have
> no business taking part in this discussion.
We are talking about filesystem attributes. Please explain to us how a login UID 0
person can be prevented from deleting files in directory A while allowing deletion in
directory B. Capabilities don't exist in a filesystem access layer. There is nowhere on
an inode that we have the ability to say uid0 is or isn't allowed to operate on this file
save these flags. For virtual sites, this discussion is extended to the admin uid of
that site.
> I agree, a two layer plan is not sufficient. That why no Unix has ever had
> just two levels. Users cant disturb other users files, etc.. This model is
> even insufficient due to the coarseness of 'root' power. Thats what in 2.2
> the Linux kernel has virtually no concept of root.
This coarseness of uid0 on the filesystem is the problem.
> It's obvious that you have no idea what you are talking about, and that
> you've made no effort to research the topic.
Rather the opposite.
> I don't understand why people who don't have any comprehension of the
> existing kernel facilities think they can waltz on in and tell everyone
> what features must be added without performing any research.
Pardon here but I didn't waltz in telling anyone anything had to be added. This
discussion ensued because using these special flags has become a priviledged operation.
Various people have used this ability to protect their files without being root and now
that has been taken away from them. Filesystem flags for users are not fully sufficient
to prevent damage, accidental or intentional.
> FACT: The Linux kernel DOES NOT USE a "TWO LAYER" (root & !root) security
> model.
> Linux uses a capability system. All 'root' level privileges
> are divided into a capability set. There are currently 26 capability
> bits assigned, thus dividing root power into 67,108,863 possible
> access levels.
And currently root can still do anything root wants with a full capability set.
Immutable prevents certain operations regardless of whether or not root has capabilities
set. This discussion also lent towards preventing root from removing the immutable flag
with a securelevel > 0 (or concept thereof). Until much in userland is rewritten, root
is root. Linux still has a long way to go before reaching a much more secure state.
> FACT: The Linux kernel does not need a secure-level. It used to have it,
> it was stupid. It's functionality has been completely superseded by
> capabilities (as long as you apply a patch for raw device access).
This part of the discussion is history. The capability structure for this is in place
but still lacking with userland employment.
> FACT: The whole notion of UID 0's special powers is mostly(*) a
> backwards-compatibility feature under Linux.
> FACT: It's possible *TODAY* to build a Linux system with no root. (it
> requires some hacking for backwards compatibility, and a daemon to manage
> powers because they aren't in the FS).
And if the daemon is destroyed or trojanned you have gained nothing. If you have a
gateway for security transferance, then you have a weakness to attack. The kernel has to
be able to refuse an operation regardless of userland. Userland is not trusted.
> I haven't seen any example uses of user-immutable that wouldn't
> eventually lead to the need for user-immutable-immutable. Your best
> argument so far has been against my spelling and frankly, I don't know why
> I'm wasting my time on some newbie who doesn't even know what's already in
> place.
>
> (*) There still is an issue of storing capabilities in the FS for a
> capability version of SUID.
That's a pretty big issue and until it is resolved, uid0 is still king of the hill.
After it is resolved you need to change the world's view of 'root' and what they expect
'root' to be able to do. Despite your view, people -are- using and relying on these
flags.
Newbie seems to be rather inaccurate. My argument is simplified. Filesystem flag
operations changed which falls under element of least surprise. People have voiced their
desire to have the removed capability. Viro presented an idea to resolve the issue.
-d
-- "The difference between 'involvement' and 'commitment' is like an eggs-and-ham breakfast: the chicken was 'involved' - the pig was 'committed'."
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:08 EST