>>> If the file just holds the capability-validation timestamp, I'd
>>> just need to make that later than the time the system is booted.
>> In which case, it would still FAIL the test - didn't you notice
>> that I very specifically stated that the test was for EQUALITY
>> with the time of last boot.
> 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.
> "Yes, this file contains a legal capabilities header, so I'll
> stamp it with my boottime" isn't quite enough...
I'm in full agreement with that. What I proposed was no more than the
procedure to be followed to ensure that security hacks didn't get by
the validation procedure when an old kernel needed to be used for some
reason. I thought I made that clear in my first post on the subject...
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.
As a result, I have NO problem with the idea of having to boot an old
kernel on occasion to deal with some problem that can't be handled any
other way, and will therefore dismiss ANY argument against the idea
without further comment...
>>>> If true, then the idea of having information on how to load an
>>>> executable in the file itself is also broken. After all, that's
>>>> a capability in itself - the capability to execute the file. If
>>>> the kernel doesn't recognise the header format of the file, it
>>>> can't execute it...
>>> Yep. That capability is called "x" bit in Unix.
>> WRONG !!!
>> The 'x' bit only says that the file should be regarded as
>> executable, and provides ZERO information on how to load the
>> executable when the user asks to run it.
> 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.
My point here is that whilst there are some capabilities that can ONLY
be stored in the file system metadata, there are also others that can
only be sensibly stored in the file itself, and yet others that could
be stored in either place. I most definately don't agree with your
claim that all capabilities must be stored in the metadata, and you'll
never persuade me that such is the case.
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.
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.
3. How to display a web page [file]
Are any comments needed regarding this one?
Perhaps that explains my position somewhat better than my previous
posts did?
>> If you don't believe me, try the following:
>> 1. Find a web page on your system. Any web page.
>> 2. Set the 'x' bit on it.
>> 3. Type in the path and name for the relevant file.
>> 4. Watch Linux REFUSE to execute it because it doesn't know how
>> to despite the fact that it has the relevant 'x' bit set.
> 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...
>>>>> ...and works only for some types of files (how about a
>>>>> webserver written in Perl?).
>>>> That's up to the PERL interpreter to handle, not the kernel.
>>>> After all, the kernel ignores s[gu]id on scripts already, and
>>>> the only reason s[gu]id works on PERL scripts is because the
>>>> PERL interpreter handles the relevant capabilities if it sees
>>>> the s[gu]id flag set on the script it's running.
>>> Great. "Any Perl script that states `I've got capability A' is
>>> now capable?! You _seriously_ suggest to trust the Perl (and sh,
>>> and ...) interpreters?
>> I don't suggest anything, YOU are the one making that
>> suggestion. Can I suggest you start by checking how s[gu]id perl
>> scripts CURRENTLY work before you start accusing me of things I
>> have neither done nor said...
> 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 securrity capabilities within them in a secure way.
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 !!!
>>> The idea of capabilities was designed to be able to build _more_
>>> secure systems. To be able to do that in practice, you _have_ to
>>> play by the capability rules, else the whole system is liable to
>>> be the victim of as yet undiscovered attacks.
>> Agreed, and that's what everybody except you appears to be trying
>> to do. I'm curious why you aren't?
> 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...
> 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.
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.
Yes, there will be a lot of suggestions that don't make it into the
final design at all, and there will be others that don't make it into
the final design in the form they were made. However, the final design
will be much more mature and solid after such a brainstorming session
since points the authors would never have thought of will be raised
and considered as a result of it.
> 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,
>>> 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.
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.
> 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.
>>> Show me _one_ system run by a security concisious sysadmin that
>>> runs 1.2.x and 2.0.x alternatively.
>> Presumably so you can have a go at cracking them, and them blame
>> it on me for publicising them. Sorry, I'm not that daft...
> Weaseling out here?
Nope, just that I don't see the logic behind advertising places where
crackers can have an easy time on a public mailing list such as this.
If you wish me to show you SEVERAL systems which match your comment
above, let me know when you'll be in Aberdeen and I'll meet you and
take you to the systems in question, but I will NOT advertise them in
public in the way you suggested. For any price.
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/