BusyBox: load_policy applet

BusyBox: load_policy applet

[Yuichi Nakamura]

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


Attached patch is to support load_policy for BusyBox.
load_policy is a program to load SELinux policy to kernel.
This applet is very important for SELinux, 
because SELinux is not activated until policy is loaded.

And this applet is _not_ based on latest load_policy, 
is based on old load_policy.
This is because the size of latest load_policy is bigger than old one,
and old load_policy has enough feature for embedded device.

Please review and consider merging.
Regards,
-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/

[-- Attachment #2: busybox-load_policy.v1.patch --]
[-- Type: application/octet-stream, Size: 3001 bytes --]

Index: include/usage.h
===================================================================
--- include/usage.h	(revision 18212)
+++ include/usage.h	(working copy)
@@ -1758,6 +1758,10 @@
        "$ ls -l /tmp/ls\n" \
        "lrwxrwxrwx    1 root     root            7 Apr 12 18:39 ls -> BusyBox*\n"
 
+#define load_policy_trivial_usage \
+       "[FILE]"
+#define load_policy_full_usage
+
 #define loadfont_trivial_usage \
        "< font"
 #define loadfont_full_usage \
Index: include/applets.h
===================================================================
--- include/applets.h	(revision 18212)
+++ include/applets.h	(working copy)
@@ -180,6 +180,7 @@ USE_SETARCH(APPLET_NOUSAGE(linux32, seta
 USE_SETARCH(APPLET_NOUSAGE(linux64, setarch, _BB_DIR_BIN, _BB_SUID_NEVER))
 USE_FEATURE_INITRD(APPLET_NOUSAGE(linuxrc, init, _BB_DIR_ROOT, _BB_SUID_NEVER))
 USE_LN(APPLET(ln, _BB_DIR_BIN, _BB_SUID_NEVER))
+USE_LOAD_POLICY(APPLET(load_policy, _BB_DIR_USR_SBIN, _BB_SUID_NEVER))
 USE_LOADFONT(APPLET(loadfont, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
 USE_LOADKMAP(APPLET(loadkmap, _BB_DIR_SBIN, _BB_SUID_NEVER))
 USE_LOGGER(APPLET(logger, _BB_DIR_USR_BIN, _BB_SUID_NEVER))
Index: selinux/load_policy.c
===================================================================
--- selinux/load_policy.c	(revision 0)
+++ selinux/load_policy.c	(revision 0)
@@ -0,0 +1,31 @@
+/*
+ * load_policy
+ * This implementation is based on old load_policy to be small.
+ * Author: Yuichi Nakamura <ynakam@hitachisoft.jp>
+ */
+#include "busybox.h"
+
+int load_policy_main(int argc, char *argv[]);
+int load_policy_main(int argc, char *argv[])
+{
+	int fd;
+	struct stat st;
+	void *data;
+	if(argc != 2) {
+		bb_show_usage();
+	}
+	
+	fd = xopen(argv[1], O_RDONLY);
+	if (fstat(fd, &st) < 0 ) {
+		bb_perror_msg_and_die("can't fstat");
+	}
+	data = mmap(NULL, st.st_size, PROT_READ, MAP_SHARED, fd, 0);
+	if (data == MAP_FAILED) {
+		bb_perror_msg_and_die("can't mmap");
+	}
+	if (security_load_policy(data, st.st_size) < 0) {
+		bb_perror_msg_and_die("can't security_load_policy");
+	}
+		
+	return 0;
+}
Index: selinux/Config.in
===================================================================
--- selinux/Config.in	(revision 18212)
+++ selinux/Config.in	(working copy)
@@ -34,6 +34,13 @@ config GETSEBOOL
 	help
 	  Enable support to get SELinux boolean values.
 
+config LOAD_POLICY
+	bool "load_policy"
+	default n
+	depends on SELINUX
+	help
+	  Enable support to load SELinux policy.
+
 config MATCHPATHCON
 	bool "matchpathcon"
 	default n
Index: selinux/Kbuild
===================================================================
--- selinux/Kbuild	(revision 18212)
+++ selinux/Kbuild	(working copy)
@@ -9,6 +9,7 @@ lib-y:=
 lib-$(CONFIG_CHCON)		+= chcon.o
 lib-$(CONFIG_GETENFORCE)	+= getenforce.o
 lib-$(CONFIG_GETSEBOOL)		+= getsebool.o
+lib-$(CONFIG_LOAD_POLICY)	+= load_policy.o
 lib-$(CONFIG_MATCHPATHCON)	+= matchpathcon.o
 lib-$(CONFIG_RUNCON)		+= runcon.o
 lib-$(CONFIG_SELINUXENABLED)	+= selinuxenabled.o

Re: BusyBox: load_policy applet

[Stephen Smalley]

On Fri, 2007-03-23 at 15:15 +0900, Yuichi Nakamura wrote:
> Attached patch is to support load_policy for BusyBox.
> load_policy is a program to load SELinux policy to kernel.
> This applet is very important for SELinux, 
> because SELinux is not activated until policy is loaded.
> 
> And this applet is _not_ based on latest load_policy, 
> is based on old load_policy.
> This is because the size of latest load_policy is bigger than old one,
> and old load_policy has enough feature for embedded device.

Hmm...are you sure?  Functionality that you are losing from the new load
policy logic that lives in libselinux these days:
- automatic discovery of the right policy file,
- automatic downgrading of the policy file format to the kernel
supported format if necessary (e.g. new policy, old kernel),
- loading of local user and/or boolean definitions (obsolete if you
choose to use libsemanage and managed policy, but not clear you are
doing that in embedded),
- preservation of boolean settings across a policy reload so they aren't
reset to the policy defaults.

Boolean management seems the greatest concern, and using policy booleans
on an embedded device to change policy states based on events /
environmental factors is quite reasonable.

I know that you have a concern about libsepol size, but we may be able
to reduce that to a minimal subset for your purposes without dropping it
altogether on embedded (and it is expected to get smaller anyway as as
result of the proposed new policy representation).

As a minor point on your applet, shouldn't you munmap and close before
returning?

-- 
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: BusyBox: load_policy applet

[Yuichi Nakamura]

Hi.

On Fri, 23 Mar 2007 08:49:37 -0400
Stephen Smalley  wrote:
> On Fri, 2007-03-23 at 15:15 +0900, Yuichi Nakamura wrote:
> > Attached patch is to support load_policy for BusyBox.
> > load_policy is a program to load SELinux policy to kernel.
> > This applet is very important for SELinux, 
> > because SELinux is not activated until policy is loaded.
> > 
> > And this applet is _not_ based on latest load_policy, 
> > is based on old load_policy.
> > This is because the size of latest load_policy is bigger than old one,
> > and old load_policy has enough feature for embedded device.
> 
> Hmm...are you sure?  Functionality that you are losing from the new load
> policy logic that lives in libselinux these days:
> - automatic discovery of the right policy file,
> - automatic downgrading of the policy file format to the kernel
> supported format if necessary (e.g. new policy, old kernel),
> - loading of local user and/or boolean definitions (obsolete if you
> choose to use libsemanage and managed policy, but not clear you are
> doing that in embedded),
> - preservation of boolean settings across a policy reload so they aren't
> reset to the policy defaults.
> 
> Boolean management seems the greatest concern, and using policy booleans
> on an embedded device to change policy states based on events /
> environmental factors is quite reasonable.
We wanted to prepare minimum(the smallest) load_policy at first.
Boolean is useful as you say, 
we will submit boolean support to BusyBox in the future, 
as a separate CONFIG option.
# And we have to prepare separating libselinux/libsepol..

> I know that you have a concern about libsepol size, but we may be able
> to reduce that to a minimal subset for your purposes without dropping it
> altogether on embedded (and it is expected to get smaller anyway as as
> result of the proposed new policy representation).
> 
> As a minor point on your applet, shouldn't you munmap and close before
> returning?
I've forgotten, I will fix.

> 
> -- 
> Stephen Smalley
> National Security Agency

-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
SELinux Policy Editor: http://seedit.sourceforge.net/


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

Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Stephen Smalley]

On Mon, 2007-03-26 at 10:28 +0900, Yuichi Nakamura wrote:
> Hi.
> 
> On Fri, 23 Mar 2007 08:49:37 -0400
> Stephen Smalley  wrote:
> > On Fri, 2007-03-23 at 15:15 +0900, Yuichi Nakamura wrote:
> > > Attached patch is to support load_policy for BusyBox.
> > > load_policy is a program to load SELinux policy to kernel.
> > > This applet is very important for SELinux, 
> > > because SELinux is not activated until policy is loaded.
> > > 
> > > And this applet is _not_ based on latest load_policy, 
> > > is based on old load_policy.
> > > This is because the size of latest load_policy is bigger than old one,
> > > and old load_policy has enough feature for embedded device.
> > 
> > Hmm...are you sure?  Functionality that you are losing from the new load
> > policy logic that lives in libselinux these days:
> > - automatic discovery of the right policy file,
> > - automatic downgrading of the policy file format to the kernel
> > supported format if necessary (e.g. new policy, old kernel),
> > - loading of local user and/or boolean definitions (obsolete if you
> > choose to use libsemanage and managed policy, but not clear you are
> > doing that in embedded),
> > - preservation of boolean settings across a policy reload so they aren't
> > reset to the policy defaults.
> > 
> > Boolean management seems the greatest concern, and using policy booleans
> > on an embedded device to change policy states based on events /
> > environmental factors is quite reasonable.
> We wanted to prepare minimum(the smallest) load_policy at first.
> Boolean is useful as you say, 
> we will submit boolean support to BusyBox in the future, 
> as a separate CONFIG option.
> # And we have to prepare separating libselinux/libsepol..

(removed busybox list from the cc line, as I'm not subscribed to it and
this part of the discussion is likely not of interest to them)

I wanted to discuss further your proposal to "separate" libsepol from
libselinux (i.e. provide a build option for libselinux to allow building
it without selinux_mkload_policy() and thus without a dependency on
libsepol, IIUC).

I have a couple of concerns with that proposal:
1) I think you will ultimately need libsepol or some subset of it to
support booleans and other forms of local customization.  Hence, it may
be better to leave the dependency of libselinux on libsepol and work on
creating a minimal version of libsepol via a build option in it instead
as well as working to optimize its size in general.  As long as you are
using shared libraries and dynamic linking, you should only need one
instance of the libsepol code regardless of how many programs link
against it (or do you use static linking in that environment?).

2) selinux_mkload_policy() and selinux_init_load_policy() encapsulate
and standardize the policy loading logic, enabling us to evolve that
logic without needing to re-patch /sbin/init or the load_policy binary
in the future.  This includes not only things like finding the right
policy file, but also selecting the initial state for SELinux
(enabled/disabled, enforcing/permissive) based on both
the /etc/selinux/config file and the kernel command line arguments.  It
is desirable to keep that logic standard across all selinux systems if
possible.  If you omit them from your libselinux and re-introduce that
logic elsewhere (in your load_policy applet and your busybox init
functionality), there seems strong potential for divergence.  On the
initial policy load topic, I think Ubuntu is looking at handling it from
initramfs instead of init, see:
https://lists.ubuntu.com/archives/ubuntu-hardened/2007-March/000171.html
https://lists.ubuntu.com/archives/ubuntu-hardened/2007-March/000175.html
which might obviate the need for selinux_init_load_policy() in libselinux.

I'd also like to find out what you think about libsemanage and
managed/modular policy in embedded environments, as mainstream selinux
has migrated to using them entirely and we are considering dropping
support for the old way of dealing with booleans and local users from
libsepol and libselinux (see my prior [RFC] Drop setlocaldefs support
from trunk posting on Feb 22).  That would require use of libsemanage
and managed policy going forward for boolean manipulation, so if that is
a problem for embedded, we need to know now.  And even if you think they
are too heavy presently, we want to work toward enabling use of managed
policy in those environments, so it would make sense to work on
optimizing the size of libsemanage (or providing a build option for a
cut-down version of it) and the size of the policy module store further
(some improvements like removing the previous copy and linked policy
file were already made, but others like bzip2 support and removing files
from the module store after installation haven't yet been done, at least
not completely - there are some RFC patches floating around). 

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Christopher J. PeBenito]

On Mon, 2007-03-26 at 10:08 -0400, Stephen Smalley wrote:
> On Mon, 2007-03-26 at 10:28 +0900, Yuichi Nakamura wrote:
> > On Fri, 23 Mar 2007 08:49:37 -0400
> > Stephen Smalley  wrote:
> > > On Fri, 2007-03-23 at 15:15 +0900, Yuichi Nakamura wrote:
> > > > Attached patch is to support load_policy for BusyBox.
> > > > load_policy is a program to load SELinux policy to kernel.
> > > > This applet is very important for SELinux, 
> > > > because SELinux is not activated until policy is loaded.
> > > > 
> > > > And this applet is _not_ based on latest load_policy, 
> > > > is based on old load_policy.
> > > > This is because the size of latest load_policy is bigger than old one,
> > > > and old load_policy has enough feature for embedded device.

> I wanted to discuss further your proposal to "separate" libsepol from
> libselinux (i.e. provide a build option for libselinux to allow building
> it without selinux_mkload_policy() and thus without a dependency on
> libsepol, IIUC).
> 
> I have a couple of concerns with that proposal:
[...]
> I'd also like to find out what you think about libsemanage and
> managed/modular policy in embedded environments, as mainstream selinux
> has migrated to using them entirely and we are considering dropping
> support for the old way of dealing with booleans and local users from
> libsepol and libselinux (see my prior [RFC] Drop setlocaldefs support
> from trunk posting on Feb 22).  That would require use of libsemanage
> and managed policy going forward for boolean manipulation, so if that is
> a problem for embedded, we need to know now.  And even if you think they
> are too heavy presently, we want to work toward enabling use of managed
> policy in those environments, so it would make sense to work on
> optimizing the size of libsemanage (or providing a build option for a
> cut-down version of it) and the size of the policy module store further
> (some improvements like removing the previous copy and linked policy
> file were already made, but others like bzip2 support and removing files
> from the module store after installation haven't yet been done, at least
> not completely - there are some RFC patches floating around). 

I'm not involved in what Yuichi and KaiGai are doing, so I can't speak
to their goals, but I figured I'd put in my $0.02.  The setup that I
have originated pre selinux-enabled busybox and pre managed policy
(example policy based).  I basically took busybox, libselinux (including
the util programs), policycoreutils (the C code pieces) and my
application, and jammed it into a little more than 8MB including the
kernel.

In my personal opinion, if you are really going tiny, that means its a
customized system, which includes customized policy.  That means you
should be setting the correct initial boolean values when you build the
policy, which also means monolithic instead of modular.  I took the
example policy,  removed a great deal of it and got a policy with less
than 8000 rules (actual rules since it was pre v20 policy), and sysadm
could still log in, and do a few admin tasks like toggle booleans,
restart the services and shutdown.  If you take refpolicy's kernel
layer, you get a little over 200 rules (v21 policy) and get a ~60k
binary policy, so its easy to get a tiny policy base to start on today.

So to summarize my rambling, my personal opinion is, embedded systems do
not use managed policy, therefore do not require libsemanage.  They do
not use a distro policy, but rather compile their own, therefore do not
use the setlocaldefs support.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Stephen Smalley]

