Steve's Views Rotating Header Image

July, 2007:

Why not to give admin or root access by default

[This is a reply to why setting your OS to give admin (root) access without a password on your computer is a not a good idea. It appeared on a Pardus review.]

Your argument is very understandable and is shared by most people. Not to be flippant about your knowledge, but it is from a very limited understanding of security, or shall we say how computers are hacked.

For example, needing to enter a password means that a remote hole in an application running as non root will not have root access automatically.

Thinking you are secure when you really don’t know what makes something insecure is folly.

Breaking into a computer it’s not done by “playing by the rules”. But is done by doing things “wrong”. As an example, back when IP firewalls came out they had rules about who’s allowed access simply by IP.

The firewall has to allow replies to requests back in or is useless. So it looked to see if the inbound packets followed the TCP rules of a reply, and if so allowed it access. That was broken by not following the standard TCP rules and they in effect gained access by saying here’s your reply. The firewall allowed the new connection thinking it was a reply.

After that we got stateful inspection which tracks outbound requests, and can therefor tell if a reply originated from an internal request or not. This is a very old example but the principle still holds true. Holes are found by doing the unusual and often wrong thing.

Take buffer overflows, they have been the most commonly used method. Which consists of writing a lot more information into a field than is expected. The poorly written program cannot process the extra information and they end up someplace in memory where it is executed, resulting in illegal access. This is a simplified view but still holds true.

When you think security, unless you have actually seen not one but how many illicit accesses are gained, don’t make the mistake in thinking that you even have a clue of what is or is not secure. It takes a LOT more than that. What’s even worse is that new holes are discovered all the time. Thus, you need to think in concepts of secure methods. Security becomes not if they can get in but finding the balance of secure vs productive methods of operating. Adding multiple levels of secure behavior with the final level being users who follow the established rules and has some respect for it all.

Look up some challenge when someone said we’ll pay you X dollars if you can break in. Then see how they did it. There were f.ex. a challenge on a shopping cart where it had some 600,000 attempts with a few successful entries. They were so ingenious nobody not experienced in real hands on hacking would have figured it out.

A bad but typical poor security example is from the early days on NT. Microslop claimed NT had received a government security rating. What they did not tell us was it required that the floppy and network card was disabled.

This false sense of security was then promoted by others, like those who wanted to defend their poor choice in OS or with an inflated self importance, by promoting how secure it was. Subsequently others who knew they themselves did not understand security listen to those who knew even less and believed they actually had a secure OS.

Security is a pain in the butt, which simply has to be balanced with the pain of loosing confidential info or loss of operation, and must not be done by coffee shop security wanna bees.

At the very best you end up shooting yourself and others in the foot with your ignorance. There are plenty of places where you can find discussions by pros discussing holes in various programs and what not. Spend some time with them and get a feel of things. (See Full disclosure, bug track. Crypto-Gram by Bruce Schneier is a very informative list for a layman. You’ll find good links and info on
Good luck!