lkml.org 
[lkml]   [1999]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectCapabilities under Linux
Hi Horst.

>>> But what do you validate against?

>> I very specifically didn't address that point as I don't have
>> anything constructive to say there. All I said about that was
>> that the capabilities were validated against some trusted
>> source, which they have to be for the idea of capabilities to
>> make any sense.

> That's what I have been saying all along. If you don't elaborate
> on this central point, you aren't saying how to do it at all.
> Case closed.

If it was, then I apologise with all my heart.

From your comments, I was under the impression that you believed that
implementing capabilities should only be done on a system that scraps
all current security checks in favour of (initially alpha-quality)
capability systems, and I don't believe that to be either feasible or
realistic. It is for that reason that I offered my suggestion as to
how to manage the migration period from one system to the other so as
not to detract from the security of either system.

>> For reference, I recently had to make use of the 2.0.27 kernel
>> that came with RedHat 4.1 on one of my systems to deal with a
>> problem that had occurred, as neither the 2.2.4 kernel that
>> machine normally uses, nor the 2.0.36 kernel used prior to that
>> and still on the system, could handle the new network card I
>> installed to replace a failed one, and I had no other means of
>> getting an updated 2.2.4 kernel on the machine in question.

> That is your personal machine, I presume. If it was a
> production, security sensitive machine, you would have had to
> find another, trusted way to get a new kernel onto it.

Actually, it IS a "production, security sensitive" system, as you put
it, at least to the extent that the company accounts processing are
run on it, and text files containing sensitive information are quite
regularly found thereon for short periods.

>>> Why "how to run it"? The _capability_ to be run is in the
>>> metadata, the _how_ is (encoded into) the file.

>> That _how_ is ALSO a capability in any meaningful interpretation
>> of the word, and that capability is stored in the file itself.

> "Capability to run this perl script as an ELF executable" makes
> a lot of sense, agreed.

If you want to act daft, I'll leave you to it - you know as well as
everybody else that that's NOT the capability I was referring to...

>> For example, where would you find the following capabilities?

>> 1. Permission to execute the file [metadata]

>> Linux and all versions of MS-DOS both put this in the metadata,
>> Linux in the file's mode, MS-DOS in the file's extension.

> This is not part of the file itself, it is data about the file,
> i.e., metadata. Nothing wrong there.

>> 2. How to load a file for execution [either]

>> Linux puts it in the file header, MS-DOS 2.xx put it in the
>> metadata (specifically whether the file's extension was BAT (a
>> shell script), COM (a memory image) or EXE (a loadable image),
>> and MS-DOS 3.xx and later used a combination where files with
>> a BAT extension were shell scripts, and files with either COM
>> or EXE extensions had their contents checked for whether they
>> were memory images or loadable images.

> DOS is broken in this regard. And putting information on the
> file _format_ elsewhere than in the file itself just invites
> errors, better make the format self-describing if at all
> practical: I.e., magic numbers et al in the Unix way.

>> 3. How to display a web page [file]

> This kind of stuff is usually handled by some sort of
> filemanager, the variety of different file formats is just too
> big to be handled by the kernel in any halfway sane way. And new
> formats are invented every day...

In each case, that was precicely my point, so I'm glad we agree on
that much at least...

>>> Format mismatch, not "can't be done because it isn't allowed".
>>> Two quite different outcomes.

>> Same difference - it refuses to execute it either way. I could
>> equally well have created a binary data file with the 'x' bit set
>> to make the same point...

> "Sorry, I'd be glad to oblige but I don't know how to do that"
> and "You aren't allowed to ask me do that" are quite different
> outcomes for me.

Agreed, but if the only way you can defend your argument is by doing
nit-picking like that, you've lost before you start.

>>> How do you encode the capabilities in a perl script, so I (the
>>> writer) am unable to forge them? How about the security of the
>>> requisite all-capable perl interpreter that is going to run any
>>> random script (hint: the script might crack the interpreter...)?

>> Precicely my point: PERL scripts (any scripts, come to that) can't
>> be written to encode security capabilities within them in a secure
>> way.

> And binary executables can't either, for exactly the same reasons.

Who's said they can? Your claim was that there's NOTHING related to
capabilities that can be stored within the file itself, and I for one
just don't believe that.

As I made clear from the start, I believe that the ONLY security
related capabilities that should be encoded in a file are those of the
"I can't action my intended task without these capabilities, so refuse
to run me if I can't be granted them" variety, which information MUST
belong in the file itself - it makes no sense at all to put it
anywhere else.

An example of this is the one I posted earlier, which you clearly
didn't bother to read through before you rubbished it: A binary stored
in ELF format effectively includes in its header the statement "I can
only be run on a system with the ability to load binaries stored in
ELF format, so refuse to run me if you can't do so". Likewise, a HTML
document file effectively includes within the file the statement "I
can only achieve my intended task when read by something that knows
how to handle documents in HTML format". OK, both are simple
capabilities that shouldn't need expressing, but I'm sure you can soon
come up with plenty of more complex ones.

One that comes to mind would be to have a capability that says "I can
only action my task if run in an environment supporting an X display",
and attach that capability to programs like Netscape or Xearth. The
ONLY place that particular capability could sensibly be stored is in
the file itself, and I for one would see NO problem with it being
copied from one system to another - irrespective of the system one
tries to run it on, the capability will remain true.

>> The same is true of s[gu]id scripts, and I regard the fact that
>> PERL scripts can meaningfully gain s[gu]id priviledges as a
>> MIS-FEATURE - in fact, I'd go so far as to call it a BUG !!!