On Mon, 2007-03-26 at 12:12 -0400, Christopher J. PeBenito wrote:
> On Mon, 2007-03-26 at 10:08 -0400, Stephen Smalley wrote:
> > On Mon, 2007-03-26 at 10:28 +0900, Yuichi Nakamura wrote:
> > > On Fri, 23 Mar 2007 08:49:37 -0400
> > > Stephen Smalley  wrote:
> > > > On Fri, 2007-03-23 at 15:15 +0900, Yuichi Nakamura wrote:
> > > > > Attached patch is to support load_policy for BusyBox.
> > > > > load_policy is a program to load SELinux policy to kernel.
> > > > > This applet is very important for SELinux, 
> > > > > because SELinux is not activated until policy is loaded.
> > > > > 
> > > > > And this applet is _not_ based on latest load_policy, 
> > > > > is based on old load_policy.
> > > > > This is because the size of latest load_policy is bigger than old one,
> > > > > and old load_policy has enough feature for embedded device.
> 
> > I wanted to discuss further your proposal to "separate" libsepol from
> > libselinux (i.e. provide a build option for libselinux to allow building
> > it without selinux_mkload_policy() and thus without a dependency on
> > libsepol, IIUC).
> > 
> > I have a couple of concerns with that proposal:
> [...]
> > I'd also like to find out what you think about libsemanage and
> > managed/modular policy in embedded environments, as mainstream selinux
> > has migrated to using them entirely and we are considering dropping
> > support for the old way of dealing with booleans and local users from
> > libsepol and libselinux (see my prior [RFC] Drop setlocaldefs support
> > from trunk posting on Feb 22).  That would require use of libsemanage
> > and managed policy going forward for boolean manipulation, so if that is
> > a problem for embedded, we need to know now.  And even if you think they
> > are too heavy presently, we want to work toward enabling use of managed
> > policy in those environments, so it would make sense to work on
> > optimizing the size of libsemanage (or providing a build option for a
> > cut-down version of it) and the size of the policy module store further
> > (some improvements like removing the previous copy and linked policy
> > file were already made, but others like bzip2 support and removing files
> > from the module store after installation haven't yet been done, at least
> > not completely - there are some RFC patches floating around). 
> 
> I'm not involved in what Yuichi and KaiGai are doing, so I can't speak
> to their goals, but I figured I'd put in my $0.02.  The setup that I
> have originated pre selinux-enabled busybox and pre managed policy
> (example policy based).  I basically took busybox, libselinux (including
> the util programs), policycoreutils (the C code pieces) and my
> application, and jammed it into a little more than 8MB including the
> kernel.
> 
> In my personal opinion, if you are really going tiny, that means its a
> customized system, which includes customized policy.  That means you
> should be setting the correct initial boolean values when you build the
> policy, which also means monolithic instead of modular.  I took the
> example policy,  removed a great deal of it and got a policy with less
> than 8000 rules (actual rules since it was pre v20 policy), and sysadm
> could still log in, and do a few admin tasks like toggle booleans,
> restart the services and shutdown.  If you take refpolicy's kernel
> layer, you get a little over 200 rules (v21 policy) and get a ~60k
> binary policy, so its easy to get a tiny policy base to start on today.
> 
> So to summarize my rambling, my personal opinion is, embedded systems do
> not use managed policy, therefore do not require libsemanage.  They do
> not use a distro policy, but rather compile their own, therefore do not
> use the setlocaldefs support.

IIRC, the conditional policy support and loadable module support grew
out of some work investigating the use of SELinux on small mobile
devices, with an eye toward allowing things like:
- a daemon on the device to make controlled changes to policy via policy
booleans in response to events / environmental factors (some of which
should be preserved even if the device is rebooted),
- new applications for the device to come with their own policies w/o
requiring full policy sources or rebuild on the end systems (in
particular thinking of third party apps).  Further, being able to limit
what those application policies could allow was of interest, which also
brings into play something like policy management server (possibly a
very cut-down version).

So I'd be concerned about not supporting such things ever in the
embedded space, and would like to have a strategy for working toward
such support even it isn't going to be in the initial version.  And I
think that the mainline selinux would benefit from such work as well, as
some optimizations may be applicable in general w/o sacrificing much in
the way of real functionality.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Karl MacMillan]

On Mon, 2007-03-26 at 12:12 -0400, Christopher J. PeBenito wrote:
> On Mon, 2007-03-26 at 10:08 -0400, Stephen Smalley wrote:
> > On Mon, 2007-03-26 at 10:28 +0900, Yuichi Nakamura wrote:
> > > On Fri, 23 Mar 2007 08:49:37 -0400
> > > Stephen Smalley  wrote:
> > > > On Fri, 2007-03-23 at 15:15 +0900, Yuichi Nakamura wrote:
> > > > > Attached patch is to support load_policy for BusyBox.
> > > > > load_policy is a program to load SELinux policy to kernel.
> > > > > This applet is very important for SELinux, 
> > > > > because SELinux is not activated until policy is loaded.
> > > > > 
> > > > > And this applet is _not_ based on latest load_policy, 
> > > > > is based on old load_policy.
> > > > > This is because the size of latest load_policy is bigger than old one,
> > > > > and old load_policy has enough feature for embedded device.
> 
> > I wanted to discuss further your proposal to "separate" libsepol from
> > libselinux (i.e. provide a build option for libselinux to allow building
> > it without selinux_mkload_policy() and thus without a dependency on
> > libsepol, IIUC).
> > 
> > I have a couple of concerns with that proposal:
> [...]
> > I'd also like to find out what you think about libsemanage and
> > managed/modular policy in embedded environments, as mainstream selinux
> > has migrated to using them entirely and we are considering dropping
> > support for the old way of dealing with booleans and local users from
> > libsepol and libselinux (see my prior [RFC] Drop setlocaldefs support
> > from trunk posting on Feb 22).  That would require use of libsemanage
> > and managed policy going forward for boolean manipulation, so if that is
> > a problem for embedded, we need to know now.  And even if you think they
> > are too heavy presently, we want to work toward enabling use of managed
> > policy in those environments, so it would make sense to work on
> > optimizing the size of libsemanage (or providing a build option for a
> > cut-down version of it) and the size of the policy module store further
> > (some improvements like removing the previous copy and linked policy
> > file were already made, but others like bzip2 support and removing files
> > from the module store after installation haven't yet been done, at least
> > not completely - there are some RFC patches floating around). 
> 
> I'm not involved in what Yuichi and KaiGai are doing, so I can't speak
> to their goals, but I figured I'd put in my $0.02.  The setup that I
> have originated pre selinux-enabled busybox and pre managed policy
> (example policy based).  I basically took busybox, libselinux (including
> the util programs), policycoreutils (the C code pieces) and my
> application, and jammed it into a little more than 8MB including the
> kernel.
> 
> In my personal opinion, if you are really going tiny, that means its a
> customized system, which includes customized policy.  That means you
> should be setting the correct initial boolean values when you build the
> policy, which also means monolithic instead of modular.

