>> 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.
I'm in full agreement with that, which is why I made the suggestions I
did as to how the effects of introducing capabilities could be kept as
secure as possible.
>>> "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.
True, but what I was getting at is that you responded to what I
consider to be a very valid point by nit-picking my poor use of
English rather than responding to the point. I could've done the same
with you several times, but gave you the courtesy of responding to
what you clearly meant to say instead...
>> 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.
I believe this is where we have been confusing each other: You appear
to believe that all capabilities are security related, and I believe
that whilst there are many capabilities that are security related,
other capabilities can and should be defined to help optimise the use
of the system. It is some of the capabilities in this latter group
that I am referring to in the above, as quite clearly many (but not
all) security related capabilities do not belong there.
In addition, I believe that security-related capabilities of the "I do
NOT require..." variety can safely be placed in the file since they
can only REDUCE the abilities of the file, and it is only capabilities
of the "I additionally require..." variety that can not safely be put
in there.
>> 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.
That was just plain bad english, and I apologise for it. What I meant
to say is betteer phrased in the two paragraphs preceding it...
> BTW, I could just have run "foobar --version", why should that
> be so draconianly denied?
Perhaps because the author of the foobar program forgot to include
anything resembling a --version option, so the command doesn't know
what to do with it anyway... 8-)
> 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.
Like I said in my previous post, any such capabilities embedded in the
file would need to be ones that applied to ALL runs of the program.
Common exceptions like --help and --version could be dealt with by a
capability that says that it runs if either of those is supplied,
irrespective of any other capability.
However, thee capabilities I would see being encoded into the file are
ones like "I do not require X to do my job", where those aren't
exceptions anyway.
> 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.
I'm still not sure what point you're trying to make with your examples
above, so can't comment on this one.
> 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.
Call them what you will, they fit the definition of "capabilities" you
gave some time back, so if you wish to exclude them, you'd best
tighten up your definition.
> If I fake a "needs X to read" property on a file, nothing could
> concievably break security.
I presume you mean "run" rather than "read", in which case that's the
point I was trying to make.
> Same goes for "Best seen through Netscape" or such. But it will
> make life miserable for lynx(1) users, so I don't think this is
> a very good idea anyway.
I wouldn't include that property, but a "This page needs a browser
that can handle graphics" property would save me quite a lot of time,
as I'm a heavy user of lynx and there's nothing more frustrating than
waiting for some page to load over a slow link only to discover that
it displays as a screen full of "[IMAGE]" tags and nothing else.
> 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.
To me, that is a "security-related capability" whereas the "needs X"
and "needs a graphical browser" capabilities are from the "functional
capability" group and the "needs ELF" and "needs JAVA" capabilities
aare from the "system capabilities" group.
>>>> 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).
If so, I'd love to know how. Certainly, I've never seen anything but
problem reports relating to this aspect of script behaviour.
>>> 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.
Most of the comments at this stage can be guaaranteed to have problems
with them,
>>> 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.
I have no disagreement with that, where those rights are
security-related. However, some of the possible capabilities can't be
sensibly stored anywhere else, as you admitted above.
> 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.
The proposals I've seen relating to this are ones that I'm in
agreement with, and can all be summed up by saying that the
capabilities that can safely be stored in the file are those that
REDUCE the abilities of the binary if they're set. I see nothing wrong
with that at all, and the only proposals I've seen suggesting any
similar treatment for capabilities that ENHANCE the abilities of the
binary were promptly withdrawn following POLITE comments from others
on this mailing list.
>> 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.
I have to admit that you came very close to my killfile before I
realised that your apparently constant attacks were unlikely to be
intentional...
>>> 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.
Two questions:
1. If so, why did you rubbish the idea both times it appeared in
this mailing list?
2. You appear to be claiming that I said otherwise than above.
Could you advise me where, as I have no recollection of doing
any such thing?
>>> 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.
Several questions:
1. What UID backup account? I've never seen a system with a
specific account for doing backups from.
2. Why 'she'? I've used 'he' because in English, that's the
gramattically correct way of referring to somebody whose
gender is unknown, but your use of 'she' implies that the
person doing the job is always female.
3. You appear to haave problems with the idea of there being
mor thn one backup system available on a system. Why?
>>> 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...
That's not how I read the comments. My reading was that the
justification for storing capabilities that REDUCE the abilities of a
binary within the file was that suchlike reductions would apply no
maatter where the binary in question was run from, and the said
capability would thus be CORRECTLY exported by existing 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.
No cop-outs please!!!
The instinctive reaction of any NOVICE Unix sysadmin (which all too
many are) is indeed "root", but for you to automatically assume that
everybody you converse with falls into that class and you're the only
one who doesn't is a far worse cop-out than the one you offered above.
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/