RE: SELinux for embedded devices...

RE: SELinux for embedded devices...

[Sriram, Kannan]

Lorenzo,

 First of all, thanks for the tip and insights!

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

> Under SELinux root is just another user with access to certain roles. Be
> them user_r or sysadm_r, doesn't matter, it's all your choice and you
> can turn root into a non privileged user.

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

> The problem of NAND flash chips and other flash memory components is
> that they have a limited writable times. Hence, the use of specific file
> systems is needed in order to *not* reach such limit in a short period
> of time.
Does SELinux require a writeable filesystem always? What if I want to use CRAMFS which is a ReadOnly system? Also, do you think that filesystem related issues will be the most important issues to live with? 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.

Thanks,
Sriram.




--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: SELinux for embedded devices...

[Lorenzo Hernández García-Hierro]

[-- 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 --]

Re: SELinux for embedded devices...

[Luke Kenneth Casson Leighton]

On Fri, Jul 29, 2005 at 10:17:18AM +0530, Sriram, Kannan wrote:
> Does SELinux require a writeable filesystem always? 

 no, it doesn't.

 however, nobody with the skills to add xattrs to any of
 the read-only filesystems has yet gone ahead and done it /
 had a requirement strong enough to justify adding xattrs.
 [i added xattrs to tmpfs because i really needed it and there
 were enough simple examples to copy].

 i too would like to use selinux-enabled squashfs or other
 read-only filesystem, because that's a _fantastic_ way of
 getting a secure OS.  someone's root-kitted the machine?
 oh dearie me: reboot it and you _know_ that the squashfs-based
 live boot CD will get you back up-and-running.

 yep.

 throw some money my way and i'll do it for you.

 l.
 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux for embedded devices...

[Stephen Smalley]

On Fri, 2005-07-29 at 09:44 +0100, Luke Kenneth Casson Leighton wrote:
> On Fri, Jul 29, 2005 at 10:17:18AM +0530, Sriram, Kannan wrote:
> > Does SELinux require a writeable filesystem always? 
> 
>  no, it doesn't.
> 
>  however, nobody with the skills to add xattrs to any of
>  the read-only filesystems has yet gone ahead and done it /
>  had a requirement strong enough to justify adding xattrs.
>  [i added xattrs to tmpfs because i really needed it and there
>  were enough simple examples to copy].
> 
>  i too would like to use selinux-enabled squashfs or other
>  read-only filesystem, because that's a _fantastic_ way of
>  getting a secure OS.  someone's root-kitted the machine?
>  oh dearie me: reboot it and you _know_ that the squashfs-based
>  live boot CD will get you back up-and-running.

I think that prior SELinux LiveCDs just loaded an ext3 or ext2
filesystem into ram, so the medium was still read-only, but you could
set/get the xattrs in the memory-backed ext2/ext3 fs.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux for embedded devices...

[Christopher J. PeBenito]

On Fri, 2005-07-29 at 09:16 -0400, Stephen Smalley wrote:
> On Fri, 2005-07-29 at 09:44 +0100, Luke Kenneth Casson Leighton wrote:
> > On Fri, Jul 29, 2005 at 10:17:18AM +0530, Sriram, Kannan wrote:
> > > Does SELinux require a writeable filesystem always? 
> > 
> >  no, it doesn't.
> > 
> >  however, nobody with the skills to add xattrs to any of
> >  the read-only filesystems has yet gone ahead and done it /
> >  had a requirement strong enough to justify adding xattrs.
> >  [i added xattrs to tmpfs because i really needed it and there
> >  were enough simple examples to copy].
> > 
> >  i too would like to use selinux-enabled squashfs or other
> >  read-only filesystem, because that's a _fantastic_ way of
> >  getting a secure OS.  someone's root-kitted the machine?
> >  oh dearie me: reboot it and you _know_ that the squashfs-based
> >  live boot CD will get you back up-and-running.
> 
> I think that prior SELinux LiveCDs just loaded an ext3 or ext2
> filesystem into ram, so the medium was still read-only, but you could
> set/get the xattrs in the memory-backed ext2/ext3 fs.

The Gentoo SELinux LiveCD loads up a large, ext2 labeled initrd for a
bare minimum root filesystem and a small writable area, so the user can
still set a resolv.conf, for example.  Then the remaining parts of the
filesystem are ext2 labeled filesystem images on the cd, mounted by
loopback.  Now that tmpfs has labels, that is another option, rather
then having a large initrd (in terms of writable areas).

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: SELinux for embedded devices...

[Sriram, Kannan]

> -----Original Message-----
> From: Lorenzo Hernández García-Hierro [mailto:lorenzo@gnu.org]
> Sent: Friday, July 29, 2005 3:09 PM
> To: Sriram, Kannan
> Cc: SELinux Mail List
> Subject: RE: SELinux for embedded devices...
> 
> 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...
> 

