[xwiki-devs] [Proposal] Define our security requirements.
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. 2. Users should not be able to commit changes to the database except through the saveDocument function. 3. Users should not be able to save documents without their name as the author or contentAuthor as applicable. 4. Guests should not be able to execute server side script except that which was written and saved by a user. 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
Hi Caleb, hi all, Although I am currently a bit far from the current development stage of XWiki, I would like to support this and any other initiative that depicts the security properties of XWiki. When talking about wiki technologies with colleagues mainly from the biomedical arena, wiki's security is their main concern. In general, wikis are considered "open environments" where anybody can read and/or modify contents. In general they are not aware of the possibility of using platforms as XWiki for enterprise levels developments with a high level of security and access control granularity. I understand that at some extent XWiki security relies on the security settings of the web server, application server and database used. Even in this case, I think it will be really useful and welcome a page/pages maintained by the XWiki team that could be used to explain how secure is this environment. Ok, any of us, as Caleb did, can start this effort! Thanks for your work, Ricardo Caleb James DeLisle wrote:
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. 2. Users should not be able to commit changes to the database except through the saveDocument function. 3. Users should not be able to save documents without their name as the author or contentAuthor as applicable. 4. Guests should not be able to execute server side script except that which was written and saved by a user.
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ricardo Rodríguez CTO eBiotic. Life Sciences, Data Modeling and Information Management Systems
On Apr 17, 2010, at 8:15 PM, [Ricardo Rodriguez] eBioTIC. wrote:
Hi Caleb, hi all,
Although I am currently a bit far from the current development stage of XWiki, I would like to support this and any other initiative that depicts the security properties of XWiki.
When talking about wiki technologies with colleagues mainly from the biomedical arena, wiki's security is their main concern. In general, wikis are considered "open environments" where anybody can read and/or modify contents. In general they are not aware of the possibility of using platforms as XWiki for enterprise levels developments with a high level of security and access control granularity.
I understand that at some extent XWiki security relies on the security settings of the web server, application server and database used. Even in this case, I think it will be really useful and welcome a page/pages maintained by the XWiki team that could be used to explain how secure is this environment.
FWIW a page was started here: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Security I know it doesn't cover all that Caleb has mentioned but it's a start and we can continue the effort. -Vincent
Ok, any of us, as Caleb did, can start this effort!
Thanks for your work,
Ricardo
Caleb James DeLisle wrote:
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. 2. Users should not be able to commit changes to the database except through the saveDocument function. 3. Users should not be able to save documents without their name as the author or contentAuthor as applicable. 4. Guests should not be able to execute server side script except that which was written and saved by a user.
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ricardo Rodríguez CTO eBiotic. Life Sciences, Data Modeling and Information Management Systems
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Vincent! Vincent Massol wrote:
On Apr 17, 2010, at 8:15 PM, [Ricardo Rodriguez] eBioTIC. wrote:
FWIW a page was started here: http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Security
I know it doesn't cover all that Caleb has mentioned but it's a start and we can continue the effort.
-Vincent
Sorry! I forgot to add this a another page I've found before posting my previous message! This other one perhaps could be deleted to avoid duplications... http://www.xwiki.org/xwiki/bin/view/AdminGuide/Security WDYT? -- Ricardo Rodríguez CTO eBiotic. Life Sciences, Data Modeling and Information Management Systems
On 04/16/2010 11:53 AM, Caleb James DeLisle wrote:
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
-- Sergiu Dumitriu http://purl.org/net/sergiu/
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:
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.
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?
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
participants (4)
-
[Ricardo Rodriguez] eBioTIC. -
Caleb James DeLisle -
Sergiu Dumitriu -
Vincent Massol