> An executable is an executable (that's the Unix tradition), it
> should be able to do the same things no matter how it is
> implemented (another cherished part of the Unix tradition:
> Uniformity, even at some cost).

If that 'cost' is that I let a trojan onto my system that I could have
avoided were it not for that requirement, then I'll quite happily
ignore the said requirement, much to your obvious dismay.

>>> Secure systems aren't build by kludgeing on "security features",
>>> they have to be concieved, designed and built that way from the
>>> ground up, using simple, easy to check and tamperproof
>>> mechanisms.

>> Whilst that's basically true, it's also true that they are
>> rarely correct the first time round, and for that reason,
>> whatever method is used to implement them MUST work in PARALLEL
>> with the existing system until it has been proven to be better
>> than the existing system, and only then can the existing system
>> be dropped...

> That doesn't mean that the secure and the legacy system have to
> run on the same machine at the same time.

True, but irrelevant.

> Someday you _will_ have to switch over. And at that moment (at
> the very latest) the "legacy compatibility" becomes a major
> burden.

Why?

>>> The schemes vented here don't live up to that, IMVHO, and
>>> might stand in the way of doing it right later to boot.

>> So far, there haven't been any schemes vented here, only
>> suggestions as to how various aspects of the finished design
>> could be implemented.

> OK, make the above "The various suggestions on how to implement
> aspects of the finished design" then. But these suggestions
> don't really consider a finished design, they want to kludge
> their way in the rough direction of the final goal, and they do
> not consider seriously how to really achieve that final goal, so
> they are fatally flawed, IMO.

I think you're reading far more into the suggestions to date than they
warrant. At best, they are various people's comments on steps that
could be taken, and other people's comments on what problems they can
envisage occurring as a result of those steps.

>> I've designed enough things in my time to know that a
>> brainstorming session like that is an ESSENTIAL prerequisite for
>> a solid design, and for that reason, I believe that ALL
>> suggestions should be WELCOMED, as should CONSTRUCTIVE criticism
>> of the suggestions made. However, DESTRUCTIVE criticism (such as
>> yours) of the suggestions made is to be AVOIDED as it only ever
>> results in a flawed design due to necessary points not being
>> raised during the brainstorming session.

> Perhaps I am mistaken, and my worries are unfounded, but you
> really haven't done much to allay them so far. And I sicerely
> think that worries such as mine _have_ to be laid to rest for
> good before _any_ scheme is adopted as the final design.

If I had any idea what your worries were, I'd be more than willing to
consider them, but I have yet to see even a clue as to what you're
actually worried about - all I've seen so far from you is comments
stating that EVERY suggestion put forward is fatally flawed without
your ever giving a comprehensible reason as to why it might be flawed.

> Perhaps I'm being overcautious, but where security is involved
> "Better safe than sorry".

Whilst I'm in full agreement with your conclusion, I'm unable to say
whether you're even near to being overcautious for the reason stated
above.

>>> What I sorely miss in this whole discussion is the design of the
>>> userland that goes with capabilities. It isn't enough to get
>>> capabilities working any old way, the system has to use them
>>> wisely if you want security advantages.

>> So far, there isn't even a full list of the capabilities that need
>> to be present,

> OK, let's work on that then.

I believe most people have given up on that idea as a result of your
attacks on everybody who mentioned the subject.

>>>>> Other way around: If you can do something like that _without_
>>>>> capability aware tools, the system is irrecoverably broken:
>>>>> This allows faking and smuggling capabilities.

>>>> Nope, that's entirely up to the tools that do the RESTORE stage
>>>> of the procedure, and the BACK-UP stage should be completely
>>>> transparent to them if it's to have any meaning whatsoever...

>>> I don't want any old "backup tool" to be able to read, say,
>>> /etc/shadow or the underlying disk without specific permission,
>>> i.e., capability.

>> Who's suggested that it should be able to? Not me, for sure.

> Then how do you handle it with your 100% backward compatible
> tools that don't need to be even recompiled?

By following the suggestion that you rubbished several times: Restrict
the generally available backup tools to use by individual users
wishing to back up their own files (which they need no special
permissions to do), and restrict the backing up of security-related
files to a backup tool that's not generally available and has the
required capabilities to do its job.

You have yet to explain what you see wrong with that idea, despite the
fact that you declared it to be rubbish at least twice in this mailing
list, and I for one would love to hear your explanation.

>> My claim is that the backup tools do not need to have any
>> special capabilities to do their job on the files they have
>> permission to access, and I stand by that claim. If you've any
>> sense, so will you.

> The backup tool runs with the UID of the backup operator, who
> doesn't have permission to read most of the files in the system.

Where did you get that rubbish from?

The backup tools run with the UID of the person wishing to use them -
for example, tar ran with *MY* UID about 10 minutes ago on this system
- and has access to the files that user has access to. I used it to
back up my files to floppy so the sysadmin can upgrade the hard drive,
something he's announced that he will be doing this coming weekend.
Since his announcement stated that individual users were responsible
for backing up their own files as there was no possibility of a
central backup being taken, I for one am glad that there's a backup
tool available that let me do so.

> It might have to backup raw disk partitions, which the backup
> operator can't touch under any circumstances.

If it does, then it should be a backup tool specific to that task, not
a generally available one. Your proposal to use a generally available
one for suchlike tasks is an open invitation to crackers in my book.

> Please forget about the cop-out "almighty root does all", that
> is the essence of what capabilities are all about.

WHere have I ever offered any such cop-out?

>>> So this has to go in anyway in some form. Why not make the
>>> tool aware then? It will have to help check security.

>> What on earth for? It's the kernel's job to check security, not
>> the backup tool's job.

> Ok, there you have a (partial) point.

I'm glad you agree.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html


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

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.114 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site