security on linux embedded

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi all, we are porting our software from RTOS to linux embedded. I'm
worried about the security of the system: virus attack, hacking...
I suppese every system connected to a local net can be attacked
whatever OS, using D.o.S. or others. But if the system is known, there
are more tecniques to complete the attack.
So my question is: how to protect an embedded system equipped with
Linux inside a lan?
I guess there were other similar topics in the past but I don't see
them.
Thanks,
Giovanni


Re: security on linux embedded

Quoted text here. Click to load it

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


Re: security on linux embedded
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

Re: security on linux embedded
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.


Re: security on linux embedded

Quoted text here. Click to load it

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


Re: security on linux embedded
Quoted text here. Click to load it

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

Re: security on linux embedded
On Wed, 20 Dec 2006 16:49:27 +0100 Michael Schnell

|> 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.

Re: security on linux embedded
Quoted text here. Click to load it

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).

Quoted text here. Click to load it


Re: security on linux embedded

| 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.

Site Timeline