We have a bit of a design problem in that we want the FB to be very secure, but also to require a minimum of system administration.
Our security requirements are very high. People might be jailed or even killed if security on these machines is broken. For example, Zimbabwe recently jailed a bunch of people for downloading Internet reports on the Tunisian revolution and discussing them. There have recently been attacks on various systems that were attributed to state-level actors, The Stuxnet worm, the "Aurora" attack an Google and others. If FB gets anywhere near its design goals, such attacks on it are not just likely, but virtually certain. This means attacks by professionals with large resources. On the other hand, we really want the machines to require almost no system administration. John Gilmore gave the reasons in another thread, and he is quite correct. That creates a problem because in general, security requires alertness. No safe is uncrackable if the attacker can take hours and use explosives and a welding torch without being noticed. Computers tend to become insecure if the admin is "too busy" to check the logs or to download and apply security updates. To some extent, we can automate around that, for example by making updates automatic. The current system of PGP-signed upgrades looks like it gives all the security needed. Should we do something like one or more "oil lights" for the end user? An expert mechanic has many ways of understanding automotive problems, most of which are beyond me. However a little red light on the dashboard that comes on when oil pressure is low can alert me to one group of problems. All I have to know is to check the dipstick if I see that light, and if it comes on when the oil level is OK, find a mechanic pronto. This becomes a documentation problem. To use a car I need neither engineering training nor the skills of a mechanic, but I do need to know some things. It is a good idea to change the oil every so often and a bad idea to rev the engine past the red line, and so on. What are the basic things an FB user needs to know? Can we get those documented and then translated? Could an intrusion detection system provide the right "lights" here? If not, what? One standard tactic for achieving security is to restrict the applications that run on the box. Only things approved by corporate IT, or whatever. The FB is Debian-based which gives a huge range of choices, and that is basically a fine thing. However, it might also be useful to have a list of default or recommended choices. It might even be good to have FB-only repositories which do not offer the whole Debian range, of course with an escape for experts to add the Debian repositories and get what they please. Another standard method is to not allow user logins. In a corporate situation, only the admins have user IDs on the mail server or the firewall, not the end users. In my house, visitors can use my router but they cannot log onto it. Applying that to FB automatically gives some restriction on applications. The FB might run a web server or cache, but not a browser, a mail server but not a user email agent, and so on. It seems to me that is the way to go, but I would like to know others' opinions. In particular, does taking that approach restrict what the box can do in any way that leads to problems in achieving its goals? Enough for now. Second post to follow. _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