What if the booleans are used to represent runtime state, for example
different security settings when a PDA is docked as opposed to undocked?
In that case there is no reasonable default and not preserving the
current values could cause serious problems.

Karl


--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Christopher J. PeBenito]

On Mon, 2007-03-26 at 12:37 -0400, Karl MacMillan wrote:
> On Mon, 2007-03-26 at 12:12 -0400, Christopher J. PeBenito wrote:
> > On Mon, 2007-03-26 at 10:08 -0400, Stephen Smalley wrote:
> > > On Mon, 2007-03-26 at 10:28 +0900, Yuichi Nakamura wrote:
> > > > On Fri, 23 Mar 2007 08:49:37 -0400
> > > > Stephen Smalley  wrote:
> > > > > On Fri, 2007-03-23 at 15:15 +0900, Yuichi Nakamura wrote:
> > > > > > Attached patch is to support load_policy for BusyBox.
> > > > > > load_policy is a program to load SELinux policy to kernel.
> > > > > > This applet is very important for SELinux, 
> > > > > > because SELinux is not activated until policy is loaded.
> > > > > > 
> > > > > > And this applet is _not_ based on latest load_policy, 
> > > > > > is based on old load_policy.
> > > > > > This is because the size of latest load_policy is bigger than old one,
> > > > > > and old load_policy has enough feature for embedded device.
> > 
> > > I wanted to discuss further your proposal to "separate" libsepol from
> > > libselinux (i.e. provide a build option for libselinux to allow building
> > > it without selinux_mkload_policy() and thus without a dependency on
> > > libsepol, IIUC).
> > > 
> > > I have a couple of concerns with that proposal:
> > [...]
> > > I'd also like to find out what you think about libsemanage and
> > > managed/modular policy in embedded environments, as mainstream selinux
> > > has migrated to using them entirely and we are considering dropping
> > > support for the old way of dealing with booleans and local users from
> > > libsepol and libselinux (see my prior [RFC] Drop setlocaldefs support
> > > from trunk posting on Feb 22).  That would require use of libsemanage
> > > and managed policy going forward for boolean manipulation, so if that is
> > > a problem for embedded, we need to know now.  And even if you think they
> > > are too heavy presently, we want to work toward enabling use of managed
> > > policy in those environments, so it would make sense to work on
> > > optimizing the size of libsemanage (or providing a build option for a
> > > cut-down version of it) and the size of the policy module store further
> > > (some improvements like removing the previous copy and linked policy
> > > file were already made, but others like bzip2 support and removing files
> > > from the module store after installation haven't yet been done, at least
> > > not completely - there are some RFC patches floating around). 
> > 
> > I'm not involved in what Yuichi and KaiGai are doing, so I can't speak
> > to their goals, but I figured I'd put in my $0.02.  The setup that I
> > have originated pre selinux-enabled busybox and pre managed policy
> > (example policy based).  I basically took busybox, libselinux (including
> > the util programs), policycoreutils (the C code pieces) and my
> > application, and jammed it into a little more than 8MB including the
> > kernel.
> > 
> > In my personal opinion, if you are really going tiny, that means its a
> > customized system, which includes customized policy.  That means you
> > should be setting the correct initial boolean values when you build the
> > policy, which also means monolithic instead of modular.
> 
> What if the booleans are used to represent runtime state, for example
> different security settings when a PDA is docked as opposed to undocked?
> In that case there is no reasonable default and not preserving the
> current values could cause serious problems.

I disagree.  The correct answer is whichever state the device assumes
when it powers up.  PDAs already have to determine that type of state
when they power up after the initial setup, so at that time when it
determines the state, it can also set the boolean.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Yuichi Nakamura]

Hi.
Thank you for opinion and information > Stephen, Christopher

My personal opinion is following:
# I think it is easier to explain my opinion by that than by commenting your posts.

I want to make SELinux easy to customize for various embedded devices.
The requirement for embedded SELinux will be various.
Someone may want to write strict policy for all processes, 
and some may want to write policy only for one or two applications.
Customize is neccesary.

If device is rich enough, 
full-featured SELinux can be used. 
Mobile PDA may be example of such devices.
It includes boolean, modular policy, semanage etc.
Size optimization for libsemanage,libsepol, semanage will be necessarty as you say.

However, what if devices are poor or there are small room for SELinux?
Example of such devices are electrical appliances conneceted to network.
In such environment, people want to make SELinux as small as possible.
They may remove modular support, libsepol and booleans, uses only monolitic poilcy.
I think even some hooks may be removed to improve performance.
Some of such people are now being attracted to other light-weight Secure OSes,
such as TOMOYO Linux(http://tomoyo.sourceforge.jp/en/1.3/) and AppArmor. 
I want to make them to be interested in SELinux.

The SELinux for embedded in my brain(future SEDiet work) for now is following.
* Embedded SELinux development kit is prepared and it has following features.
* BusyBox includes SELinux commands
* Developers can choose required features(boolean, module, semanage etc)
* To implement it following will be necessary.
* libselinux/libsepol/libsemanage is separated
* Something like ENABLE_BOOLEAN, ENABLE_MODULE, ENABLE_SEMANAGE is embedded in source codes of libse*, BusyBox.
* Least set of refpolicy is prepared: 
  - only core policy(kernel policy module?) and macros are enabled by default
  - supports both modular and monolitic
  - To write new policy, SEEdit or other tools can be used
  - has a compiler that has feature for size optimization


-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
Japan SELinux Users Group(JSELUG)
SELinux Policy Editor: http://seedit.sourceforge.net/


--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Ryan Bradetich]

Hello all,

Just thought I would add a few comments.

On 3/26/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Mon, 2007-03-26 at 12:12 -0400, Christopher J. PeBenito wrote:
> > So to summarize my rambling, my personal opinion is, embedded systems do
> > not use managed policy, therefore do not require libsemanage.  They do
> > not use a distro policy, but rather compile their own, therefore do not
> > use the setlocaldefs support.

The embedded system I work on are typically higher end embedded
systems, but everything on these devices are controlled from settings
[NOTE: End-users are never provided a direct path to obtain shell
access on the system].  While the current research I am doing for my
thesis does not require module support, I could easily imagine
situations where I would like both modules and boolean support.

Chris is correct though, we do tend to customize and compile
everything to meet our space requirements, etc.  My goal is to fit my
customized SELinux Debian based distribution in 16MB of flash.

I did read Stephen's RFC on setlocaldefs, but to be honest ... I do
not have enough background to really understand it yet.   I will need
some more time to dig in get a feel for the issue :(

> IIRC, the conditional policy support and loadable module support grew
> out of some work investigating the use of SELinux on small mobile
> devices, with an eye toward allowing things like:
> - a daemon on the device to make controlled changes to policy via policy
> booleans in response to events / environmental factors (some of which
> should be preserved even if the device is rebooted),

I can imagine a couple different scenarios where I would like to have
limited control over the policy via booleans based on events/commands
originating from the SCADA operations center.

> - new applications for the device to come with their own policies w/o
> requiring full policy sources or rebuild on the end systems (in
> particular thinking of third party apps).  Further, being able to limit
> what those application policies could allow was of interest, which also
> brings into play something like policy management server (possibly a
> very cut-down version).

A different take on this would be different modules could be loaded
depending upon device settings.  For example, one of the settings on
one of my devices might be to disable the HTTP server.   Based on this
setting information, the SELinux web server policy could be optionally
loaded or unloaded.  [NOTE: Settings changes on my embedded devices
are very rare once they are in production, but are very common during
the commissioning phase, so it is not unreasonable to require a reboot
of the device on settings change if absolutely needed].

One other example is information in the settings could be used to
generate the policy file themselves.  For example, the HTTP protocol
typically listens on port 80, but this port number is actually a user
configurable setting.   On a settings change, I could have my embedded
device generate the appropriate HTTP module using the current port
setting information and the load the module.

The idea of a policy  management server is also intriguing,  but I am
still trying to get my head around SELinux and how I can successfully
use it in my environment.  No comments from me yet on the policy
management server yet :)

> So I'd be concerned about not supporting such things ever in the
> embedded space, and would like to have a strategy for working toward
> such support even it isn't going to be in the initial version.  And I
> think that the mainline selinux would benefit from such work as well, as
> some optimizations may be applicable in general w/o sacrificing much in
> the way of real functionality.

I would also like to see this.   I am planning on following this email
up with my customized policy (based on the refpolicy) that I am using
for my thesis research.
The reason I bring this up here is my binary policy (version 21) size
is 18k.   While the refpolicy is a great start, and I am hoping with
more embedded people getting interested in SELinux, that we can also
work on the policy size as well as flexibility in the future.

Thanks!

- Ryan

--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Stephen Smalley]