We have a hardware + software mechanism that actually does this job, and actually has cryptographic accelerators on the SoC.

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

Firmware -- bootROM, on chip (SoC)
Bootloader -- u-boot, on the flash chip. We calculate the digest of u-boot, sign it with the private key (the certificate) and append it to the u-boot image. Same for kernel image as well.
 
> 
> > 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.
> 

But what if the insmod (and friends) were designed to counter this? For example, insmod will first look for the certificate and authorize the module before loading it into the kernel proper?

> 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).
> 
Well, not really. Someone with physical access to the system, but who does not necessarily have, lets say, the device specific key, can be made to do very "restricted things" (leaving out the DoS attacks for now, nobody wants to do that on his own phone!) There's just a new paradigm here, where we don't really have an attacker vs user alone, but in the case of a mobile phone, the end user, the operator and the OEM, all working together, and yet, wanting to do "secure things".. :-)

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

Yes, very true. But assuming we have the hardware resources in place, and assuming that tamperproofing (using software certificates, and not the black/opaque material) is employed effectively, we are trying to study and find out how to best leverage what a great concept like SELinux can offer, for the kernel level security. Basically, we have already (arguably) taken care of the kernel integrity (tamperproof) but just looking at ways to seal it from the loadable modules, and the filesystem perspective.

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

Well, embedded devices typically end up having either Cramfs or JFFS2.

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

