Security Issues Summary

Problem Summary

The major issue that keeps security group awake is maintenance of the integrity of the client. There has been a lot of talk about agents, extensibility. All these features need to be implemented securely.

The other major issue is that the current security guy is not going to cut it for implementation, and would like to get a replacement ASAP.

Brief History

The current plan is that all extensions to Chandler will be implemented in Python. Python is not a secure language. Making it such might be a very large project.

Extensions cannot be sandboxed in insecure languages. Every extension is a superuser, and has access to your entire machine. Every installation of an extension can potentially open a security hole. Therefore, installation of scripts should be infrequent, (comparable to installing an application on your PC).

Some features under discussion relied on frequent extension installations (email filters). We need to decide:

• Can Chandler live with the limitation that extensions are installed rarely (only as new parcels)
• if we can't, we need a sandbox-able scripting language.

Issue Summary

• Can we live with the limitation that scripts are installed infrequently?
• If not, what is our stragegy for a sandboxed language?
• How do solve the security issues around code sharing?

Risks

• designing features that can't be implemented due to security considerations.
• ending up without the functionality we'd really like to have
• shipping a client that needs to be made less secure for full access to features
• we need to fill our security position with a security expert

Known Answers

• Making Python a secure language is a hard, maybe too hard, problem
• Hire a security guy!

-- AleksTotic - 16 May 2003

---

Discussion

This doesn't mention anything about authorization or encryption. Is that because we believe those are be snakes? I feel like there is at least a staffing problem which would raise them to "snake" status.

• You are correct. We have a staffing problem. Our current security guy is not going to cut it for implementation. I've modified the document to reflect this. AleksTotic - May 19 2003

-- MichaelToy - 16 May 2003

---

It's not just email filters, it's also agents as a whole. Email filters are probably going to be implemented as a subset of agents.

-- DuckySherwood - 16 May 2003

---

Zope maintains a distinction between Python filesystem products, which can do anything, and Python scripts in the ZODB, which use a limited subset of Python for security.

Zope Script API documentation

-- TomHoffman - 17 May 2003

It sounds a little alarmist to say that "Every extension is a superuser, and has access to your entire machine." Users shouldn't be running Chander as root/Administrator, thus that's not literally true. All a bad extension could do is delete your entire home directory...

-- WesFelter - 28 May 2003

Security is not about what you do, but how you do it.

Will there be a location where agents can be registered? This would provide one way to ensure there is some accountability for the code. While this is not perfect it could allow others to test or audit the agent and post their thoughts for compairson before installing. The agent to be installed would be compared against the MD5/SHA1 of the agent listed on the site. For agents that are not listed, Chandler might have the option of sending an IM to a trusted source asking if they would review it (I do not imagine the agents will be that big).

The only sure way to deal with this is education of the user and tools to help them in the process of validating the software.

-- WaynePierce - 09 Jun 2003