On Tue, 2007-03-27 at 09:59 +0900, Yuichi Nakamura wrote:
> Hi.
> Thank you for opinion and information > Stephen, Christopher
> 
> My personal opinion is following:
> # I think it is easier to explain my opinion by that than by commenting your posts.
> 
> I want to make SELinux easy to customize for various embedded devices.
> The requirement for embedded SELinux will be various.
> Someone may want to write strict policy for all processes, 
> and some may want to write policy only for one or two applications.
> Customize is neccesary.
> 
> If device is rich enough, 
> full-featured SELinux can be used. 
> Mobile PDA may be example of such devices.
> It includes boolean, modular policy, semanage etc.
> Size optimization for libsemanage,libsepol, semanage will be necessarty as you say.
> 
> However, what if devices are poor or there are small room for SELinux?
> Example of such devices are electrical appliances conneceted to network.
> In such environment, people want to make SELinux as small as possible.
> They may remove modular support, libsepol and booleans, uses only monolitic poilcy.
> I think even some hooks may be removed to improve performance.
> Some of such people are now being attracted to other light-weight Secure OSes,
> such as TOMOYO Linux(http://tomoyo.sourceforge.jp/en/1.3/) and AppArmor.
>  
> I want to make them to be interested in SELinux.
> 
> The SELinux for embedded in my brain(future SEDiet work) for now is following.
> * Embedded SELinux development kit is prepared and it has following features.
> * BusyBox includes SELinux commands
> * Developers can choose required features(boolean, module, semanage etc)
> * To implement it following will be necessary.
> * libselinux/libsepol/libsemanage is separated
> * Something like ENABLE_BOOLEAN, ENABLE_MODULE, ENABLE_SEMANAGE is embedded in source codes of libse*, BusyBox.
> * Least set of refpolicy is prepared: 
>   - only core policy(kernel policy module?) and macros are enabled by default
>   - supports both modular and monolitic
>   - To write new policy, SEEdit or other tools can be used
>   - has a compiler that has feature for size optimization

For the most part, this approach sounds fine, and I suspect that you
could even introduce a build option for creating a minimal subset of
libselinux as well as the other libraries.  Note that the loadable
policy module support depends on libsemanage, so I doubt you would
support separate ENABLE_MODULE vs. ENABLE_SEMANAGE options unless you
just mean the set of utility programs.

Some specific questions and comments:
1) Do you think you will need the legacy support for setting local
persistent booleans without using libsemanage?  We were planning on
dropping that support out of libselinux and libsepol in the 2.x/devel
series.
2) How do you plan to support initial policy load in the embedded
environment?  From an initramfs, as proposed for Ubuntu, or via modified
init functionality in busybox, as in current distributions that support
SELinux?  Do you intend to replicate the logic that currently lives in
selinux_init_load_policy() for selecting the initial state of SELinux
(disabled/enforcing/permissive) based on /etc/selinux/config and the
kernel parameters somewhere else?
3) I'd much prefer to see your policy optimization work go into
refpolicy and any "optimizing" policy compiler work go into checkpolicy
rather than keeping it in your own SEEdit-specific policy and tool.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Christopher J. PeBenito]

On Mon, 2007-03-26 at 19:58 -0700, Ryan Bradetich wrote:
> Hello all,
> 
> Just thought I would add a few comments.
> 
> On 3/26/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Mon, 2007-03-26 at 12:12 -0400, Christopher J. PeBenito wrote:
> > > So to summarize my rambling, my personal opinion is, embedded systems do
> > > not use managed policy, therefore do not require libsemanage.  They do
> > > not use a distro policy, but rather compile their own, therefore do not
> > > use the setlocaldefs support.
> 
> The embedded system I work on are typically higher end embedded
> systems, but everything on these devices are controlled from settings
> [NOTE: End-users are never provided a direct path to obtain shell
> access on the system].  While the current research I am doing for my
> thesis does not require module support, I could easily imagine
> situations where I would like both modules and boolean support.
> 
> Chris is correct though, we do tend to customize and compile
> everything to meet our space requirements, etc.  My goal is to fit my
> customized SELinux Debian based distribution in 16MB of flash.
> 
> I did read Stephen's RFC on setlocaldefs, but to be honest ... I do
> not have enough background to really understand it yet.   I will need
> some more time to dig in get a feel for the issue :(
> 
> > IIRC, the conditional policy support and loadable module support grew
> > out of some work investigating the use of SELinux on small mobile
> > devices, with an eye toward allowing things like:
> > - a daemon on the device to make controlled changes to policy via policy
> > booleans in response to events / environmental factors (some of which
> > should be preserved even if the device is rebooted),
> 
> I can imagine a couple different scenarios where I would like to have
> limited control over the policy via booleans based on events/commands
> originating from the SCADA operations center.

This mostly fits with what my idea of how booleans fit in.  I view them
as needing to be toggled based on the state of the device.  I still
don't agree that they need to be preserved, as the device is going to
have to reestablish its state when it boots, and can set the booleans at
that time.

> > - new applications for the device to come with their own policies w/o
> > requiring full policy sources or rebuild on the end systems (in
> > particular thinking of third party apps).  Further, being able to limit
> > what those application policies could allow was of interest, which also
> > brings into play something like policy management server (possibly a
> > very cut-down version).
> 
> A different take on this would be different modules could be loaded
> depending upon device settings.  For example, one of the settings on
> one of my devices might be to disable the HTTP server.   Based on this
> setting information, the SELinux web server policy could be optionally
> loaded or unloaded.  [NOTE: Settings changes on my embedded devices
> are very rare once they are in production, but are very common during
> the commissioning phase, so it is not unreasonable to require a reboot
> of the device on settings change if absolutely needed].

If the device requires configuration changes, I think the best answer is
the upcoming tunable support.  You could use just a base module and have
all the options.  Then you won't be wasting kernel memory on unused
configuration options since only the rules required for the
configuration settings are included in the final binary policy.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Stephen Smalley]

On Mon, 2007-03-26 at 20:13 +0000, Christopher J. PeBenito wrote:
> On Mon, 2007-03-26 at 12:37 -0400, Karl MacMillan wrote:
> > On Mon, 2007-03-26 at 12:12 -0400, Christopher J. PeBenito wrote:
> > > On Mon, 2007-03-26 at 10:08 -0400, Stephen Smalley wrote:
> > > > On Mon, 2007-03-26 at 10:28 +0900, Yuichi Nakamura wrote:
> > > > > On Fri, 23 Mar 2007 08:49:37 -0400
> > > > > Stephen Smalley  wrote:
> > > > > > On Fri, 2007-03-23 at 15:15 +0900, Yuichi Nakamura wrote:
> > > > > > > Attached patch is to support load_policy for BusyBox.
> > > > > > > load_policy is a program to load SELinux policy to kernel.
> > > > > > > This applet is very important for SELinux, 
> > > > > > > because SELinux is not activated until policy is loaded.
> > > > > > > 
> > > > > > > And this applet is _not_ based on latest load_policy, 
> > > > > > > is based on old load_policy.
> > > > > > > This is because the size of latest load_policy is bigger than old one,
> > > > > > > and old load_policy has enough feature for embedded device.
> > > 
> > > > I wanted to discuss further your proposal to "separate" libsepol from
> > > > libselinux (i.e. provide a build option for libselinux to allow building
> > > > it without selinux_mkload_policy() and thus without a dependency on
> > > > libsepol, IIUC).
> > > > 
> > > > I have a couple of concerns with that proposal:
> > > [...]
> > > > I'd also like to find out what you think about libsemanage and
> > > > managed/modular policy in embedded environments, as mainstream selinux
> > > > has migrated to using them entirely and we are considering dropping
> > > > support for the old way of dealing with booleans and local users from
> > > > libsepol and libselinux (see my prior [RFC] Drop setlocaldefs support
> > > > from trunk posting on Feb 22).  That would require use of libsemanage
> > > > and managed policy going forward for boolean manipulation, so if that is
> > > > a problem for embedded, we need to know now.  And even if you think they
> > > > are too heavy presently, we want to work toward enabling use of managed
> > > > policy in those environments, so it would make sense to work on
> > > > optimizing the size of libsemanage (or providing a build option for a
> > > > cut-down version of it) and the size of the policy module store further
> > > > (some improvements like removing the previous copy and linked policy
> > > > file were already made, but others like bzip2 support and removing files
> > > > from the module store after installation haven't yet been done, at least
> > > > not completely - there are some RFC patches floating around). 
> > > 
> > > I'm not involved in what Yuichi and KaiGai are doing, so I can't speak
> > > to their goals, but I figured I'd put in my $0.02.  The setup that I
> > > have originated pre selinux-enabled busybox and pre managed policy
> > > (example policy based).  I basically took busybox, libselinux (including
> > > the util programs), policycoreutils (the C code pieces) and my
> > > application, and jammed it into a little more than 8MB including the
> > > kernel.
> > > 
> > > In my personal opinion, if you are really going tiny, that means its a
> > > customized system, which includes customized policy.  That means you
> > > should be setting the correct initial boolean values when you build the
> > > policy, which also means monolithic instead of modular.
> > 
> > What if the booleans are used to represent runtime state, for example
> > different security settings when a PDA is docked as opposed to undocked?
> > In that case there is no reasonable default and not preserving the
> > current values could cause serious problems.
> 
> I disagree.  The correct answer is whichever state the device assumes
> when it powers up.  PDAs already have to determine that type of state
> when they power up after the initial setup, so at that time when it
> determines the state, it can also set the boolean.

The state might be set by the user, e.g. knowing that I am about to take
my PDA out of the building, I set or clear a boolean to lock it down,
and I don't want that to be unlocked until I take explicit action to do
so - reboot shouldn't reset it.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Christopher J. PeBenito]

On Tue, 2007-03-27 at 08:45 -0400, Stephen Smalley wrote:
> On Mon, 2007-03-26 at 20:13 +0000, Christopher J. PeBenito wrote:
> > On Mon, 2007-03-26 at 12:37 -0400, Karl MacMillan wrote:
> > > On Mon, 2007-03-26 at 12:12 -0400, Christopher J. PeBenito wrote:
> > > > In my personal opinion, if you are really going tiny, that means its a
> > > > customized system, which includes customized policy.  That means you
> > > > should be setting the correct initial boolean values when you build the
> > > > policy, which also means monolithic instead of modular.
> > > 
> > > What if the booleans are used to represent runtime state, for example
> > > different security settings when a PDA is docked as opposed to undocked?
> > > In that case there is no reasonable default and not preserving the
> > > current values could cause serious problems.
> > 
> > I disagree.  The correct answer is whichever state the device assumes
> > when it powers up.  PDAs already have to determine that type of state
> > when they power up after the initial setup, so at that time when it
> > determines the state, it can also set the boolean.
> 
> The state might be set by the user, e.g. knowing that I am about to take
> my PDA out of the building, I set or clear a boolean to lock it down,
> and I don't want that to be unlocked until I take explicit action to do
> so - reboot shouldn't reset it.

Using the power button on a PDA doesn't shut it down, it does something
more like putting it into standby mode so it can still pop up calendar
reminders.  Thus, when it "turns on" it still has the same boolean
states.  The only time it boots is because the battery was just dead, or
you force it because the system is locked up (or some similar reason).
Both reset the device state too, and then falling back to the defaults
would be the anticipated behavior.  If a lock down is supposed to
survive even that, I would argue that its not a state, its a
configuration and that the tunables are the way to go.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Stephen Smalley]

