Previous Entry Share Next Entry
Brainstorming: QL and security
querki
jducoeur wrote in querki_project
Okay, time for us to chat about one of the more interesting problems in Querki, which has been lurking in the background for a while but is slowly moving towards getting important: what are the security requirements for QL? I'm thinking out loud a little here, and looking for input and observations.

The motivating use case is QL in Conversations. I'm implementing Conversations (the comment system) now, and initially it'll just be simple text, but it's going to evolve fast. By the time the first release of the feature goes out, you should be able to use arbitrary QText inside of a comment. (This is strictly necessary -- nobody wants to type HTML paragraphs.) But in the medium term, you should clearly be able to use QL inside of a comment.

Why? Well, the simple example is linking -- remember that a link to a Thing is usually done as [[My Other Thing]], and that is a QL expression, if a simplistic one. It seems clear that you ought to be able to do something like that in a Comment: I should be able to link to any Thing that I can see.

OTOH, you clearly *shouldn't* be able to put completely arbitrary code into QL -- in particular, you shouldn't be able to use QL to circumvent read-security. Say that I have my Space set up so that Members can only see half of the Things. In that case, I don't want those Members to be able to write QL expressions that list out all of those Things, much less perform operations on all of their Properties.

(I should note, this is all true now in the case of Thing editing -- if Members can edit Things, they can currently work around Read security. So the problem I'm talking about is more general and more important than just Conversations: we're going to need to wrestle with it in order to make fine-grained read permissions really work properly.)

For the time being, it *might* suffice to simply apply the Read permissions of the author of the Comment when looking up a Thing. For instance, if the Owner of the Space chooses to do a calculation on a lot of semi-private Things, we have to presume that he knows what he's doing, and is doing that intentionally. But if a low-security Member writes the same QL expression, it should probably fail to fetch any Things that they don't have Read access to, whether by direct name, via _instances(), or via Links.

In the long run, even that won't suffice -- I'm planning to eventually enable true field-level security, so that a visible thing can have truly hidden fields. But that's a ways off, and probably lowish-priority: I suspect that it's mostly a power-user feature. For now, the interesting question is whether simply limiting the available Things based on the rights of the author is good enough. Any thoughts?

  • 1
I don't have much of a sense for the likely use-cases involved, so I can't really weight "man, I wish I could just use this QL in this comment" vs. "what do you mean I just exposed a whole mess of data that not everyone had Read access to?"

One thought: everywhere else in the system, when you write QL, you have the assurance (I believe?) that that QL will be run using the permissions of whomever's viewing the Thing. To have that not be true for comments might be deceptive.

One thought: everywhere else in the system, when you write QL, you have the assurance (I believe?) that that QL will be run using the permissions of whomever's viewing the Thing. To have that not be true for comments might be deceptive.

Actually, that isn't true now anywhere -- QL expressions just work. If you can read the Thing, you can read whatever it displays. Which is convenient, but clearly not even remotely sufficient for the long run: the implication is that anyone who has Edit access to the Space can do an end-run around read security. That's really why I decided that I have to wrestle with this problem regardless, instead of just saying, "Well, comments can't use QL and we'll just deal". (And is why the title of this post doesn't include comments: they're the immediate motivation, but not actually the *important* one. I'm not planning on allowing QL in comments until we have this well settled, but that doesn't solve the central problem.)

So set the Comments question aside entirely (since that's the least critical part), and instead think about a Space where some stuff is private, but Members have *some* limited Edit access to at least a few Things, and can thus enter QL expressions. The question is, what is the right general model for what is displayed?

And yes, the issue is very subtle, and I'm not sure I understand the tradeoffs perfectly myself. On the one hand, it seems like we should allow the Owner to compute and display expressions based on private information -- I suspect it would be unreasonably limiting not to let them do that. But yes, there is a non-trivial danger of accidental data exposure by a naive or careless user.

(Note: I've been assuming that this issue is semi-academic for the moment, on the theory that your Space isn't going to allow Members to edit and doesn't contain any crucially secret information. If those aren't correct, it may raise the priority of this problem.)

Anyway, it's not an easy problem, and in the medium term we clearly need to solve it. My Thing-access concept mentioned above might be part of the solution; something involving Instance Properties (which concept may eventually need to get more nuanced) might also get involved. But it's all pretty fuzzy at this point -- I don't feel like I have my hands around the correct principles yet...

  • 1
?

Log in

No account? Create an account