6 May
2010
6 May
'10
4:29 a.m.
When I get a chance I'll start a draft on this.
I guess we should have security requirements for now and proposed security requirements
for later.
I would propose that in the future PR should not give the user absolute power to (for
example)
read and write arbitrary memory addresses or files and to load and execute native code.
That said, I think the core code should have the same permissions as PR code excepting
specific modules
which manage things like filesystem access.
Sergiu Dumitriu wrote:
On 04/16/2010 11:53 AM, Caleb James DeLisle wrote:
Is there a use case for this? I think it's nice to be absolutely sure who saved a
document.
Although I don't think PR ability to bypass this should be listed as a security flaw
now, I don't think it
should be included in future API.
WDYT?
It might sound silly but if there are no security
requirements then there are no security holes.
We all know when we see something which shouldn't happen but I don't think there
is any page
defining exactly what the security requirements are.
1. Users should not be able to spawn additional processes on the server.
They should, with Programming Rights. For example the SVN application
needs to execute SVN commands. I'd say that it would be better to secure
the server than the application. This is the reason why the container
should never run with the root account. A very secure setup should have
a proper chrooted environment running with a limited user in a virtual
machine, and maybe with a security policy in place which lists
everything that the application can do. We should just prevent data
loss/corruption/access on our side.
2. Users should not be able to commit changes to
the database except through the saveDocument function.
Agreed.
3. Users should not be able to save documents
without their name as the author or contentAuthor as applicable.
Not using the public API. With Programming Rights it is possible, and
I'd say that it should be kept this way. 4. Guests should not be able to execute server
side script except that which was written and saved by a user.
Agreed.
This list is doesn't cover much yet, I hope
to see some additions and discussion of may code may violate some
the rules as well as how we can have 'untrusted' code which is unable to violate
the rules.
I propose we put up a design page for maintenance of this list.
WDYT?
Caleb