RE: SELinux for embedded devices...

["Lorenzo Hernández García-Hierro" <lorenzo@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 5567 bytes --]

El vie, 29-07-2005 a las 10:17 +0530, Sriram, Kannan escribió:
> Lorenzo,
> 
>  First of all, thanks for the tip and insights!

My pleasure.

> > Also, what do you mean my "tamper-proof" in this context? Physically
> > protecting the chip which serves as storage for it? That sounds strange.
> 
> By tamper-proofing, I mean that the kernel image that is on the flash
>  device cannot be altered - any image on the flash (bootloader, kernel,
>  etc) carries a cryptographically signed certificate (by the OEM of the
>  phone, using private key, of a public/ private pair), and the system
>  does not boot up if the certificate of the image is invalid. A "trust
>  chain" is constructed this way - boot ROM (not alterable)
>  authenticates the boot loader, boot loader then authenticates the
>  kernel and so on...

Well, I have some doubts on this. I'll try to organize the questions
from most trivial ones to others with more complexity.

 1) What type of firmware, engine or booting system you can use that:
reads a key (even PKI-inspired/based), checks boot media integrity, boot
loader turns control over the real boot loader which loads kernel at
memory, and then you're done? Apart of the complexity of such approach,
I seriously doubt it's reliable both technically and in terms of
available resources. That is, how do you want to do this in a embedded
device such a smart-phone or those with a very limited memory and
processing capability? Simple things tend to be less prone to errors...

 2) On the other hand, we have a certificate which is stored in the same
"image" (the term sounds quite confusing to me in this context) as the
kernel being loaded. What about poisoning the certificate?  Also,
against what you will certify the trustworthiness of the certificate
itself? If it relies on internal data it might as well accessible for
poisoning.

 3) How do you separate firmware, kernel image, file-system data and
integrity verification engine + data?


> Are their any caveats to this? If I can make the root to be a
>  non-privileged user, how can kernel modules be insmod'ed? 

They shouldn't be introduced in kernel space after initialization.
Loadable kernel modules are weak by design and common target of a wide
range of infection/injection techniques which go from redirection
(hijacking) internal functions to other weird things like run-time
kernel patching.

Anyways, users with access to the sysadm_r role would be allowed to do
such operations.

> Sorry, I
>  know I can dig through the sources and find out how this is handled,
>  but any handholding at this study stage (for me) would be very
>  helpful.

Well, the documentation is maintained at the NSA website section for
SELinux and it's quite well structured, enough to make it a straight
forward reading. It's best to read the documentation first and then come
with concrete questions which we (everyone of us, subscribers of the
list, etc) can answer properly.

> Should I be creating one more privilege level and assign it
>  to a "central authority", purely for dealing with the setup and
>  configuration of the security policies itself (for example, the
>  network operator/carrier or some such entity)?

SELinux is not about a CA-based model, in any case.
You should just rely on roles. For example, security officer, user,
admin, operator, etc. I think you should mature your idea a bit more. It
might be an interesting literature for the case, the Simone
Fischer-Hübner  privacy model documentation (it's always good to talk
also about others' projects when they are well-done) already implemented
by the RSBAC folks. Sidenote: RSBAC hasn't been tested in the embedded
devices scenarios nor in other scenarios like multi-processor machines
with a certain level of complexity.

> Pls note that we are
>  trying to make the person with "physical access to the system" to be
>  able to do whatever a "privileged user" can do, but at the same time,
>  just not give enough power for configuration of the security policy
>  itself, without authorization.

Ironically, someone with physical access to the device can do literally
anything with minimal knowledge on electronics. As I said, everything is
important when talking about security, and more with the physical
factor. I would recall on Nokia and Siemens as examples. They don't
apply the typical obscurity techniques to mobile phones (ie. covering
the circuits with another layer of black, opaque material. Same as the
AlphaShield manufacturer did in the past, and maybe still does. It's
weird but works).

You need to truly assure both software-level and hardware-level
security.

> Does SELinux require a writeable filesystem always?

Try to remount / as read-only in any machine, be it running SELinux or
not.

>  What if I want to use CRAMFS which is a ReadOnly system? 

CramFS is not intended for this, nor others like SquashFS. I don't know
a lot about these file-systems, anyways. I just know they're not for
your purposes.

> Also, do you
>  think that filesystem related issues will be the most important issues
>  to live with? 

One of the most important ones, definitely.

> I'm asking this because there are only a countable
>  number of FS variants for embedded systems AFAIK, so we can *maybe*
>  take them on one at a time.

Or end up doing one at our own...

Cheers,
-- 
Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
[1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]