Magma must have security or it will never work directly on the Net. I hope KryptOn will prove a good basis for this, but I have reached a point where detailed choices have me struggling about where to balance transparency and security.
For the most part, I have used the Croquet suggestions for my guide:
http://minnow.cc.gatech.edu/squeak/3770.
But let me draw attention to my specific matter of contention.
"- Security needs to be largely invisible. The Diablo trading system, referred to in earlier email, points the way.."
and,
"I would suggest going with a system that always encrypts automatically to see how you like it. Even if you decide to build in a way to circumvent encryption from the first day, I would urge, on my knees, that sending data unencrypted require an explicit and highly visible coding change such that the default, easiest path to communication is indeed encrypted, and both original programmers and later reviewers can immediately spot digressions from the secure communications. I have a number of tragi-comic stories about people who knew they were using strong encryption ... except they were actually sending cleartext. Perhaps the requirement should be, do not add to the collection of funny stories :-)"
Now, I searched for info about Diablo II's trading system but couldn't find any details; just stuff about the "paladins" and "mages" and stuff.. Anyone know where a good description of their trading system?
Notwithstanding that, I am specifically torn on the idea of "always on" security because, ultimately, requiring the user to say, "useSecurity: false" is where the transparency ends. However maybe not. Maybe the user assumes POLA, since maybe what they expect by transparency is "the computer reasonably takes care of me as best it can even if I all I do is take care of my physical computer.".
To put it in Magma terms..
Every repository created will require Capabilities to access it. Now, if you don't want to deal with security at all, it can put these capabilities in the default directory automatically. This is essentially laying the golden key right on top of the treasure chest, but it seems merely to extend the non-secure area from the confines of the image to the physical computer.
IOW, you could still expose the repository on the net and only you could access it. But to do that you need to remember to bring the Capabilities with you to connect remotely so some awareness of security is required anyway, its not fully transparent.
So lately I'm thinking this attempt to eat my cake and have it too is fruitless. Either the user will have to be somewhat aware of security or there should probably be no security. I need to choose a more definitive philosophy:
always on? default on, allow turning it off? default off, allow turning it on?
Comments or advice greatly appreciated..
- Chris
Chris Muller wrote:
So lately I'm thinking this attempt to eat my cake and have it too is fruitless. Either the user will have to be somewhat aware of security or there should probably be no security. I need to choose a more definitive philosophy:
always on? default on, allow turning it off? default off, allow turning it on?
My preference: "default on, allow turning it off".
I'm quite happy to have security be a little bothersome (nothing costs nothing, right?). I use ssh and https extensively, and find them both quite usable once they're set up correctly. ssh is extremely easy to set up; https is quite tricky (because of the fact that certificates are signed by an external CA, which requires a CSR, and so on).
The best way to mitigate user-frustration is to have the process be as simple as possible but no simpler, have great documentation available on the web, and make the system as easy to fault-find as possible.
Also, the fact that there are several extra steps required to activate the security features gives it an aura of "we are serious about this stuff" :>
Bruce Schneier would probably dismiss this as "security theatre", but my experience is that
- if it is totally easy to turn on security, then people still mess it up. - if it is totally impossible to turn on security, no one uses it. - if is is slightly hard, people use their brains when setting it up.
Andrew
Andrew Gaylard ag@computer.org wrote:
Chris Muller wrote:
So lately I'm thinking this attempt to eat my cake and have it too is fruitless. Either the user will have to be somewhat aware of security or there should probably be no security. I need to choose a more definitive philosophy:
always on? default on, allow turning it off? default off, allow turning it on?
My preference: "default on, allow turning it off".
I am fine with either with the two last choices - *as long as you can't miss the fact that it is ON or OFF*. Otherwise you will get:
- People complaining about performance (not realizing it is ON and they don't need it). - People suddenly realizing they are unsecure (not realizing it is OFF and they thought it was ON)
So just pick a default and somehow SHOW that it is ON or OFF. Not sure what Magma has in the way of showing things - a log somewhere? Or perhaps a blody one time confirm popping up or whatever. Or HUGE letters in the first page in the manual, that works too. :)
Or as I do in HV - I have two methods for starting a web app:
MyAppView start
or: MyAppView startDebug
...that way it is clear. It could be even clearer if it was #startNoDebug instead of #start :).
regards, Göran
On 11/10/05, goran@krampe.se goran@krampe.se wrote:
So just pick a default and somehow SHOW that it is ON or OFF.
At the InternetOne, the background for our deployment server was red, for the test server green :)
On 11/10/05, Chris Muller chris@funkyobjects.org wrote:
Magma must have security or it will never work directly on the Net.
Well, you are free to do as you like with Magma, but I could not care less. I'm not even sure it'd be nice to have security in Magma, and if so - please make it optional.
"I would suggest going with a system that always encrypts automatically to see how you like it..."
Now, that's the sort of stuff that makes me cringe. Crippling local network speed by encrypting everything. It's still hard for a CPU to saturate network bandwidth on an ecrypted link, and for high-performance applications can well do without that burden.
If you really insist on adding it, I would strongly suggest that you create latent security in the server (iow - the server can accept by default both clear and encrypted links and a policy setting could always disable the cleartext bit) and a secure client as an alternative to the default.
But what's the idea of exposing a database to the internet anyway? I really can't think of a reason. I'd never in my life do it.
Case in point - the last project I setup where security was anywhere on the requirements list we didn't even expose the database to the webserver. Instead, we allowed access to the database only from localhost, and on that host we ran a basic apache server and every query that the webserver wanted to do got wrapped in an xml-rpc service in that apache server.
So for security analysis on that site, we don't need to go through lengthy evaluations of database-level security (or even table-level or row-level, both absent in Mysql anyway ;)), we simple do 'more *' in the XML-RPC service directory and get a list of queries that are allowed.
This sort of stuff does not, IMNSHO, belong in a persistence engine. Not even an object persistence engine. Persistent objects don't usually form the application layer.
But then, prove me wrong. I liked to be proven wrong if it makes life simpler for me ;)
Thanks for the feedback. Certainly, if performance is significantly affected then that will be a major factor in the decisions. But, I will note that having already run my benchmarks with capability-verification enabled for a local server has had NO EFFECT on performance. Local is how most of the web servers will be running, so I should have asked for your feedback with the stipulation, "assuming no effect on performance," where should transparency be balanced against security..?
I'm not even sure it'd be nice to have security in Magma, and if so - please make it optional.
As long as you have the same transparency you have now and the same speed you have now, why wouldn't it be nice to have security?
Now, that's the sort of stuff that makes me cringe. Crippling local network speed by encrypting everything. It's still hard for a CPU to saturate network bandwidth on an ecrypted link, and for high-performance applications can well do without that burden.
I have worked hard to make Magma perform reasonable. Rest assured, I'm not about to throw that out the window in the name of mandatory security.
But what's the idea of exposing a database to the internet anyway? I really can't think of a reason. I'd never in my life do it.
A Maui interface to the Nags domain could be built in half the time it took to do the Seaside interface, and I get to stay in Squeak to use it (ok, so could you if you want to use Scamper). By using remote connection to Magma and opening port to the Net, you can support web and Maui users simultaneously. Not only that, Maui users can customize their UI's to their personal taste and choose to share them or not with others very easily..
Magma is not just about having centralized repositories behind "applications". Its also about using personal repositories to share objects with others.
This sort of stuff does not, IMNSHO, belong in a persistence engine. Not even an object persistence engine. Persistent objects don't usually form the application layer.
I'm not sure I understand. I think you *need* security in the db. If an attacker gains access to your db files then you become another story like we've been hearing from companies in the US lately, that had their customer personal information compromised in some way.. This cannot happen (hopefully) with what I'm doing with Magma, the only sensitive information ever exposed is in object-memory.
Three-tier is fine for corporate / web. IMO two-tier is better for personal / distributed objects.
But then, prove me wrong. I liked to be proven wrong if it makes life simpler for me ;)
Me too, and there's no ego. I want to learn here, not "prove someone wrong"..
Cheers, Chris
On 11/10/05, Chris Muller chris@funkyobjects.org wrote:
As long as you have the same transparency you have now and the same speed you have now, why wouldn't it be nice to have security?
Err.. transparancy means I can access everything. Where's the security, then?
I have worked hard to make Magma perform reasonable. Rest assured, I'm not about to throw that out the window in the name of mandatory security.
Good :)
A Maui interface to the Nags domain could be built in half the time it took to do the Seaside interface, [...]
Is that a challenge? ;) Anyway, Nags' interface is almost empty, most of the coding time went to developing generic develop-apps-quickly-stuff.
I'm not sure I understand. I think you *need* security in the db. If an attacker gains access to your db files then you become another story like we've been hearing from companies in the US lately, that had their customer personal information compromised in some way..
If an attacker gets access to the db files, you're hosed anyway. And bad security will always happen - I bet that the companies that screwed up had databases with built-in security ;).
I happily ran VW+OmniBase to support a business for years. We were security conscious, if you compartimentalize your network well enough the difference between internet|firewall|webserver|firewall|appserver|firewal|dbserver or internet|firewall|webserver|firewall|appserver+presistence isn't too bad.
Three-tier is fine for corporate / web. IMO two-tier is better for personal / distributed objects.
Agree there.
Summary: at the moment, I'm looking at Magma as a persistence engine below Squeak. And I like it. For *my* purposes, I don't really need security - yet. So I hope that whatever you cook up, doesn't interfere :)
At the same time, I'm interested in where you take this. So I'll shut up for new, lest you start taking my advice...
magma@lists.squeakfoundation.org