On Tue, 2007-03-27 at 11:42 -0400, Christopher J. PeBenito wrote:
> On Tue, 2007-03-27 at 08:45 -0400, Stephen Smalley wrote:
> > On Mon, 2007-03-26 at 20:13 +0000, Christopher J. PeBenito wrote:
> > > On Mon, 2007-03-26 at 12:37 -0400, Karl MacMillan wrote:
> > > > On Mon, 2007-03-26 at 12:12 -0400, Christopher J. PeBenito wrote:
> > > > > In my personal opinion, if you are really going tiny, that means its a
> > > > > customized system, which includes customized policy.  That means you
> > > > > should be setting the correct initial boolean values when you build the
> > > > > policy, which also means monolithic instead of modular.
> > > > 
> > > > What if the booleans are used to represent runtime state, for example
> > > > different security settings when a PDA is docked as opposed to undocked?
> > > > In that case there is no reasonable default and not preserving the
> > > > current values could cause serious problems.
> > > 
> > > I disagree.  The correct answer is whichever state the device assumes
> > > when it powers up.  PDAs already have to determine that type of state
> > > when they power up after the initial setup, so at that time when it
> > > determines the state, it can also set the boolean.
> > 
> > The state might be set by the user, e.g. knowing that I am about to take
> > my PDA out of the building, I set or clear a boolean to lock it down,
> > and I don't want that to be unlocked until I take explicit action to do
> > so - reboot shouldn't reset it.
> 
> Using the power button on a PDA doesn't shut it down, it does something
> more like putting it into standby mode so it can still pop up calendar
> reminders.  Thus, when it "turns on" it still has the same boolean
> states.  The only time it boots is because the battery was just dead, or
> you force it because the system is locked up (or some similar reason).
> Both reset the device state too, and then falling back to the defaults
> would be the anticipated behavior.  If a lock down is supposed to
> survive even that, I would argue that its not a state, its a
> configuration and that the tunables are the way to go.

Ok, so what I'm hearing is that we don't need to preserve support for
local boolean and user definitions apart from managed policy.  If anyone
disagrees, speak up please.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Karl MacMillan]

On Tue, 2007-03-27 at 11:48 -0400, Stephen Smalley wrote:
> On Tue, 2007-03-27 at 11:42 -0400, Christopher J. PeBenito wrote:
> > On Tue, 2007-03-27 at 08:45 -0400, Stephen Smalley wrote:
> > > On Mon, 2007-03-26 at 20:13 +0000, Christopher J. PeBenito wrote:
> > > > On Mon, 2007-03-26 at 12:37 -0400, Karl MacMillan wrote:
> > > > > On Mon, 2007-03-26 at 12:12 -0400, Christopher J. PeBenito wrote:
> > > > > > In my personal opinion, if you are really going tiny, that means its a
> > > > > > customized system, which includes customized policy.  That means you
> > > > > > should be setting the correct initial boolean values when you build the
> > > > > > policy, which also means monolithic instead of modular.
> > > > > 
> > > > > What if the booleans are used to represent runtime state, for example
> > > > > different security settings when a PDA is docked as opposed to undocked?
> > > > > In that case there is no reasonable default and not preserving the
> > > > > current values could cause serious problems.
> > > > 
> > > > I disagree.  The correct answer is whichever state the device assumes
> > > > when it powers up.  PDAs already have to determine that type of state
> > > > when they power up after the initial setup, so at that time when it
> > > > determines the state, it can also set the boolean.
> > > 
> > > The state might be set by the user, e.g. knowing that I am about to take
> > > my PDA out of the building, I set or clear a boolean to lock it down,
> > > and I don't want that to be unlocked until I take explicit action to do
> > > so - reboot shouldn't reset it.
> > 
> > Using the power button on a PDA doesn't shut it down, it does something
> > more like putting it into standby mode so it can still pop up calendar
> > reminders.  Thus, when it "turns on" it still has the same boolean
> > states.  The only time it boots is because the battery was just dead, or
> > you force it because the system is locked up (or some similar reason).
> > Both reset the device state too, and then falling back to the defaults
> > would be the anticipated behavior.  If a lock down is supposed to
> > survive even that, I would argue that its not a state, its a
> > configuration and that the tunables are the way to go.
> 
> Ok, so what I'm hearing is that we don't need to preserve support for
> local boolean and user definitions apart from managed policy.  If anyone
> disagrees, speak up please.
> 

I still disagree.

* As Steve mentioned, some of this state could be user defined.
Currently booleans are the means to express this type of configuration
data. The policy developer cannot choose at compile time (using default
booleans or tunables) because multiple states are valid. We can't assume
modular policy at all times for space reasons, so tunables as part of
modules won't work there. That leaves booleans with persistent state.

* We are not just talking about reboots, we are also talking about
policy updates. I wouldn't expect installing an app to turn off a
lockdown mode, but that would happen if it installed policy.

So, not every device will need this, but it seems like a reasonable
solution to a set of problems. In the context of enabling configuration
options for embedded devices this seems like a useful option. Why impose
this limit for no reason?

Karl


--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Christopher J. PeBenito]

On Tue, 2007-03-27 at 12:02 -0400, Karl MacMillan wrote:
> On Tue, 2007-03-27 at 11:48 -0400, Stephen Smalley wrote:
> > On Tue, 2007-03-27 at 11:42 -0400, Christopher J. PeBenito wrote:
> > > On Tue, 2007-03-27 at 08:45 -0400, Stephen Smalley wrote:
> > > > On Mon, 2007-03-26 at 20:13 +0000, Christopher J. PeBenito wrote:
> > > > > On Mon, 2007-03-26 at 12:37 -0400, Karl MacMillan wrote:
> > > > > > On Mon, 2007-03-26 at 12:12 -0400, Christopher J. PeBenito wrote:
> > > > > > > In my personal opinion, if you are really going tiny, that means its a
> > > > > > > customized system, which includes customized policy.  That means you
> > > > > > > should be setting the correct initial boolean values when you build the
> > > > > > > policy, which also means monolithic instead of modular.
> > > > > > 
> > > > > > What if the booleans are used to represent runtime state, for example
> > > > > > different security settings when a PDA is docked as opposed to undocked?
> > > > > > In that case there is no reasonable default and not preserving the
> > > > > > current values could cause serious problems.
> > > > > 
> > > > > I disagree.  The correct answer is whichever state the device assumes
> > > > > when it powers up.  PDAs already have to determine that type of state
> > > > > when they power up after the initial setup, so at that time when it
> > > > > determines the state, it can also set the boolean.
> > > > 
> > > > The state might be set by the user, e.g. knowing that I am about to take
> > > > my PDA out of the building, I set or clear a boolean to lock it down,
> > > > and I don't want that to be unlocked until I take explicit action to do
> > > > so - reboot shouldn't reset it.
> > > 
> > > Using the power button on a PDA doesn't shut it down, it does something
> > > more like putting it into standby mode so it can still pop up calendar
> > > reminders.  Thus, when it "turns on" it still has the same boolean
> > > states.  The only time it boots is because the battery was just dead, or
> > > you force it because the system is locked up (or some similar reason).
> > > Both reset the device state too, and then falling back to the defaults
> > > would be the anticipated behavior.  If a lock down is supposed to
> > > survive even that, I would argue that its not a state, its a
> > > configuration and that the tunables are the way to go.
> > 
> > Ok, so what I'm hearing is that we don't need to preserve support for
> > local boolean and user definitions apart from managed policy.  If anyone
> > disagrees, speak up please.
> > 
> 
> I still disagree.
> 
> * As Steve mentioned, some of this state could be user defined.
> Currently booleans are the means to express this type of configuration
> data. The policy developer cannot choose at compile time (using default
> booleans or tunables) because multiple states are valid. We can't assume
> modular policy at all times for space reasons, so tunables as part of
> modules won't work there. That leaves booleans with persistent state.

A PDA is going to have more backed storage than RAM.  I would argue that
the tunables solution is the better solution from a memory optimization
perspective.  Why waste precious RAM on unused configuration rules in
conditionals, when you have roomier flash-backed storage for tunables?

More specialized systems that have tighter constraints aren't going to
have these configuration options since they're much more static than a
general purpose device like a PDA.

> * We are not just talking about reboots, we are also talking about
> policy updates. I wouldn't expect installing an app to turn off a
> lockdown mode, but that would happen if it installed policy.

Removing setlocaldefs will not change this behavior.  Current Boolean
states will still be kept if you reload or update the policy on a
running system.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Stephen Smalley]

On Tue, 2007-03-27 at 14:43 -0400, Christopher J. PeBenito wrote:
> On Tue, 2007-03-27 at 12:02 -0400, Karl MacMillan wrote:
> > * We are not just talking about reboots, we are also talking about
> > policy updates. I wouldn't expect installing an app to turn off a
> > lockdown mode, but that would happen if it installed policy.
> 
> Removing setlocaldefs will not change this behavior.  Current Boolean
> states will still be kept if you reload or update the policy on a
> running system.

That's true as long as at least that part of the policy loading logic is
preserved, i.e. the if (preservebools) block in selinux_mkload_policy()
in libselinux.  Which calls sepol_genbools_array() and thus requires
libsepol (or a cut-down version of it).  But the present load_policy
applet for busybox just calls security_load_policy() directly and won't
preserve booleans across reloads.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Karl MacMillan]

On Tue, 2007-03-27 at 14:47 -0400, Stephen Smalley wrote:
> On Tue, 2007-03-27 at 14:43 -0400, Christopher J. PeBenito wrote:
> > On Tue, 2007-03-27 at 12:02 -0400, Karl MacMillan wrote:
> > > * We are not just talking about reboots, we are also talking about
> > > policy updates. I wouldn't expect installing an app to turn off a
> > > lockdown mode, but that would happen if it installed policy.
> > 
> > Removing setlocaldefs will not change this behavior.  Current Boolean
> > states will still be kept if you reload or update the policy on a
> > running system.
> 
> That's true as long as at least that part of the policy loading logic is
> preserved, i.e. the if (preservebools) block in selinux_mkload_policy()
> in libselinux.  Which calls sepol_genbools_array() and thus requires
> libsepol (or a cut-down version of it).  But the present load_policy
> applet for busybox just calls security_load_policy() directly and won't
> preserve booleans across reloads.
> 

I think that the boolean preservation is more important that the
setlocaldefs portion. So I'm not against removing that I guess.

Karl


--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Christopher J. PeBenito]

On Tue, 2007-03-27 at 15:09 -0400, Karl MacMillan wrote:
> On Tue, 2007-03-27 at 14:47 -0400, Stephen Smalley wrote:
> > On Tue, 2007-03-27 at 14:43 -0400, Christopher J. PeBenito wrote:
> > > On Tue, 2007-03-27 at 12:02 -0400, Karl MacMillan wrote:
> > > > * We are not just talking about reboots, we are also talking about
> > > > policy updates. I wouldn't expect installing an app to turn off a
> > > > lockdown mode, but that would happen if it installed policy.
> > > 
> > > Removing setlocaldefs will not change this behavior.  Current Boolean
> > > states will still be kept if you reload or update the policy on a
> > > running system.
> > 
> > That's true as long as at least that part of the policy loading logic is
> > preserved, i.e. the if (preservebools) block in selinux_mkload_policy()
> > in libselinux.  Which calls sepol_genbools_array() and thus requires
> > libsepol (or a cut-down version of it).  But the present load_policy
> > applet for busybox just calls security_load_policy() directly and won't
> > preserve booleans across reloads.
> > 
> 
> I think that the boolean preservation is more important that the
> setlocaldefs portion. So I'm not against removing that I guess.

I definitely agree on this.  Not having that would be a regression.

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Ryan Bradetich]