Yes, of course. I'll be glad to, once I know that I'm not reinventing the wheel. Any pointers on whether someone is working on this path?
> 
> Cheers,
> --
> Lorenzo Hernández García-Hierro <lorenzo@gnu.org>
> [1024D/6F2B2DEC] & [2048g/9AE91A22][http://tuxedo-es.org]


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

SELinux for embedded devices...

[Sriram, Kannan]

Hello all,

 I'm a newbie to SELinux, trying to figure out if SELinux is applicable/
suitable to embedded system security, especially mobile terminals/
smartphones. I have the following very basic questions... Pls help me
out, or redirect me to the appropriate forum.

1. Is SELinux applicable and suitable for mobile equipment, where the
end user always has root privileges? Has SELinux been ported to any
embedded device yet (some ARM platform??).

2. Assuming I have made the kernel on the flash to be tamperproof (can't
replace the SElinux image on the flash with the "SE" part disabled),
isn't  it still possible at runtime to disable the security server?

3. Same as above, is it possible to change the security policy files, or
reload a different set of policies (given root access).

And now the big question, is there a way to prevent both (2) and (3)??
Or have I completely misunderstood the whole thing??

Thanks in advance,
Sriram.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux for embedded devices...

[Lorenzo Hernández García-Hierro]

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

El vie, 29-07-2005 a las 07:50 +0530, Sriram, Kannan escribió:
> Hello all,
> 
>  I'm a newbie to SELinux, trying to figure out if SELinux is applicable/
> suitable to embedded system security, especially mobile terminals/
> smartphones. I have the following very basic questions... Pls help me
> out, or redirect me to the appropriate forum.
> 
> 1. Is SELinux applicable and suitable for mobile equipment, where the
> end user always has root privileges? Has SELinux been ported to any
> embedded device yet (some ARM platform??).

SELinux itself doesn't need to be ported to ARM processors, but the
file-systems in which the labeling relies.

The problem of NAND flash chips and other flash memory components is
that they have a limited writable times. Hence, the use of specific file
systems is needed in order to *not* reach such limit in a short period
of time.

Currently, there's a problem about this. Maybe you can think on ext3,
XFS, etc, and all of those nice "bullet-proof" file-systems with
journaling. The problem is that, such file-systems make an exhaustive
use of the memory/storage device they are running on with each
operation, reaching the limit of writes and thus turning the flash
memory chip unusable.

There are file systems specifically designed to be "small" and efficient
on these scenarios. Notable examples are JFFS2 and the
still-under-design JFFS3 maintained by the Linux-MTD project.

I was working on the design of extended attributes for JFFS2 (in which
SELinux relies for labeling file-system objects), even got help from an
Intel guy, but I got stuck at it, without any resources for testing, and
the Intel guy who was willing to work together with me was requested for
legal approbation before doing anything. Thus, time passed and I
couldn't go a step further on doing anything serious about it.

Someday I may re-start the little project, but that's unlikely to happen
until I get the needed time and resources for testing, designing and
implementing this.

> 2. Assuming I have made the kernel on the flash to be tamperproof (can't
> replace the SElinux image on the flash with the "SE" part disabled),
> isn't  it still possible at runtime to disable the security server?

If correctly configured policy and enforcement mode turned on present,
"de-activating the SS" (more like going into permissive mode or just
disabling SELinux at runtime via selinuxfs) wont be possible.

Also, what do you mean my "tamper-proof" in this context? Physically
protecting the chip which serves as storage for it? That sounds strange.

> 3. Same as above, is it possible to change the security policy files, or
> reload a different set of policies (given root access).

Under SELinux root is just another user with access to certain roles. Be
them user_r or sysadm_r, doesn't matter, it's all your choice and you
can turn root into a non privileged user.

> And now the big question, is there a way to prevent both (2) and (3)??
> Or have I completely misunderstood the whole thing??

On 2 and 3, SELinux stuff with correct configuration (policy,
enforcement mode by default, etc), you would prevent both. In any case,
physical protection of the storage media is more important.

Just think if someone with access to the proper resources (ie. anyone
studying an electrical engineering degree or with some knowledge on the
field and money to waste) could dump an image of the flash memory chip
after de-assembling it form the circuit, and post-analyzing the obtained
data? Neither SELinux nor file-system labeling will be able to do
anything against that. Many times these methods are used to
reverse-engineer firmware and the like.

I hope it helped.

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

Re: SELinux for embedded devices...

[Luke Kenneth Casson Leighton]

On Fri, Jul 29, 2005 at 06:12:29AM +0200, Lorenzo Hern?ndez Garc?a-Hierro wrote:

> El vie, 29-07-2005 a las 07:50 +0530, Sriram, Kannan escribi?:
> > Hello all,
> > 
> >  I'm a newbie to SELinux, trying to figure out if SELinux is applicable/
> > suitable to embedded system security, especially mobile terminals/
> > smartphones. I have the following very basic questions... Pls help me
> > out, or redirect me to the appropriate forum.
> > 
> > 1. Is SELinux applicable and suitable for mobile equipment, where the
> > end user always has root privileges? Has SELinux been ported to any
> > embedded device yet (some ARM platform??).

> I was working on the design of extended attributes for JFFS2 (in which
> SELinux relies for labeling file-system objects), even got help from an
> Intel guy, but I got stuck at it, without any resources for testing, and
> the Intel guy who was willing to work together with me was requested for
> legal approbation before doing anything. Thus, time passed and I
> couldn't go a step further on doing anything serious about it.

 i have a complete test environment for doing this sort of
 thing, it's been sitting unused for several months because
 the project has been shut down.

 the device is a skyminder - a 90Mhz Cirrus Logic "Maverick"
 ARM 720T and it contains a GSM radio module and a GPS module.
 the company ran out of money to do things like, oh i dunno,
 correct the radio interference from the GSM radio module
 to the audio codec and the microphone for example, which
 was only discovered recently when i developed enough of the
 drivers and test procedures to notice it was a problem.

 ... but _other_ than that, the device is perfectly serviceable,
 runs a 2.6.11 kernel, uses JFFS2 on its 16Mbyte flash RAM,
 i have all the source code blah blah full development
 environment blah blah.

 yes i briefly considered adding selinux in to the mix, but
 not on the budget they were paying me.

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: SELinux for embedded devices...

[Stephen Smalley]

On Fri, 2005-07-29 at 07:50 +0530, Sriram, Kannan wrote:
> 1. Is SELinux applicable and suitable for mobile equipment, where the
> end user always has root privileges? Has SELinux been ported to any
> embedded device yet (some ARM platform??).

As to the first question, being able to confine exploits of flaws in
applications on such devices is important, because you may not be able
to update software on those devices very quickly or easily.  That is a
separate issue from controlling what the end user of the device can do.
As to the latter question, earlier versions of SELinux (before we
migrated to using extended attributes for file security labels) were
successfully ported to the iPAQ.  The current version of SELinux
shouldn't have any architecture-specific issues, but there is the
problem of having a labeled filesystem, as others have noted.  In the
short term, one could take the reiserfs approach of implementing xattrs
as regular files hidden from userspace to avoid changing the filesystem
format for jffs2 et al, but that isn't the desired approach for
upstream.  

> 2. Assuming I have made the kernel on the flash to be tamperproof (can't
> replace the SElinux image on the flash with the "SE" part disabled),
> isn't  it still possible at runtime to disable the security server?
> 
> 3. Same as above, is it possible to change the security policy files, or
> reload a different set of policies (given root access).
> 
> And now the big question, is there a way to prevent both (2) and (3)??
> Or have I completely misunderstood the whole thing??

Do you want to prevent such tampering, or just be able to subsequently
perform remote attestation that the device is running an approved
software stack and configuration before giving the device access to some
remote resource?

In any event, the kernel could certainly be modified to check (or just
measure, depending on what you want to achieve above) the integrity
of /sbin/init prior to executing it and of the policy prior to loading
it, and likewise for any other security-critical dependencies that may
exist.  And the kernel can be configured to turn off various options
such as CONFIG_SECURITY_SELINUX_BOOTPARAM,
CONFIG_SECURITY_SELINUX_DISABLE, and CONFIG_SECURITY_SELINUX_DEVELOP, so
that selinux=0, enforcing=0 and /selinux/disable are all rendered
unuseable.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.