security on linux embedded

In the same way as you do it with normal Linux. There is nothing special about embedded Linux. Read a good book on Linux system administration - you need to know about file attributes, users, groups, etc.

The kernel contains a firewall. For an embedded system you probably need to (cross-) compile the netfilter utilities to use it.

The security measures depend very much on what the intended function of the system is.

Kind regards,

Iwo

If you need extended security you might want to take a look at PikeOS by SYSGO. Same creates multiple "Partitions", that are protected against each other. In each partition an OS (e.g. Linux) runs. If one partition crashes, the others are not effected.

-Michael

Because the system is known and people can see the source, holes tend to be discovered quicker and fixed. A proprietary closed source product may have all sorts of holes - you simply don't know - and have no way of closing them, relying on the supplier to produce timely fixes (if at all).

My question was more generic. Nowadays linux is embedded in a lot of devices, I'm not the first one that use it in this way. So I'd like to know from people that have used linux embedded before me, how they faced up to the security problem.

Assuming that there really is a security problem, you fix it. You've got the source, you can do it. In fact, because of this, someone has probably done it already.

None of the standard network security features require obscurity to be safe. The secret is normally entirely contained inside a key or a password.

The different protocols have well known features and limitations.

If you want to create a secure embedded device, you use exactly the same techniques as you would for a webserver, for instance. You select the correct protocols, you switch on the DOS defenses and make sure you don't offer more services than you need to.

And don't forget to allow for field upgrades, in case someone finds a problem after you shipped the device. Security is a moving target.

Kind regards,

Iwo

Right. On the contrary obscurity is unsafe as it prevents closing safety holes.

But Linux is huge and thus there is much room for safety hole and there always are undetected ones. So using something very small and revisable for super-secure stuff seems recommended. If you need some of the great Linux features using two or more systems on the same or on different hardware might be the way to go.

-Michael

|> None of the standard network security features require |> obscurity to be safe. | | Right. On the contrary obscurity is unsafe as it prevents closing safety | holes. | | But Linux is huge and thus there is much room for safety hole and there | always are undetected ones. So using something very small and revisable | for super-secure stuff seems recommended. If you need some of the great | Linux features using two or more systems on the same or on different | hardware might be the way to go.

Typical PC distributions tend to be insecure because they are made for people that want to see everything "working" as soon as the install is done. So the distro installs most daemons _and_ sets them (usually all) to start up on boot, often with little or no specification as to who can get in and what they can do (too often being anyone to do anything).

Your embedded system is going to be customized (by you) to do only the things you intend it for. Anything else: don't run it or don't install it.

Most security holes are in userland programs. The kernel itself has few if any because of relatively little handling of network bits. And what it does handle is looked over by a lot of eyes. And that is generally at layers where there isn't much opportunity for exploitive payloads.

You know what your embedded goal is. Do that and no more than that. Then focus on those programs for security aspects.

| Because the system is known and people can see the source, holes tend to | be discovered quicker and fixed. A proprietary closed source product may | have all sorts of holes - you simply don't know - and have no way of | closing them, relying on the supplier to produce timely fixes (if at all).

To elaborate on this:

Closed source does not prevent people from discovering holes or even fixing them. But, not having source means whatever you do is a big binary hack and very ugly (and very hard for the average programmer to do; worse for the average system administrator). To the hacker, ugly is an advantage. Exploits don't use source code (historically I have seen a couple that do, but that's 2 out of tens of thousands).

Closed source: Hacker: a little slower to make an exploit Admin: a LOT slower/harder to fix it, forcing vendor dependence Open source: Hacker: a littler faster to make an exploit Admin: a LOT faster/easier to fix it, with the advantage of a community that can do it, not just a vendor

The embedded scenario will be harder to work with due to the need to redistribute the fix since embedded users won't generally be in any position to deal with it. But embedded also has the advantage of not having to deploy a full-blown host system, focusing instead on the exact application intended. It's probably a break-even and depending on the application, perhaps a net advantage.