On 3/27/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> Ok, so what I'm hearing is that we don't need to preserve support for
> local boolean and user definitions apart from managed policy.  If anyone
> disagrees, speak up please.

Please excuse my ignorance, but I do not have a good handle on the
terms "local boolean" and "user definitions".

My guess at what you are referring to better encapsulation of booleans
into the policy modules.  For example:

The squid_connect_any boolean/tunable is always present in the policy.
 It is not dependent upon if I had disabled squid support in the
policy.conf file.  One of the advancements I thought was occurring was
to better encapsulate boolean support into policy modules.  So the
squid_connect_any boolean/tunable would only be present if the squid
module was compiled in or as a loaded module.

I personally like this idea, because it gives me less to review,
audit, test, and document  before system deployment.  I am not sure if
this encapsulation idea is what you are referring to as a "local
boolean", but I can also live without this support.  As Chris
mentioned, I would just modify the policy to remove all the booleans
that are not relevant to my system before deployment.

Is this the support you are looking to remove?  Or do you mean something else?

Thanks,

- Ryan

--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Ryan Bradetich]

On 3/27/07, Christopher J. PeBenito <cpebenito@tresys.com> wrote:
> On Tue, 2007-03-27 at 12:02 -0400, Karl M
> A PDA is going to have more backed storage than RAM.  I would argue that
> the tunables solution is the better solution from a memory optimization
> perspective.  Why waste precious RAM on unused configuration rules in
> conditionals, when you have roomier flash-backed storage for tunables?

Maybe I am confused on the difference between a boolean and a tunable
again.  My understanding is that currently there is no difference, but
in the future boolean will be represented as run-time policy changes
and tunables will be represented as compile-time policy changes.

While I generally agree that I would prefer compile time options over
run-time options due to space and processor burden, I also like the
run-time option.  The SCADA industry is a real-time network, so I can
easily imagine situations where the power engineers I work with will
give me requirements like the following:

When the contact input on IN101 goes high, the following action(s)
need to occur within x  time period.

If the x time period is less than the time it takes to re-compile and
load the new policy, I would need to make the time vs space trade-off
and use a run-time check.


My gut feeling would be something like:

I would use tunables (compile-time) options for policy that is driven
by device settings.
I would use run-time (run-time) options for policy that is driven by
SCADA events.


Just offering an alternative embedded use for SELinux that is not a PDA :)

Thanks,

- Ryan

--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Joshua Brindle]

Ryan Bradetich wrote:
> On 3/27/07, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> Ok, so what I'm hearing is that we don't need to preserve support for
>> local boolean and user definitions apart from managed policy.  If anyone
>> disagrees, speak up please.
> 
> Please excuse my ignorance, but I do not have a good handle on the
> terms "local boolean" and "user definitions".
> 
> My guess at what you are referring to better encapsulation of booleans
> into the policy modules.  For example:
> 
> The squid_connect_any boolean/tunable is always present in the policy.
> It is not dependent upon if I had disabled squid support in the
> policy.conf file.  One of the advancements I thought was occurring was
> to better encapsulate boolean support into policy modules.  So the
> squid_connect_any boolean/tunable would only be present if the squid
> module was compiled in or as a loaded module.
> 
> I personally like this idea, because it gives me less to review,
> audit, test, and document  before system deployment.  I am not sure if
> this encapsulation idea is what you are referring to as a "local
> boolean", but I can also live without this support.  As Chris
> mentioned, I would just modify the policy to remove all the booleans
> that are not relevant to my system before deployment.
> 
> Is this the support you are looking to remove?  Or do you mean something 
> else?
> 

Something else. What you mentioned is a policy issue and the discussion 
is about the toolchain/libraries. The local boolean support was added 
before modular policy was added that lets users set boolean values 
persistently locally and init/load_policy (through libselinux) read a 
flat text file with the boolean values and set them in the in-memory 
policydb before loading it into the kernel.

Modular policy has removed the need to modify policies at load time by 
rebuilding the binary from the modules and all local settings (users, 
ports, nodes, booleans, etc). We sought to remove the in-memory 
modification to policies so that we could analyze the actual policy 
binary being used on the system and not something that would be modified 
before being loaded. It also allowed us to add more flexibility by way 
of semanage that was not there previously.


--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[KaiGai Kohei]

>> The SELinux for embedded in my brain(future SEDiet work) for now is following.
>> * Embedded SELinux development kit is prepared and it has following features.
>> * BusyBox includes SELinux commands
>> * Developers can choose required features(boolean, module, semanage etc)
>> * To implement it following will be necessary.
>> * libselinux/libsepol/libsemanage is separated
>> * Something like ENABLE_BOOLEAN, ENABLE_MODULE, ENABLE_SEMANAGE is embedded in source codes of libse*, BusyBox.
>> * Least set of refpolicy is prepared: 
>>   - only core policy(kernel policy module?) and macros are enabled by default
>>   - supports both modular and monolitic
>>   - To write new policy, SEEdit or other tools can be used
>>   - has a compiler that has feature for size optimization
> 
> For the most part, this approach sounds fine, and I suspect that you
> could even introduce a build option for creating a minimal subset of
> libselinux as well as the other libraries.  Note that the loadable
> policy module support depends on libsemanage, so I doubt you would
> support separate ENABLE_MODULE vs. ENABLE_SEMANAGE options unless you
> just mean the set of utility programs.
> 
> Some specific questions and comments:
> 1) Do you think you will need the legacy support for setting local
> persistent booleans without using libsemanage?  We were planning on
> dropping that support out of libselinux and libsepol in the 2.x/devel
> series.

I want to mention that separating libselinux/libsepol is not the only way
to reduce binary size.
Is it possible to replace some functions rare needed in the target system
by empty implemented functions, isn't it? I think this approach enables
more flexible selection of functionalities than the simple separation.

The typical example is userspace avc. I think seldom people use userspace
object managers like XACE/SELinux on embedded systems.
The sum of avc.o, avc_internal.o and avc_sidtab.o is about 32kb (on i386).
Because the size of libselinux.a is about 146kb, we will be able to reduce
about 20% of binary size.

Currently, I don't have actual measurement of the minimum binary size of
libsepol needed to handle preserving boolean variables and so on.
Who can estimate it?

Thanks,

> 2) How do you plan to support initial policy load in the embedded
> environment?  From an initramfs, as proposed for Ubuntu, or via modified
> init functionality in busybox, as in current distributions that support
> SELinux?  Do you intend to replicate the logic that currently lives in
> selinux_init_load_policy() for selecting the initial state of SELinux
> (disabled/enforcing/permissive) based on /etc/selinux/config and the
> kernel parameters somewhere else?
>
> 3) I'd much prefer to see your policy optimization work go into
> refpolicy and any "optimizing" policy compiler work go into checkpolicy
> rather than keeping it in your own SEEdit-specific policy and tool.

-- 
Open Source Software Promotion Center, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Yuichi Nakamura]

On Tue, 27 Mar 2007 08:15:07 -0400
Stephen Smalley  wrote:
> On Tue, 2007-03-27 at 09:59 +0900, Yuichi Nakamura wrote:
> > Hi.
> > Thank you for opinion and information > Stephen, Christopher
> > 
> > My personal opinion is following:
> > # I think it is easier to explain my opinion by that than by commenting your posts.
> > 
> > I want to make SELinux easy to customize for various embedded devices.
> > The requirement for embedded SELinux will be various.
> > Someone may want to write strict policy for all processes, 
> > and some may want to write policy only for one or two applications.
> > Customize is neccesary.
> > 
> > If device is rich enough, 
> > full-featured SELinux can be used. 
> > Mobile PDA may be example of such devices.
> > It includes boolean, modular policy, semanage etc.
> > Size optimization for libsemanage,libsepol, semanage will be necessarty as you say.
> > 
> > However, what if devices are poor or there are small room for SELinux?
> > Example of such devices are electrical appliances conneceted to network.
> > In such environment, people want to make SELinux as small as possible.
> > They may remove modular support, libsepol and booleans, uses only monolitic poilcy.
> > I think even some hooks may be removed to improve performance.
> > Some of such people are now being attracted to other light-weight Secure OSes,
> > such as TOMOYO Linux(http://tomoyo.sourceforge.jp/en/1.3/) and AppArmor.
> >  
> > I want to make them to be interested in SELinux.
> > 
> > The SELinux for embedded in my brain(future SEDiet work) for now is following.
> > * Embedded SELinux development kit is prepared and it has following features.
> > * BusyBox includes SELinux commands
> > * Developers can choose required features(boolean, module, semanage etc)
> > * To implement it following will be necessary.
> > * libselinux/libsepol/libsemanage is separated
> > * Something like ENABLE_BOOLEAN, ENABLE_MODULE, ENABLE_SEMANAGE is embedded in source codes of libse*, BusyBox.
> > * Least set of refpolicy is prepared: 
> >   - only core policy(kernel policy module?) and macros are enabled by default
> >   - supports both modular and monolitic
> >   - To write new policy, SEEdit or other tools can be used
> >   - has a compiler that has feature for size optimization
> 
> For the most part, this approach sounds fine, and I suspect that you
> could even introduce a build option for creating a minimal subset of
> libselinux as well as the other libraries.  Note that the loadable
> policy module support depends on libsemanage, so I doubt you would
> support separate ENABLE_MODULE vs. ENABLE_SEMANAGE options unless you
> just mean the set of utility programs.
Yes. separating module and semanage does not make sense..
We are thinking about options that can be chosen by embedded developers..
We will propose in the future.

> Some specific questions and comments:
> 1) Do you think you will need the legacy support for setting local
> persistent booleans without using libsemanage?  We were planning on
> dropping that support out of libselinux and libsepol in the 2.x/devel
> series.
I saw discussion between you, Karl and Chris.
And I've understood legacy boolean support can be removed.
I and KaiGai will proceed to include preserve boolean support in load_policy BusyBox applet.
We will also try to reduce libselinux+libsepol size.

> 2) How do you plan to support initial policy load in the embedded
> environment?  From an initramfs, as proposed for Ubuntu, or via modified
> init functionality in busybox, as in current distributions that support
> SELinux?  Do you intend to replicate the logic that currently lives in
> selinux_init_load_policy() for selecting the initial state of SELinux
> (disabled/enforcing/permissive) based on /etc/selinux/config and the
> kernel parameters somewhere else?
I think it depends on devices.
I am using Open Zaurus, and its /sbin/init is a shell script, 
I am loading policy in shell script.
I think the most reasonable will be in /sbin/init binary.

> Do you intend to replicate the logic that currently lives in
> selinux_init_load_policy() for selecting the initial state of SELinux
> (disabled/enforcing/permissive) based on /etc/selinux/config and the
> kernel parameters somewhere else?
It depends on size.
I will use selinux_init_load_policy if the size is small enough,
if it is not small, I will write small selinux_init_load_policy.

