[...]
> 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.
No, I think capabilities should work seamlessly together (as an extension
of, or complement to) regular Unix permissions. But AFAIKS this has
profound implications for _everything_ that has to be checked for
permission.
[...]
> >>> 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...
I'm completely at a loss about what you mean then.
[...]
> > "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.
It is quite a difference to me. Sure, the outcome is that nothing happens
in both cases. In the first, I can fix it by correcting the file (I might
have given execute permission to the wrong file, or a file for the wrong
architecture, or mistyped the interpreter name, or something like that), in
the second case I'm just not allowed to do what I want.
[...]
> 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.
It can be stored in the file, but security in any meaningful sense goes out
the window: It is just to easy to overwrite files, get the helpful sysadmin
to restore a file, doctor something that is being copied via NFS, ... There
are just too many points of attack, and the kernel would have a hell of a
time guaranteeing nobody has tampered with the file's capabilities.
> 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.
OK, but IMHO they'd better encoded into code:
if(getcap("foo") != 0) {
perror("getting foo");
exit(EXIT_FAILURE);
}
BTW, I could just have run "foobar --version", why should that be so
draconianly denied? Many programs have several uses, i.e., tar(1) might be
used to untar a bunch of files in my account. But tar would need to be able
to set _any_ capability (just in case). Should it bail out on me?
sendmail(8) can be used to send mail (as used in several scripts). In that
capacity it doesn't need binding to the smtp port.
Perhaps they should; and other, more restricted, tools should take their
place for these kinds of uses. But I'd oppose that: It is good that most
sysadmin work is done with everyday tools.
> 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".
That isn't a capability of the program, it's a property of the system in my
view.
> 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.
But showing a HTML file is _not_ the only thing you might want to do to it:
Perhaps edit it with vi(1), count its lines, ... The independence of the
tools Unix uses from the file formats is precisely its greatest strength. I
have worked on systems where the actions on a file were restricted by its
type, and felt quite unconfortable indeed.
What you are talking about would better be described as prerequisites (or
properties) of the file, and for those I truly have no objections to store
them in the file itself: If I fake a "needs X to read" property on a file,
nothing could concievably break security. Same goes for "Best seen through
Netscape" or such. But it will make life misserable for lynx(1) users, so I
don't think this is a very good idea anyway.
A capability (in the abstract sense of the underlying security model) is a
key that opens some resource for the process that owns the capability.
Something quite different from the above.
[...]
> >> 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.
I'm not up to date WRT the status of S[UG]ID scripts, but I understand that
they _can_ be implemented securely, without kludges like an all-powerful
interpreter (that is clearly out of the question for a capability system).
[...]
> > 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.
Exactly! I'm trying to look ahead for possible problems.
[...]
> > 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.
Storing the rights to do things inside files (that can be tampered with in
a miriad different ways) is not secure. The ideas given here were proposed
as a way of continuing using the exact same tools as before, but they
couldn't live up to that (extra bits for capabilities, overloading sticky
(+ inmutable) or SUID root for marking a capable executable all need
_extra_ support in tools to recognize the special status). So you will need
to hack them anyway, and the whole advantage of this just evaporates.
> > 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.
Perhaps.
[...]
> I believe most people have given up on that idea as a result of your
> attacks on everybody who mentioned the subject.
If I came through as attacking somebody, I'm truly sorry. It was never my
intention to do that, just to point out that there are _lots_ of things to
be concerned about when talking capabilities.
[...]
> > 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.
That's what I have been saying all along: You need those specialized tools
(or trusted "normal" tools that are capability-aware), so "continue to use
regular tar(1) everywhere" doesn't cut it anyway.
[...]
> > 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.
Yes, but the UID backup account (who is in charge of the person responsible
for doing backups) has _no_ access to /etc/shadow. But the tools she uses
must be able to back that up anyway.
> > 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.
Exactly what has being thrown around here as the justification for storing
capabilities inside the files is that you continue using the old tools...
> > 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?
Whenever specific capabilities are needed to do a job the instinctive
reaction of any Unix sysadmin is "root". You have to think almighty root
away, suddenly things look _very_ different.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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/