I never said they were alternatives, I said you didn't need authentication, and that authorization was sufficient. I'm not a shmuck who's been drinking too much of the capability kool-aid; I know authentication can be quite useful in some situations, and is an integral part of many existing systems. However, I believe authentication draws far too much attention when it's really a trivial problem. We know 10,001 ways to authenticate anything, but it doesn't help because authentication is not the problem.
Even passwords are a sufficient authentication mechanism as long as users only have to remember one. That's all they should need to remember, and then we can make the password fairly strong. And that's only for users: authentication for programs really is completely useless. And even for users, I suggested an authorization technique to replace an authentication. You can argue that the example is also an authentication, and that example does blur the line, but from the user's perspective, it behaves like an authorization, and that's what matters.
I never questioned your credentials, but one should always be careful in claiming that something is impossible.:-)
Hmm, from my reading, the poster asked an access control question, not an authentication question. To answer your questions, you connect that bag of meat to his session the same way you connect any other piece of software to another remote piece of software: carry an authorization token. I explained one way to make this easy here.
Let me pose a hypothetical: consider a capability OS a suspended shell session. Your OS stored a cryptographic token which directly designates that session on a USB key, or a secure crypto card of some sort. Plugging your key into the computer automatically reconnects you to your session. Do you consider this an authentication or an authorization?
Being used to identity-based access control, it's difficult to imagine another way. I just posted this elaborate response to another question, but perhaps it's a little too abstract. I'll assume you're a programmer. I'll further assume that you're familiar with Java.
Assume that we're in a Java-like language with no static fields or methods. All we have are object instances, and instance methods. Now, let's assume a simple filesystem API for our OS:
package Filesystem;
public abstract class Entry {
public string getName();
public void Delete(); } public class Directory : Entry {
public Entry[] getEntries();
public Entry getEntry(string name); } public class File : Entry {
public FileStream openStream(); }
This package provides very basic filesystem-like services: we can traverse a directory tree, look up names, retrieve subdirectories or files, and open a stream for reading and writing data to files. Let's suppose that the on-disk filesystem looks like this:
/etc /home /home/A /home/B
Now let's suppose that person A and B are modeled by two threads in our OS. We can start thread A with a Directory object which references "/home/A", and we start thread B with a Directory referencing "/home/B". Now show me a sequence of method calls where A can access files under "/home/B", or even the files under "/etc".
Spoiler: no such attack is possible. Our Java-like language is memory safe, so you can't forge a reference to another directory without being given that reference. Object references are capabilities. There is no "getParent()" on a Directory, so a thread, or person, cannot escape out of their home directories. Each directory tree is a private namespace. So how do we enable sharing and document exchange? We map documents into that namespace.
Documents under "/home/B", like "/home/B/homework.doc" look like "/homework.doc" to B. B thinks he's working out of the root directory, and has no knowledge of anything outside of that. Even if he did gain outside knowledge, there's no way to exploit that knowledge. He's constrained by what capabilities he holds, ie. by what references he has. He can only access the objects to which he has references.
For a simple answer to document exchange, let's say we add "/home/A/shared/B", then add a directory entry under "/home/B/A" that points to it. Now A and B have an indirect communication path. Note that we have no notion of "identities", and no separate notion of "permissions" on the files, so your question about impersonation is actually meaningless. If you hold a reference to the object, you can operate on it, no ifs, ands or buts. If you don't have a capability to the object, directly or indirectly, you cannot cause changes to that object. This is capability security. I hope that clarifies things.
1) It would still seem that the decision to initially hand the capability to the user has to be made with knowledge of who the user is, and
You pose some good questions which I intend to address, but first there are a number of assumptions in this one statement which has lead people astray in the past, so I want to address those first.
The User: just about every single access control discussion, particularly informal ones like this thread, start by talking about "users". Talking about "users" quite naturally dovetails into discussions of identities, then authentication, and finally the natural access control abstractions end up looking identity-based like Unix/Windows. The problem with this approach is, users generally aren't a threat. The real threats are from programs.
Access control is mainly about maintaining the integrity of a system in the presence of malicious programs. When viewed this way, identity-based access control starts to look meaningless. The "identities" of programs is a much fuzzier concept than the identities of users, but this is the right way to view access control. You can deal with program identities ala Polaris, and the resulting system is usable, but it's far simpler to eschew identities entirely.
Once you eschew identities, dealing with authorizations as distinct entities looks more natural. The more fine-grained the authorization, the better. Since programs are the only entities handling these authorizations, it doesn't matter how fine-grained we make them. Most of the heavy-lifting is done behind the scenes, hidden from users. When accessing a resource, you have to name it, then provide the authorization token demonstrating you have permission access to it. Then you start to wonder why the designation and the authorization can't be combined into a single handle for convenience. They can! They're called capabilities. Some other designs maintain this separation, but I can't find the reference to the paper at the moment.
Now comes the question: where do these capabilities come from, and how do we get them? The simple answer is: initial conditions. Just like the Big Bang, the universe of objects inside a computer is constructed at installation time. The installer constructs the primordial storage manager, user manager, shell, etc. from which the primordial user can allocate more storage to create other users, and endow them with capabilities, and so on.
At this stage, I've only been talking about programs all contained within a single computer. Now we come full circle to your question: how does someone outside the computer get (re)connected to their session which exists inside the computer? Note first that this is only a problem for a computer shared amongst multiple users.
To maintain the security properties, you need: portable sessions, as you suggested, a portable authorization token, or some form of secure authentication. This is the only authentication step needed, and even then it's not necessarily required.
Your comment seems to imply that an authentication is needed for every interaction with a new object, when you only need to authenticate with one computer, your own, and if you can carry that computer with you (pda, cellphone, etc.), then no further authentication is ever needed. A portable authorization token can be a USB key or a secure card that holds a cryptographically-secure hash designating your session. I prefer the last option, as its the most user friendly, and the most secure.
2) I'm curious how you would go about restoring security were such a persisted capability stolen.
This is a long-standing fear of system administrators everywhere. "Capabilities grant you flexibility and POLA, but you lose control!" There is a thread going on right now on the cap-talk mailing list about this actually. There are many possible ways to address this concern actually, and the only answer t
"Anyone who knows security knows this"...should be read as "anyone who agrees with me knows this"....should be read as "I'm too ignorant on the subject to comment constructively, so I'll just be flippant".
Let me ask you this: what use is authentication without identity? Identity is generally irrelevant when making authorization decisions, particularly when using capabilities. Identity-based access control is the single cause of our vulnerable computing infrastructure. Identity-based security can be locked down somewhat, with Polaris being the epitome of what's achievable on Windows, but it has fundamental limits associated with the amount of information available to make appropriate authorization decisions.
Capabilities change the whole security game, as they enable principle of least authority designs to be easily constructed. Identity-based controls are not composable, so fine-grained permissions are simply impossible.
Capabilities are not the only authorization-based access control of course, but they are perhaps the most well-known. You can even start playing with capabilities today.
How can your authorize something, unless you know who you're authorizing?
You've asked the right question. You can find an intro here. That article links to arguably the best authorization scheme: capability-based security, where authorization is combined with designation. This results in many useful security properties that aren't achievable via authentication schemes.
Authentication is a broken concept. Anybody who knows anything about security knows this. Focusing on authorization, not authentication, is the only way to secure anything.
Of course, if you actually care about data integrity and database features, there's not contest at all. But the performance gap is now non-existent, if not completely reversed.
Regulate those sections of the market that need it, and let the rest continue.
Or just don't. There are already software companies that accept liability if their software has bugs, and such software is used in mission critical systems (see QNX). Why introduce regulation when there isn't really a problem?
Hurd doesn't virtualize hardware so it can not host a foreign OS.
Immaterial. The kernel just needs to trap on privileged instructions, and send messages to the hosted kernel's fault manager(s), which translates the trap codes into native kernel calls. See L4Linux.
As far as I know there is no software that does virtualization available for Hurd.
Which is a very different statement than the original "it cannot be done". Now we're mostly in agreement. Hurd is being ported to L4, and L4 already hosts Linux, so you're only half right.
- UNIX can be successfully run as an application program
`Run' perhaps, `successfully' no. Name a product that succeeds by running UNIX as an application.
L4Linux. Performance is comparable to running linux natively, and often better than running it on Xen.
- RPC is a good idea to base your system on
Depends on what you mean by RPC. If you predefine the complete set of RPC's, then yes. If you make RPC a paradigm and expect every application to build its own (c.f. stub compilers), you lose all the discipline you need to make the system comprehensive.
Misinformed. Stub compilers are used for language interoperation, and simple data marshalling. They are not a necessary component of any microkernel.
As for predefining the complete set of RPC interfaces: while every communication can be represented as a read/write stream as in Plan9, you still to marshall data anyway, in which case you're back to doing it manually, or using stub compilers.
The downside is that it will likely be a single-address space system, so you can't use more than your addressable memory, ie. MMU operating systems can theoretically host two processes each consuming 4GB on a 32-bit machine, where a language-based system like Singularity can't. You can solve this by introducing page tables again, but you also reintroduce many of the problems you sought to avoid (TLB flushes, slower context switches, copying, etc.). There may be alternative designs which don't suffer from this limitation though, and I agree that language platforms are the future.
There are many microkernels that have demonstrated that microkernels are just as fast, if not faster than monolithic kernels (faster because there's less resource contention and locking in kernel space, they use fewer resources because the resources are better partitioned, etc.). See L4, EROS (now CapROS on Sourceforge), QNX, and the forthcoming Coyotos operating systems.
Indeed, or perhaps, due to women and other minorities becoming more socially viable employees, the workforce supply outstripped the demand, so the wage per employee dropped.
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 1
I don't get it. Safe html? All html is safe. Certain extensions to embed content are not safe, such as embed and script, but html itself is safe. So basically, you just want to be able to include third-party html, but only html, no other content. How is that hard to filter?
a) Wikipedia is not a math journal b) Subsequently, how do you know it's correct? Wikipedia does not have the peer review of a math journal. c) Long proofs like this are more appropriate for the Wikipedia books project, not Wikipedia itself. Articles are supposed to be summaries.
I can sympathize with your plight, as there are many CS papers I'd like to read that are unavailable online. Still, Wikipedia cannot stretch itself too thin. Do one thing well, even at the expense of other useful things if necessary.
Slashdot Mirror
I never said they were alternatives, I said you didn't need authentication, and that authorization was sufficient. I'm not a shmuck who's been drinking too much of the capability kool-aid; I know authentication can be quite useful in some situations, and is an integral part of many existing systems. However, I believe authentication draws far too much attention when it's really a trivial problem. We know 10,001 ways to authenticate anything, but it doesn't help because authentication is not the problem.
:-)
Even passwords are a sufficient authentication mechanism as long as users only have to remember one. That's all they should need to remember, and then we can make the password fairly strong. And that's only for users: authentication for programs really is completely useless. And even for users, I suggested an authorization technique to replace an authentication. You can argue that the example is also an authentication, and that example does blur the line, but from the user's perspective, it behaves like an authorization, and that's what matters.
I never questioned your credentials, but one should always be careful in claiming that something is impossible.
Hmm, from my reading, the poster asked an access control question, not an authentication question. To answer your questions, you connect that bag of meat to his session the same way you connect any other piece of software to another remote piece of software: carry an authorization token. I explained one way to make this easy here.
Let me pose a hypothetical: consider a capability OS a suspended shell session. Your OS stored a cryptographic token which directly designates that session on a USB key, or a secure crypto card of some sort. Plugging your key into the computer automatically reconnects you to your session. Do you consider this an authentication or an authorization?
Identity is meaningless in a capability system, so it all depends how far down your capabilities go.
Assume that we're in a Java-like language with no static fields or methods. All we have are object instances, and instance methods. Now, let's assume a simple filesystem API for our OS: This package provides very basic filesystem-like services: we can traverse a directory tree, look up names, retrieve subdirectories or files, and open a stream for reading and writing data to files. Let's suppose that the on-disk filesystem looks like this: Now let's suppose that person A and B are modeled by two threads in our OS. We can start thread A with a Directory object which references "/home/A", and we start thread B with a Directory referencing "/home/B". Now show me a sequence of method calls where A can access files under "/home/B", or even the files under "/etc".
Spoiler: no such attack is possible. Our Java-like language is memory safe, so you can't forge a reference to another directory without being given that reference. Object references are capabilities. There is no "getParent()" on a Directory, so a thread, or person, cannot escape out of their home directories. Each directory tree is a private namespace. So how do we enable sharing and document exchange? We map documents into that namespace.
Documents under "/home/B", like "/home/B/homework.doc" look like "/homework.doc" to B. B thinks he's working out of the root directory, and has no knowledge of anything outside of that. Even if he did gain outside knowledge, there's no way to exploit that knowledge. He's constrained by what capabilities he holds, ie. by what references he has. He can only access the objects to which he has references.
For a simple answer to document exchange, let's say we add "/home/A/shared/B", then add a directory entry under "/home/B/A" that points to it. Now A and B have an indirect communication path. Note that we have no notion of "identities", and no separate notion of "permissions" on the files, so your question about impersonation is actually meaningless. If you hold a reference to the object, you can operate on it, no ifs, ands or buts. If you don't have a capability to the object, directly or indirectly, you cannot cause changes to that object. This is capability security. I hope that clarifies things.
Then perhaps you should get a better dictionary. There is more in heaven and earth Horatio, than is dreamt of in your philosophy...
1) It would still seem that the decision to initially hand the capability to the user has to be made with knowledge of who the user is, and
You pose some good questions which I intend to address, but first there are a number of assumptions in this one statement which has lead people astray in the past, so I want to address those first.
The User: just about every single access control discussion, particularly informal ones like this thread, start by talking about "users". Talking about "users" quite naturally dovetails into discussions of identities, then authentication, and finally the natural access control abstractions end up looking identity-based like Unix/Windows. The problem with this approach is, users generally aren't a threat. The real threats are from programs.
Access control is mainly about maintaining the integrity of a system in the presence of malicious programs. When viewed this way, identity-based access control starts to look meaningless. The "identities" of programs is a much fuzzier concept than the identities of users, but this is the right way to view access control. You can deal with program identities ala Polaris, and the resulting system is usable, but it's far simpler to eschew identities entirely.
Once you eschew identities, dealing with authorizations as distinct entities looks more natural. The more fine-grained the authorization, the better. Since programs are the only entities handling these authorizations, it doesn't matter how fine-grained we make them. Most of the heavy-lifting is done behind the scenes, hidden from users. When accessing a resource, you have to name it, then provide the authorization token demonstrating you have permission access to it. Then you start to wonder why the designation and the authorization can't be combined into a single handle for convenience. They can! They're called capabilities. Some other designs maintain this separation, but I can't find the reference to the paper at the moment.
Now comes the question: where do these capabilities come from, and how do we get them? The simple answer is: initial conditions. Just like the Big Bang, the universe of objects inside a computer is constructed at installation time. The installer constructs the primordial storage manager, user manager, shell, etc. from which the primordial user can allocate more storage to create other users, and endow them with capabilities, and so on.
At this stage, I've only been talking about programs all contained within a single computer. Now we come full circle to your question: how does someone outside the computer get (re)connected to their session which exists inside the computer? Note first that this is only a problem for a computer shared amongst multiple users.
To maintain the security properties, you need: portable sessions, as you suggested, a portable authorization token, or some form of secure authentication. This is the only authentication step needed, and even then it's not necessarily required.
Your comment seems to imply that an authentication is needed for every interaction with a new object, when you only need to authenticate with one computer, your own, and if you can carry that computer with you (pda, cellphone, etc.), then no further authentication is ever needed. A portable authorization token can be a USB key or a secure card that holds a cryptographically-secure hash designating your session. I prefer the last option, as its the most user friendly, and the most secure.
2) I'm curious how you would go about restoring security were such a persisted capability stolen.
This is a long-standing fear of system administrators everywhere. "Capabilities grant you flexibility and POLA, but you lose control!" There is a thread going on right now on the cap-talk mailing list about this actually. There are many possible ways to address this concern actually, and the only answer t
"Anyone who knows security knows this" ...should be read as "anyone who agrees with me knows this". ...should be read as "I'm too ignorant on the subject to comment constructively, so I'll just be flippant".
Let me ask you this: what use is authentication without identity? Identity is generally irrelevant when making authorization decisions, particularly when using capabilities. Identity-based access control is the single cause of our vulnerable computing infrastructure. Identity-based security can be locked down somewhat, with Polaris being the epitome of what's achievable on Windows, but it has fundamental limits associated with the amount of information available to make appropriate authorization decisions.
Capabilities change the whole security game, as they enable principle of least authority designs to be easily constructed. Identity-based controls are not composable, so fine-grained permissions are simply impossible.
Capabilities are not the only authorization-based access control of course, but they are perhaps the most well-known. You can even start playing with capabilities today.
How can your authorize something, unless you know who you're authorizing?
You've asked the right question. You can find an intro here. That article links to arguably the best authorization scheme: capability-based security, where authorization is combined with designation. This results in many useful security properties that aren't achievable via authentication schemes.
Authentication is a broken concept. Anybody who knows anything about security knows this. Focusing on authorization, not authentication, is the only way to secure anything.
Sounds like a distributed application, whose distributed properties were then broken by forcing the data to be located on the same host. A shame.
A couple such comparisons already exist. They may be a year or two out of date however.
Yeah, if only for those darn inconvenient facts demonstrating that PostgreSQL is faster than MySQL, particularly under load. Note that the benchmark was PostgreSQL 8.2. Now note that 8.3 is up to twice as fast as 8.2. I think the polarity on your order of magnitude performance difference should be reversed.
Of course, if you actually care about data integrity and database features, there's not contest at all. But the performance gap is now non-existent, if not completely reversed.
Regulate those sections of the market that need it, and let the rest continue.
Or just don't. There are already software companies that accept liability if their software has bugs, and such software is used in mission critical systems (see QNX). Why introduce regulation when there isn't really a problem?
Hurd doesn't virtualize hardware so it can not host a foreign OS.
Immaterial. The kernel just needs to trap on privileged instructions, and send messages to the hosted kernel's fault manager(s), which translates the trap codes into native kernel calls. See L4Linux.
As far as I know there is no software that does virtualization available for Hurd.
Which is a very different statement than the original "it cannot be done". Now we're mostly in agreement. Hurd is being ported to L4, and L4 already hosts Linux, so you're only half right.
- UNIX can be successfully run as an application program
`Run' perhaps, `successfully' no. Name a product that succeeds by running UNIX as an application.
L4Linux. Performance is comparable to running linux natively, and often better than running it on Xen.
- RPC is a good idea to base your system on
Depends on what you mean by RPC. If you predefine the complete set of RPC's, then yes. If you make RPC a paradigm and expect every application to build its own (c.f. stub compilers), you lose all the discipline you need to make the system comprehensive.
Misinformed. Stub compilers are used for language interoperation, and simple data marshalling. They are not a necessary component of any microkernel.
As for predefining the complete set of RPC interfaces: while every communication can be represented as a read/write stream as in Plan9, you still to marshall data anyway, in which case you're back to doing it manually, or using stub compilers.
Back in 1998 the problem was mainly that nobody had invested in that particular mirco-kernel technology
What? L3, L4, EROS, QNX, and KeyKOS microkernels all predate 1998, and most of them are top performers.
The downside is that it will likely be a single-address space system, so you can't use more than your addressable memory, ie. MMU operating systems can theoretically host two processes each consuming 4GB on a 32-bit machine, where a language-based system like Singularity can't. You can solve this by introducing page tables again, but you also reintroduce many of the problems you sought to avoid (TLB flushes, slower context switches, copying, etc.). There may be alternative designs which don't suffer from this limitation though, and I agree that language platforms are the future.
There are many microkernels that have demonstrated that microkernels are just as fast, if not faster than monolithic kernels (faster because there's less resource contention and locking in kernel space, they use fewer resources because the resources are better partitioned, etc.). See L4, EROS (now CapROS on Sourceforge), QNX, and the forthcoming Coyotos operating systems.
If you don't like the word tell us how we should describe microkernel code that someone stripped the process isolation from?
Isn't it obvious? It's monolithic. If there is no isolation, there is no protection, thus, it's not a microkernel.
No it isn't. Xen is a hypervisor it isn't a microkernel. You could host Hurd and or Minx 3 on Xen but you can't host Xen on Minx 3 or Hurd.
Yes, you can. It's all just software in the end.
Indeed, or perhaps, due to women and other minorities becoming more socially viable employees, the workforce supply outstripped the demand, so the wage per employee dropped.
I don't get it. Safe html? All html is safe. Certain extensions to embed content are not safe, such as embed and script, but html itself is safe. So basically, you just want to be able to include third-party html, but only html, no other content. How is that hard to filter?
a) Wikipedia is not a math journal
b) Subsequently, how do you know it's correct? Wikipedia does not have the peer review of a math journal.
c) Long proofs like this are more appropriate for the Wikipedia books project, not Wikipedia itself. Articles are supposed to be summaries.
I can sympathize with your plight, as there are many CS papers I'd like to read that are unavailable online. Still, Wikipedia cannot stretch itself too thin. Do one thing well, even at the expense of other useful things if necessary.