As KaiGai said now,
to reduce size of libselinux+libsepol,
it is nice if we can pick up necessary fuctions from libselinux/libsepol by build option.
This means, not separated libselinux/libsepol, but tiny libselinux/libsepol.

> 3) I'd much prefer to see your policy optimization work go into
> refpolicy and any "optimizing" policy compiler work go into checkpolicy
> rather than keeping it in your own SEEdit-specific policy and tool.
I see.

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


-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
Japan SELinux Users Group(JSELUG)
SELinux Policy Editor: http://seedit.sourceforge.net/


--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Yuichi Nakamura]

On Wed, 28 Mar 2007 10:57:25 +0900
KaiGai Kohei  wrote:
> Currently, I don't have actual measurement of the minimum binary size of
> libsepol needed to handle preserving boolean variables and so on.
> Who can estimate it?

It seems that "sepol_genbools_array" libsepol function 
is necessary to preserve boolean.

And sepol_genbools_array uses following:
-From policydb.o
 policydb_init
 policydb_destroy
- From policydb_convert.o
 policydb_from_image
- From policydb_public.o
 policydb_write
-From conditional.o
 evaluate_conds
-From  hashtab.o
 hashtab_search

Then:
$ ls -l policydb.o hashtab.o conditional.o  policydb_convert.o policydb_public.o
-rw-rw-r-- 1 ynakam ynakam  6856 Mar 27 05:10 conditional.o
-rw-rw-r-- 1 ynakam ynakam  2540 Mar 27 05:10 hashtab.o
-rw-rw-r-- 1 ynakam ynakam 29284 Mar 27 05:10 policydb.o
-rw-rw-r-- 1 ynakam ynakam  2576 Mar 27 05:10 policydb_convert.o
-rw-rw-r-- 1 ynakam ynakam  2396 Mar 27 05:10 policydb_public.o
Above are compiled with -Os option.

So, to preserve bool at least 43.6 k is necessary.

I want boolean to be enabled/disabled by build option of libselinux/sepol and BusyBox.

> I want to mention that separating libselinux/libsepol is not the only way
> to reduce binary size.
> Is it possible to replace some functions rare needed in the target system
> by empty implemented functions, isn't it? I think this approach enables
> more flexible selection of functionalities than the simple separation.
Yes, this implementation is one possibility. 
This may be better than only separating libselinux/sepol.

BTW, in Japanese chat, 
you and Shinji said too fine-grained selection will not be understood by 
embedded developers.

I've come up with three selections.
1) Full-featured SELinux
2) Tiny-SELinux for embedded device with poor resource
= 1) - semanage - boolean - user space object manager etc
3) Tiny-SELinux for mobile PDA(richer embedded device)
 2) + boolean

Regards,
-- 
Yuichi Nakamura
Hitachi Software Engineering Co., Ltd.
Japan SELinux Users Group(JSELUG)
SELinux Policy Editor: http://seedit.sourceforge.net/


--
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: [busybox:00575] Re: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[KaiGai Kohei]

Yuichi Nakamura wrote:
> On Wed, 28 Mar 2007 10:57:25 +0900
> KaiGai Kohei  wrote:
>> Currently, I don't have actual measurement of the minimum binary size of
>> libsepol needed to handle preserving boolean variables and so on.
>> Who can estimate it?
> 
> It seems that "sepol_genbools_array" libsepol function 
> is necessary to preserve boolean.
> 
> And sepol_genbools_array uses following:
> -From policydb.o
>  policydb_init
>  policydb_destroy
> - From policydb_convert.o
>  policydb_from_image
> - From policydb_public.o
>  policydb_write
> -From conditional.o
>  evaluate_conds
> -From  hashtab.o
>  hashtab_search
> 
> Then:
> $ ls -l policydb.o hashtab.o conditional.o  policydb_convert.o policydb_public.o
> -rw-rw-r-- 1 ynakam ynakam  6856 Mar 27 05:10 conditional.o
> -rw-rw-r-- 1 ynakam ynakam  2540 Mar 27 05:10 hashtab.o
> -rw-rw-r-- 1 ynakam ynakam 29284 Mar 27 05:10 policydb.o
> -rw-rw-r-- 1 ynakam ynakam  2576 Mar 27 05:10 policydb_convert.o
> -rw-rw-r-- 1 ynakam ynakam  2396 Mar 27 05:10 policydb_public.o
> Above are compiled with -Os option.
> 
> So, to preserve bool at least 43.6 k is necessary.

Nakamura, Isn't it a bit rough-grained measurement?

For example, policydb_init() calls the following functions internally:
  - symtab_init() defined at symtab.c
  - avrule_block_create() defined at avrule_block.c
  - avrule_decl_create() defined at avrule_block.c
  - avtab_init() defined at avtab.c
  - roles_init() defined at policydb.c
  - cond_policydb_init() defined at conditional.c
  - avtab_destroy() defined at avtab.c
  - hashtab_destroy() defined at hashtab.c
  - avrule_block_list_destroy() defined at avrule_block.c

So, we also have to include symtab.c, avrule_block.c, avtab.c, conditional.c,
hashtab.c and avrule_block.c additionally for only policydb_init().

It is not so easy work as we can end up quickly, I think.

Thanks,

> I want boolean to be enabled/disabled by build option of libselinux/sepol and BusyBox.
> 
>> I want to mention that separating libselinux/libsepol is not the only way
>> to reduce binary size.
>> Is it possible to replace some functions rare needed in the target system
>> by empty implemented functions, isn't it? I think this approach enables
>> more flexible selection of functionalities than the simple separation.
> Yes, this implementation is one possibility. 
> This may be better than only separating libselinux/sepol.
> 
> BTW, in Japanese chat, 
> you and Shinji said too fine-grained selection will not be understood by 
> embedded developers.
> 
> I've come up with three selections.
> 1) Full-featured SELinux
> 2) Tiny-SELinux for embedded device with poor resource
> = 1) - semanage - boolean - user space object manager etc
> 3) Tiny-SELinux for mobile PDA(richer embedded device)
>  2) + boolean
> 
> Regards,

-- 
Open Source Software Promotion Center, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Russell Coker]

On Wednesday 28 March 2007 04:43, "Christopher J. PeBenito" 
<cpebenito@tresys.com> wrote:
> > > > same boolean states.  The only time it boots is because the battery
> > > > was just dead, or you force it because the system is locked up (or
> > > > some similar reason). Both reset the device state too, and then
> > > > falling back to the defaults would be the anticipated behavior.  If a

Except of course if it's not desired.

> > > > lock down is supposed to survive even that, I would argue that its
> > > > not a state, its a configuration and that the tunables are the way to
> > > > go.

I can imagine a situation where a wireless PDA device has booleans set when 
leaving a secure area.  When returning to a secure area an RSA based 
authentication mechanism could be used to inform a management program to 
change the boolean values.

> A PDA is going to have more backed storage than RAM.

This is wrong.  I have two iPaQ's that have 32M of flash and 64M of RAM.  I am 
not running out of either and expect that which you find limiting would 
depend greatly on application.

Incidentally rumor has it that when manufacturing such devices RAM is cheaper 
than flash, I'm not sure whether the rumor is true.  But the incidence of 
small devices using ram-disks for data that could be better stored on flash 
seems to indicate that it might be.

> I would argue that 
> the tunables solution is the better solution from a memory optimization
> perspective.  Why waste precious RAM on unused configuration rules in
> conditionals, when you have roomier flash-backed storage for tunables?

I think that it would be good to have the option to disable each of these 
facilities at compile time and let the embedded developer choose the minimal 
set of features that meet their requirements.

> More specialized systems that have tighter constraints aren't going to
> have these configuration options since they're much more static than a
> general purpose device like a PDA.

For such things TOMOYO might be a good option.  SE Linux is designed for 
general purpose computers.  When you get down to an embedded device with 4M 
of RAM and 8M of flash that only runs three or four programs then TOMOYO may 
have an advantage.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Stephen Smalley]

On Wed, 2007-03-28 at 10:57 +0900, KaiGai Kohei wrote:
> >> The SELinux for embedded in my brain(future SEDiet work) for now is following.
> >> * Embedded SELinux development kit is prepared and it has following features.
> >> * BusyBox includes SELinux commands
> >> * Developers can choose required features(boolean, module, semanage etc)
> >> * To implement it following will be necessary.
> >> * libselinux/libsepol/libsemanage is separated
> >> * Something like ENABLE_BOOLEAN, ENABLE_MODULE, ENABLE_SEMANAGE is embedded in source codes of libse*, BusyBox.
> >> * Least set of refpolicy is prepared: 
> >>   - only core policy(kernel policy module?) and macros are enabled by default
> >>   - supports both modular and monolitic
> >>   - To write new policy, SEEdit or other tools can be used
> >>   - has a compiler that has feature for size optimization
> > 
> > For the most part, this approach sounds fine, and I suspect that you
> > could even introduce a build option for creating a minimal subset of
> > libselinux as well as the other libraries.  Note that the loadable
> > policy module support depends on libsemanage, so I doubt you would
> > support separate ENABLE_MODULE vs. ENABLE_SEMANAGE options unless you
> > just mean the set of utility programs.
> > 
> > Some specific questions and comments:
> > 1) Do you think you will need the legacy support for setting local
> > persistent booleans without using libsemanage?  We were planning on
> > dropping that support out of libselinux and libsepol in the 2.x/devel
> > series.
> 
> I want to mention that separating libselinux/libsepol is not the only way
> to reduce binary size.
> Is it possible to replace some functions rare needed in the target system
> by empty implemented functions, isn't it? I think this approach enables
> more flexible selection of functionalities than the simple separation.

You don't even necessarily have to provide function stubs; that's what I
meant by a cut-down version of the libraries - we could provide build
options to create minimal subsets of each library.

> The typical example is userspace avc. I think seldom people use userspace
> object managers like XACE/SELinux on embedded systems.
> The sum of avc.o, avc_internal.o and avc_sidtab.o is about 32kb (on i386).
> Because the size of libselinux.a is about 146kb, we will be able to reduce
> about 20% of binary size.

Yes, that makes sense.
> 
> Currently, I don't have actual measurement of the minimum binary size of
> libsepol needed to handle preserving boolean variables and so on.
> Who can estimate it?

You'd start from sepol_genbools_array() and work through the
dependencies.  But you don't need the rest of the genbools
functionality, including the parser.

-- 
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: [busybox:00575] Re: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Stephen Smalley]

