Security issue for fluidinfo-hosted web-apps
Daniel A. Nagy
With the current security model, all web applications used by a certain
fluidinfo user can access the data of all other web applications.
I do not have an elegant solution for this problem, but it should be
somewhere along the lines of a "limited authorization", where user
permissions are only granted for tags within a certain namespace; for
all other tags, the user is treated as anonymous. For example, accepting
user names that have namespaces in them, like epointsystem/scada with
the same password would help. It is not a perfect solution for many
reasons, but maybe you can come up with something better.
Regards,
--
Daniel
Nick Radcliffe
On 23 Jul 2011, at 09:57, Daniel A. Nagy wrote:
> Hello,
>
> With the current security model, all web applications used by a
> certain
> fluidinfo user can access the data of all other web applications.
Hi Daniel
This seems slightly circular to me. The permissions system has to
operate in terms of some notion of a user, and the level it chooses to
operate at is the natural one---a Fluidinfo user. If you want
different applications to have different permissions, why wouldn't you
just use different users for them?
To take your example, why not epointsystems.scada or
scada.epointsystems or epointsystemescada as a user, for example?
If the issue is that you want some overarching epointsystems user to
be able to access everything, you can arrange that a couple of ways,
either by granting permission for epointsystems.scada to write into a
namespace under scada (e.g. epointsystems/scada) or, conversely, by
allowing epointsystems to write data under opointsystems.scada.
Admittedly this is less convenient than it might be today (because
there is no permissions inheritance at all), but this will change soon
since we will be changing things so that tags and namespaces inherit
permissions, at the time they are created, from their parent namespace.
Perhaps I'm misunderstanding, but unless there's a strong reason not
to use different users, it seems to me the system already supports
what you are asking for.
Regards
Nick
Nick Radcliffe
Sorry, two typos in my reply, which could be confusing. Corrected
below.
I also realised that in even in advance of the permissions changes,
the /policies endpoint can be used to allow epointsystems consistent
access to everything under a new epointsystems.scada user.
The previous mail should have said:
On 23 Jul 2011, at 09:57, Daniel A. Nagy wrote:
> Hello,
>
> With the current security model, all web applications used by a
> certain
> fluidinfo user can access the data of all other web applications.
Hi Daniel
This seems slightly circular to me. The permissions system has to
operate in terms of some notion of a user, and the level it chooses to
operate at is the natural one---a Fluidinfo user. If you want
different applications to have different permissions, why wouldn't you
just use different users for them?
To take your example, why not epointsystems.scada or
scada.epointsystems or epointsystemescada as a user, for example?
If the issue is that you want some overarching epointsystems user to
be able to access everything, you can arrange that a couple of ways,
either by granting permission for epointsystems.scada to write into a
namespace under epointsystems (e.g. epointsystems/scada) or,
conversely, by allowing epointsystems to write data under
epointsystems.scada. Admittedly this is less convenient than it might
be today (because there is no permissions inheritance at all), but
this will change soon since we will be changing things so that tags
and namespaces inherit permissions, at the time they are created, from
their parent namespace.
Perhaps I'm misunderstanding, but unless there's a strong reason not
to use different users, it seems to me the system already supports
what you are asking for.
Regards
Nick
>
Daniel A. Nagy
> If you want
> different applications to have different permissions, why wouldn't you
> just use different users for them?
Because registering a new user is too expensive.
--
Daniel
Xavier Noria
Can you put a concrete example of the use case you have in mind? Of
course if an application or person has your credentials, they are you
from the permissions system viewpoint.
Daniel A. Nagy
> Can you put a concrete example of the use case you have in mind? Of
> course if an application or person has your credentials, they are you
> from the permissions system viewpoint.
Suppose you have a notepad application that stores text notes in
fluidinfo and you have a financial application that stores transaction
ledgers. Now, if the author of the notepad is malicious, he can steal
your financial data without you ever noticing, just because you are
logged in.
--
Daniel
Xavier Noria
<nagy...@epointsystem.org> wrote:
> Suppose you have a notepad application that stores text notes in
> fluidinfo and you have a financial application that stores transaction
> ledgers. Now, if the author of the notepad is malicious, he can steal
> your financial data without you ever noticing, just because you are
> logged in.
Sure, but that's expected behavior. If you later access your account
using the Perl module Net::Fluidinfo, whose author is a suspicious guy
I am told, that library will be able to steal your financial data as
well. There are lots of ways to access your account besides
self-hosted web applications. And if you give credentials to them, you
are implicitly trusting them.
The situation is similar to the one in a computer. If you're logged
in, all applications have access to all your files. So the apparently
innocent MyNotes freeware can steal your Quicken data. We run in that
environment everyday.
Users can grant/deny permissions on their stuff to other users, and
with a fine-grained configuration level. A mechanism to control access
for pairs user/application is there in that form (as already
mentioned).
Nick Radcliffe
>> If you want
>> different applications to have different permissions, why wouldn't
>> you
>> just use different users for them?
>
> Because registering a new user is too expensive
> On 07/23/2011 04:08 PM, Xavier Noria wrote:
I'm not sure whether I've understood you correctly, but if I have, it
doesn't need to be like that.
A user can absolutely grant one application access to one subnamespace
and another access to a different subnamespace without their being
able to read each other's data.
If I create namespaces njr/spreadsheet and njr/notepad and set all
permissions on the first to
closed except ["njr", "spreadsheet"]
and on the second to
closed except ["njr", "notepad"]
then the Fluidinfo users spreadsheet and notepad won't be able to read
or write each others' data. (The is a small gotcha at the moment,
that when notepad or spreadsheet create new data under your
subnamespaces, they will end up with control permission over it, not
you, but (a) they can give it back and (b) that will be fixed by the
create-time permission inheritance that's being implemented right now.
This does require different user accounts for different apps, but not
one per user per app.
If that isn't the situation you mean, I don't really understand the
"too expensive" comment: developing any kind of app seems very
"expensive" compared to creating a Fluidinfo account.
Regards
Nick
Daniel A. Nagy
On 07/23/2011 04:52 PM, Xavier Noria wrote:
> On Sat, Jul 23, 2011 at 4:20 PM, Daniel A. Nagy
> <nagy...@epointsystem.org> wrote:
>
>> Suppose you have a notepad application that stores text notes in
>> fluidinfo and you have a financial application that stores transaction
>> ledgers. Now, if the author of the notepad is malicious, he can steal
>> your financial data without you ever noticing, just because you are
>> logged in.
>
> Sure, but that's expected behavior. If you later access your account
> using the Perl module Net::Fluidinfo, whose author is a suspicious guy
> I am told, that library will be able to steal your financial data as
> well. There are lots of ways to access your account besides
> self-hosted web applications. And if you give credentials to them, you
> are implicitly trusting them.
Right, except that your web browser automatically gives them your
credentials, without asking you.
> The situation is similar to the one in a computer. If you're logged
> in, all applications have access to all your files. So the apparently
> innocent MyNotes freeware can steal your Quicken data. We run in that
> environment everyday.
Yes, the situation is very similar, but with one crucial difference: you
decide what software you install on your computer, but you have no
control over what self-hosted software is installed in fluidinfo and it
can be updated without your knowledge.
Actually, even within a single computer that security model is becoming
obsolete. Note that on Android, each application has its own unix uid
for a good reason.
> Users can grant/deny permissions on their stuff to other users, and
> with a fine-grained configuration level. A mechanism to control access
> for pairs user/application is there in that form (as already
> mentioned).
Should I register a separate user before I start using an application?
That's too expensive, as I have already stated.
Regards,
--
Daniel
Daniel A. Nagy
On 07/23/2011 05:48 PM, Nick Radcliffe wrote:
> A user can absolutely grant one application access to one subnamespace
> and another access to a different subnamespace without their being able
> to read each other's data.
I am talking about applications hosted within fluidinfo that run on the
user's browser: all static web content and javascripts are also hosted
inside fluidinfo as opaque tag values. In this case, you cannot grant or
deny access to the application. Or am I missing something?
Regards,
--
Daniel
Nick Radcliffe
Right, I see what you mean. Yes, I agree, if you give each
application the user's Fluidinfo credentials, obviously those apps can
all do everything that the user can do. Ideally the apps would
authenticate as themselves, just getting relevant permissions from the
user, but I guess in javascript it's hard to see how they could get
app-specific credentials safely.
Nick
Xavier Noria
<nagy...@epointsystem.org> wrote:
> Right, except that your web browser automatically gives them your
> credentials, without asking you.
Can you elaborate? Are you concerned about the possibility that you
accidentally visit a malicious self-hosted web application that reads
the cookies set by another application?
Daniel A. Nagy
Not (just) the cookies. Once you log into a website using Basic Auth,
your browser will attempt to use the same credentials for that host,
meaning that a malicious self-hosted web-app can actually read and write
my tags in fluidinfo.
--
Daniel
Xavier Noria
<nagy...@epointsystem.org> wrote:
> Not (just) the cookies. Once you log into a website using Basic Auth,
> your browser will attempt to use the same credentials for that host,
> meaning that a malicious self-hosted web-app can actually read and write
> my tags in fluidinfo.
Alright, I see what you have in mind now.
Yes that's true. Applications should not require you to use Basic
Auth. Also the path restriction to access cookies can be overcome with
some techniques. I don't know which other secure options they have
except asking credentials per request.
Self-hosted web applications are a nice side-effect of the design of
Fluidinfo. The good use of HTTP, REST, etc. but in my view they are a
curiosity. You know they can't run code in the server side. Only
static stuff with client-side code at most.
Because of that, I think self-hosted websites that require
authentication are going to be rare. And I think they should not
influence the design of Fluidinfo at all. (Only expressing a personal
opinion, I am not involved in Fluidinfo.)