On Wed, 2007-03-28 at 18:12 +0900, KaiGai Kohei wrote:
> Yuichi Nakamura wrote:
> > On Wed, 28 Mar 2007 10:57:25 +0900
> > KaiGai Kohei  wrote:
> >> Currently, I don't have actual measurement of the minimum binary size of
> >> libsepol needed to handle preserving boolean variables and so on.
> >> Who can estimate it?
> > 
> > It seems that "sepol_genbools_array" libsepol function 
> > is necessary to preserve boolean.
> > 
> > And sepol_genbools_array uses following:
> > -From policydb.o
> >  policydb_init
> >  policydb_destroy
> > - From policydb_convert.o
> >  policydb_from_image
> > - From policydb_public.o
> >  policydb_write
> > -From conditional.o
> >  evaluate_conds
> > -From  hashtab.o
> >  hashtab_search
> > 
> > Then:
> > $ ls -l policydb.o hashtab.o conditional.o  policydb_convert.o policydb_public.o
> > -rw-rw-r-- 1 ynakam ynakam  6856 Mar 27 05:10 conditional.o
> > -rw-rw-r-- 1 ynakam ynakam  2540 Mar 27 05:10 hashtab.o
> > -rw-rw-r-- 1 ynakam ynakam 29284 Mar 27 05:10 policydb.o
> > -rw-rw-r-- 1 ynakam ynakam  2576 Mar 27 05:10 policydb_convert.o
> > -rw-rw-r-- 1 ynakam ynakam  2396 Mar 27 05:10 policydb_public.o
> > Above are compiled with -Os option.
> > 
> > So, to preserve bool at least 43.6 k is necessary.
> 
> Nakamura, Isn't it a bit rough-grained measurement?
> 
> For example, policydb_init() calls the following functions internally:
>   - symtab_init() defined at symtab.c
>   - avrule_block_create() defined at avrule_block.c
>   - avrule_decl_create() defined at avrule_block.c
>   - avtab_init() defined at avtab.c
>   - roles_init() defined at policydb.c
>   - cond_policydb_init() defined at conditional.c
>   - avtab_destroy() defined at avtab.c
>   - hashtab_destroy() defined at hashtab.c
>   - avrule_block_list_destroy() defined at avrule_block.c
> 
> So, we also have to include symtab.c, avrule_block.c, avtab.c, conditional.c,
> hashtab.c and avrule_block.c additionally for only policydb_init().

You don't actually need any of the code for the policy module format
(which is presently interwoven with the rest, since the policydb
structure supports both module and kernel formats).  A lot of that will
boil away from the new policy representation.

> 
> It is not so easy work as we can end up quickly, I think.
> 
> Thanks,
> 
> > I want boolean to be enabled/disabled by build option of libselinux/sepol and BusyBox.
> > 
> >> I want to mention that separating libselinux/libsepol is not the only way
> >> to reduce binary size.
> >> Is it possible to replace some functions rare needed in the target system
> >> by empty implemented functions, isn't it? I think this approach enables
> >> more flexible selection of functionalities than the simple separation.
> > Yes, this implementation is one possibility. 
> > This may be better than only separating libselinux/sepol.
> > 
> > BTW, in Japanese chat, 
> > you and Shinji said too fine-grained selection will not be understood by 
> > embedded developers.
> > 
> > I've come up with three selections.
> > 1) Full-featured SELinux
> > 2) Tiny-SELinux for embedded device with poor resource
> > = 1) - semanage - boolean - user space object manager etc
> > 3) Tiny-SELinux for mobile PDA(richer embedded device)
> >  2) + boolean
> > 
> > Regards,
> 
-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Stephen Smalley]

On Wed, 2007-03-28 at 21:26 +1100, Russell Coker wrote:
> On Wednesday 28 March 2007 04:43, "Christopher J. PeBenito" 
> <cpebenito@tresys.com> wrote:
> > > > > same boolean states.  The only time it boots is because the battery
> > > > > was just dead, or you force it because the system is locked up (or
> > > > > some similar reason). Both reset the device state too, and then
> > > > > falling back to the defaults would be the anticipated behavior.  If a
> 
> Except of course if it's not desired.
> 
> > > > > lock down is supposed to survive even that, I would argue that its
> > > > > not a state, its a configuration and that the tunables are the way to
> > > > > go.
> 
> I can imagine a situation where a wireless PDA device has booleans set when 
> leaving a secure area.  When returning to a secure area an RSA based 
> authentication mechanism could be used to inform a management program to 
> change the boolean values.
> 
> > A PDA is going to have more backed storage than RAM.
> 
> This is wrong.  I have two iPaQ's that have 32M of flash and 64M of RAM.  I am 
> not running out of either and expect that which you find limiting would 
> depend greatly on application.
> 
> Incidentally rumor has it that when manufacturing such devices RAM is cheaper 
> than flash, I'm not sure whether the rumor is true.  But the incidence of 
> small devices using ram-disks for data that could be better stored on flash 
> seems to indicate that it might be.
> 
> > I would argue that 
> > the tunables solution is the better solution from a memory optimization
> > perspective.  Why waste precious RAM on unused configuration rules in
> > conditionals, when you have roomier flash-backed storage for tunables?
> 
> I think that it would be good to have the option to disable each of these 
> facilities at compile time and let the embedded developer choose the minimal 
> set of features that meet their requirements.
> 
> > More specialized systems that have tighter constraints aren't going to
> > have these configuration options since they're much more static than a
> > general purpose device like a PDA.
> 
> For such things TOMOYO might be a good option.  SE Linux is designed for 
> general purpose computers.  When you get down to an embedded device with 4M 
> of RAM and 8M of flash that only runs three or four programs then TOMOYO may 
> have an advantage.

SELinux (like Linux) should scale across the full range.  If it doesn't
presently, we should work to make it so.

(And I doubt you'd recommend TOMOYO if you read the code)

-- 
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Christopher J. PeBenito]

On Wed, 2007-03-28 at 21:26 +1100, Russell Coker wrote:
> On Wednesday 28 March 2007 04:43, "Christopher J. PeBenito" 
> <cpebenito@tresys.com> wrote:
> > > > > same boolean states.  The only time it boots is because the battery
> > > > > was just dead, or you force it because the system is locked up (or
> > > > > some similar reason). Both reset the device state too, and then
> > > > > falling back to the defaults would be the anticipated behavior.  If a
> 
> Except of course if it's not desired.
> 
> > > > > lock down is supposed to survive even that, I would argue that its
> > > > > not a state, its a configuration and that the tunables are the way to
> > > > > go.
> 
> I can imagine a situation where a wireless PDA device has booleans set when 
> leaving a secure area.  When returning to a secure area an RSA based 
> authentication mechanism could be used to inform a management program to 
> change the boolean values.

I've already stated my position on this.  I don't think this is any
different than Karl's docked/undocked example.

> > A PDA is going to have more backed storage than RAM.
> 
> This is wrong.  I have two iPaQ's that have 32M of flash and 64M of RAM.  I am 
> not running out of either and expect that which you find limiting would 
> depend greatly on application.

I disagree, I think this is the past.  Especially now that PDAs have
memory card slots so you can put 2GB+ into them.

-- 
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: [busybox:00575] Re: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Joshua Brindle]

Stephen Smalley wrote:
> On Wed, 2007-03-28 at 18:12 +0900, KaiGai Kohei wrote:
>> Yuichi Nakamura wrote:
>>> On Wed, 28 Mar 2007 10:57:25 +0900
>>> KaiGai Kohei  wrote:
>>>> Currently, I don't have actual measurement of the minimum binary size of
>>>> libsepol needed to handle preserving boolean variables and so on.
>>>> Who can estimate it?
>>> It seems that "sepol_genbools_array" libsepol function 
>>> is necessary to preserve boolean.
>>>
>>> And sepol_genbools_array uses following:
>>> -From policydb.o
>>>  policydb_init
>>>  policydb_destroy
>>> - From policydb_convert.o
>>>  policydb_from_image
>>> - From policydb_public.o
>>>  policydb_write
>>> -From conditional.o
>>>  evaluate_conds
>>> -From  hashtab.o
>>>  hashtab_search
>>>
>>> Then:
>>> $ ls -l policydb.o hashtab.o conditional.o  policydb_convert.o policydb_public.o
>>> -rw-rw-r-- 1 ynakam ynakam  6856 Mar 27 05:10 conditional.o
>>> -rw-rw-r-- 1 ynakam ynakam  2540 Mar 27 05:10 hashtab.o
>>> -rw-rw-r-- 1 ynakam ynakam 29284 Mar 27 05:10 policydb.o
>>> -rw-rw-r-- 1 ynakam ynakam  2576 Mar 27 05:10 policydb_convert.o
>>> -rw-rw-r-- 1 ynakam ynakam  2396 Mar 27 05:10 policydb_public.o
>>> Above are compiled with -Os option.
>>>
>>> So, to preserve bool at least 43.6 k is necessary.
>> Nakamura, Isn't it a bit rough-grained measurement?
>>
>> For example, policydb_init() calls the following functions internally:
>>   - symtab_init() defined at symtab.c
>>   - avrule_block_create() defined at avrule_block.c
>>   - avrule_decl_create() defined at avrule_block.c
>>   - avtab_init() defined at avtab.c
>>   - roles_init() defined at policydb.c
>>   - cond_policydb_init() defined at conditional.c
>>   - avtab_destroy() defined at avtab.c
>>   - hashtab_destroy() defined at hashtab.c
>>   - avrule_block_list_destroy() defined at avrule_block.c
>>
>> So, we also have to include symtab.c, avrule_block.c, avtab.c, conditional.c,
>> hashtab.c and avrule_block.c additionally for only policydb_init().
> 
> You don't actually need any of the code for the policy module format
> (which is presently interwoven with the rest, since the policydb
> structure supports both module and kernel formats).  A lot of that will
> boil away from the new policy representation.
> 

Presumably all of the policy management will operate on the new 
representation rather than the kernel format so bringing in any 
management at all brings in all of the module format code.


--
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: Separating libselinux/libsepol (Was: Re: BusyBox: load_policy applet)

[Russell Coker]

On Wednesday 28 March 2007 22:06, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > For such things TOMOYO might be a good option.  SE Linux is designed for
> > general purpose computers.  When you get down to an embedded device with
> > 4M of RAM and 8M of flash that only runs three or four programs then
> > TOMOYO may have an advantage.
>
> SELinux (like Linux) should scale across the full range.  If it doesn't
> presently, we should work to make it so.

For the smallest possible resource use on a machine that performs a limited 
number of tasks the best way to develop the policy is to test all permitted 
actions and then develop a policy that allows nothing else.

It would be quite possible to do this with SE Linux, however it would require 
at a minimum a separate executable for each task that is performed.

TOMOYO changes security context based on executing a path name and therefore 
you could have the program that is the main purpose of an embedded device as 
a busybox module and have only one executable in the system.

But I think that the real issue will be how long it takes for the minimum 
embedded system to become equal to my iPaQ's.  I believe that I have 
demonstrated that my iPaQ's (32M of flash and 64M of RAM) are more than 
adequate to run SE Linux, when such systems are shipped on a single chip the 
need for optimisation to smaller hardware will be removed.  I don't think 
that we have long to wait.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development


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