Been looking at further shrinkage of the SELinux footprint on Linux.

Been looking at further shrinkage of the SELinux footprint on Linux.

[Daniel J Walsh]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We are trying to shrink out cloud image as small as possible.  One idea was to
shrink SELinux Policy footprint by adding compression to it.

Here is a patch I have been fooling around with which would read a policy.29
file if it was compressed with xz.

xz compression does around a 90% compression on the policy file,  and does not
slow the load in any meaningfull way.

I also have done a patch to try out gzip.

gzip and xz are already used in systemd, which means we would not need to add
a new requirement to the minimal system.

xz seems quicker and smaller then gzip.

Have not started playing with libsemanage yet.

What do you think?  Is xz availabel on Android?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJxXnUACgkQrlYvE4MpobNR9QCgx4AMRM+0TR0mqwvPikvj6mGH
O1UAn0OIwFNTmQ2zIBwtB65IwfqfsEq2
=dBjb
-----END PGP SIGNATURE-----

[-- Attachment #2: libselinux_lzma.patch --]
[-- Type: text/x-patch, Size: 4542 bytes --]

diff --git a/libselinux/src/Makefile b/libselinux/src/Makefile
index 02dd829..6dfdb46 100644
--- a/libselinux/src/Makefile
+++ b/libselinux/src/Makefile
@@ -114,7 +114,7 @@ $(LIBA): $(OBJS)
 	$(RANLIB) $@
 
 $(LIBSO): $(LOBJS)
-	$(CC) $(CFLAGS) -shared -o $@ $^ -lpcre -ldl $(LDFLAGS) -L$(LIBDIR) -Wl,-soname,$(LIBSO),-z,defs,-z,relro
+	$(CC) $(CFLAGS) -shared -o $@ $^ -lpcre -llzma -ldl $(LDFLAGS) -L$(LIBDIR) -Wl,-soname,$(LIBSO),-z,defs,-z,relro
 	ln -sf $@ $(TARGET) 
 
 $(LIBPC): $(LIBPC).in ../VERSION
diff --git a/libselinux/src/load_policy.c b/libselinux/src/load_policy.c
index e419f1a..275672d 100644
--- a/libselinux/src/load_policy.c
+++ b/libselinux/src/load_policy.c
@@ -16,6 +16,82 @@
 #include <dlfcn.h>
 #include "policy.h"
 #include <limits.h>
+#include <lzma.h>
+
+static char *lzmaread(int fd, size_t *rsize) {
+	int capacity = 64*1024;
+	char *buf = NULL;
+	int tmpsize = 8 * 1024;
+	unsigned char tmp[tmpsize];
+	unsigned char tmp_out[tmpsize];
+	size_t size = 0;
+	lzma_stream strm = LZMA_STREAM_INIT;
+	lzma_action action = LZMA_RUN;
+	lzma_ret ret;
+	
+	FILE *stream = fdopen (fd, "r");
+	if (!stream) {
+		return NULL;
+	}
+	ret = lzma_stream_decoder(&strm, UINT64_MAX,
+				  LZMA_CONCATENATED);
+	
+	strm.avail_in = 0;
+	strm.next_out = tmp_out;
+	strm.avail_out = tmpsize;
+	
+	buf = (char *) malloc (capacity);
+	if (!buf)
+		goto err;
+	
+	while (1) {
+		if (strm.avail_in == 0) {
+			strm.next_in = tmp;
+			strm.avail_in = fread(tmp, 1, tmpsize, stream);
+			
+			if (ferror(stream)) {
+				// POSIX says that fread() sets errno if
+				// an error occurred. ferror() doesn't
+				// touch errno.
+				goto err;
+			}
+			if (feof(stream)) action = LZMA_FINISH;
+		}
+		
+		ret = lzma_code(&strm, action);
+		
+		// Write and check write error before checking decoder error.
+		// This way as much data as possible gets written to output
+		// even if decoder detected an error.
+		if (strm.avail_out == 0 || ret != LZMA_OK) {
+			const size_t num =  tmpsize - strm.avail_out;
+			if (num > capacity) {
+				buf = (char*) realloc (buf, size*2);
+				capacity = size;
+			}
+			memcpy (buf+size, tmp_out, num);
+			capacity -= num;
+			size += num;
+			strm.next_out = tmp_out;
+			strm.avail_out = tmpsize;
+		}
+		if (ret != LZMA_OK) {
+			if (ret == LZMA_STREAM_END) {
+				break;
+			} else {
+				goto err;
+			}
+		}
+	}
+	*rsize = size;
+	
+	goto exit;
+err:
+	free(buf); buf = NULL;
+exit:
+	lzma_end(&strm);
+	return buf;
+}
 
 int security_load_policy(void *data, size_t len)
 {
@@ -55,7 +131,7 @@ int selinux_mkload_policy(int preservebools)
 	struct stat sb;
 	struct utsname uts;
 	size_t size;
-	void *map, *data;
+	void *map = NULL, *data=NULL;
 	int fd, rc = -1, prot;
 	sepol_policydb_t *policydb;
 	sepol_policy_file_t *pf;
@@ -181,24 +257,28 @@ checkbool:
 		goto dlclose;
 	}
 
-	if (fstat(fd, &sb) < 0) {
-		fprintf(stderr,
-			"SELinux:  Could not stat policy file %s:  %s\n",
-			path, strerror(errno));
-		goto close;
-	}
-
-	prot = PROT_READ;
-	if (setlocaldefs || preservebools)
-		prot |= PROT_WRITE;
+	data = lzmaread(fd,&size);
 
-	size = sb.st_size;
-	data = map = mmap(NULL, size, prot, MAP_PRIVATE, fd, 0);
-	if (map == MAP_FAILED) {
-		fprintf(stderr,
-			"SELinux:  Could not map policy file %s:  %s\n",
+	if (!data) {
+		if (fstat(fd, &sb) < 0) {
+			fprintf(stderr,
+				"SELinux:  Could not stat policy file %s:  %s\n",
 			path, strerror(errno));
-		goto close;
+			goto close;
+		}
+		
+		prot = PROT_READ;
+		if (setlocaldefs || preservebools)
+			prot |= PROT_WRITE;
+		
+		size = sb.st_size;
+		data = map = mmap(NULL, size, prot, MAP_PRIVATE, fd, 0);
+		if (map == MAP_FAILED) {
+			fprintf(stderr,
+				"SELinux:  Could not map policy file %s:  %s\n",
+				path, strerror(errno));
+			goto close;
+		}
 	}
 
 	if (vers > kernvers && usesepol) {
@@ -210,6 +290,8 @@ checkbool:
 			goto unmap;
 		}
 		policy_file_set_mem(pf, data, size);
+		if (!map)
+			free(data);
 		if (policydb_read(policydb, pf)) {
 			policy_file_free(pf);
 			policydb_free(policydb);
@@ -223,7 +305,8 @@ checkbool:
 				path);
 			policy_file_free(pf);
 			policydb_free(policydb);
-			munmap(map, sb.st_size);
+			if (map)
+				munmap(map, sb.st_size);
 			close(fd);
 			vers--;
 			goto search;
@@ -275,7 +358,7 @@ checkbool:
 #endif
 	}
 
-
+	
 	rc = security_load_policy(data, size);
 	
 	if (rc)
@@ -286,7 +369,8 @@ checkbool:
       unmap:
 	if (data != map)
 		free(data);
-	munmap(map, sb.st_size);
+	if (map)
+		munmap(map, sb.st_size);
       close:
 	close(fd);
       dlclose:

[-- Attachment #3: compare --]
[-- Type: text/plain, Size: 582 bytes --]

Information gathered from Fedora 21/Rawhide.

Current Load_policy

real	0m0.848s
user	0m0.047s
sys	0m0.283s

real	0m0.846s
user	0m0.094s
sys	0m0.625s

real	0m0.850s
user	0m0.114s
sys	0m0.717s

xz Load_policy
real	0m0.885s
user	0m0.084s
sys	0m0.382s

real	0m0.878s
user	0m0.090s
sys	0m0.453s

real	0m0.886s
user	0m0.128s
sys	0m0.572s

du -s *
2584	policy.29
384	policy.29.xz

valgrind shows 
mmap load_policy
total heap usage: 443,521 allocs, 443,519 frees, 34,795,153 bytes allocated
Versus
xz load_policy
total heap usage: 443,509 allocs, 443,507 frees, 18,115,873 bytes allocated

Re: Been looking at further shrinkage of the SELinux footprint on Linux.

[Joshua Brindle]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> We are trying to shrink out cloud image as small as possible.  One idea was to
> shrink SELinux Policy footprint by adding compression to it.
>
> Here is a patch I have been fooling around with which would read a policy.29
> file if it was compressed with xz.
>
> xz compression does around a 90% compression on the policy file,  and does not
> slow the load in any meaningfull way.
>
> I also have done a patch to try out gzip.
>
> gzip and xz are already used in systemd, which means we would not need to add
> a new requirement to the minimal system.
>
> xz seems quicker and smaller then gzip.
>
> Have not started playing with libsemanage yet.
>
> What do you think?  Is xz availabel on Android?

No.

Is there a reason you wouldn't just have systemd decompress it before 
loading it? I guess if you want all the existing tools/libraries to work 
without any changes it would need to be build in to libselinux rather 
done outside of the library.

Android's libselinux is forked anyway so this probably wouldn't flow to 
Android.

--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Stephen Smalley]

On 10/30/2013 03:31 PM, Daniel J Walsh wrote:
> We are trying to shrink out cloud image as small as possible.  One idea was to
> shrink SELinux Policy footprint by adding compression to it.
> 
> Here is a patch I have been fooling around with which would read a policy.29
> file if it was compressed with xz.
> 
> xz compression does around a 90% compression on the policy file,  and does not
> slow the load in any meaningfull way.
> 
> I also have done a patch to try out gzip.
> 
> gzip and xz are already used in systemd, which means we would not need to add
> a new requirement to the minimal system.
> 
> xz seems quicker and smaller then gzip.
> 
> Have not started playing with libsemanage yet.
> 
> What do you think?  Is xz availabel on Android?

Personally, I'd much rather see work done on shrinking the actual policy
size in Fedora rather than just compressing it.  Both by reducing the
overall size of refpolicy through coalescing similar domains/types and
by making better use of the work that has already been done to support
putting policy modules into rpms and only installing what actually get used.

On the former, I wrote a little tool for Android called sepolicy-analyze
that identifies all equivalent types in the policy.  It works nicely on
the Android policy but unfortunately I gave up waiting on it running on
Fedora policy because it is so large.  We're also looking at extending
that tool to identify isomorphic types, not just equivalent ones.  I
know apol has a similar feature under the Analysis tab (Types
relationship summary) but it only does it on a pairwise basis; there
doesn't seem to be any way to apply it systematically.

Anyway, with regard to impact on Android of your patch, it won't affect
it as libselinux is forked (and significantly modified) there as Joshua
noted and we don't bring over any of libsemanage or policycoreutils
either (we reimplemented the pieces of policycoreutils that we wanted in
the Android init and toolbox programs, just as people previously did in
busybox).  And we only build/use libsepol and checkpolicy on the build
host, not the device.  So I think the only real concern is whether this
is an acceptable dependency on conventional Linux distros.









--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/30/2013 04:14 PM, Stephen Smalley wrote:
> On 10/30/2013 03:31 PM, Daniel J Walsh wrote:
>> We are trying to shrink out cloud image as small as possible.  One idea
>> was to shrink SELinux Policy footprint by adding compression to it.
>> 
>> Here is a patch I have been fooling around with which would read a
>> policy.29 file if it was compressed with xz.
>> 
>> xz compression does around a 90% compression on the policy file,  and
>> does not slow the load in any meaningfull way.
>> 
>> I also have done a patch to try out gzip.
>> 
>> gzip and xz are already used in systemd, which means we would not need to
>> add a new requirement to the minimal system.
>> 
>> xz seems quicker and smaller then gzip.
>> 
>> Have not started playing with libsemanage yet.
>> 
>> What do you think?  Is xz availabel on Android?
> 
> Personally, I'd much rather see work done on shrinking the actual policy 
> size in Fedora rather than just compressing it.  Both by reducing the 
> overall size of refpolicy through coalescing similar domains/types and by
> making better use of the work that has already been done to support putting
> policy modules into rpms and only installing what actually get used.
> 
> On the former, I wrote a little tool for Android called sepolicy-analyze 
> that identifies all equivalent types in the policy.  It works nicely on the
> Android policy but unfortunately I gave up waiting on it running on Fedora
> policy because it is so large.  We're also looking at extending that tool
> to identify isomorphic types, not just equivalent ones.  I know apol has a
> similar feature under the Analysis tab (Types relationship summary) but it
> only does it on a pairwise basis; there doesn't seem to be any way to apply
> it systematically.
> 
> Anyway, with regard to impact on Android of your patch, it won't affect it
> as libselinux is forked (and significantly modified) there as Joshua noted
> and we don't bring over any of libsemanage or policycoreutils either (we
> reimplemented the pieces of policycoreutils that we wanted in the Android
> init and toolbox programs, just as people previously did in busybox).  And
> we only build/use libsepol and checkpolicy on the build host, not the
> device.  So I think the only real concern is whether this is an acceptable
> dependency on conventional Linux distros.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 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.
> 
Well we have done some work on combining like domains, see antivirus and
spamassassin, but this is a lot of work which no one has time for.

I would love to see the mailserver and mailclients domains combined.

If people want to suggest or more importantly submit patches to combine other
domains, I am all for it.

Problems with shipping policy within rpm still exists. although we (Red Hat)
are at least moving toward layered products shipping their own policy.
openstack-selinux, openshift-selinux, gluster-selinux.  This is more for them
updating quicker then RHEL.

1. semanage is slowwwwwwwww.  If we ran all pp files without combining them
into a single transaction the installation  and yum updates would take a long
time.
2.  Cordination between domains, we put a fix into an interface and we need to
trigger 10 packages to update.

For every apache bug in policy, do we want to wait for an update apache
package, or do we ship lots more packages.

3. Uninstall of types leaves unlabeled_t content on disk.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJxbeYACgkQrlYvE4MpobOrgwCgqurQA/VYLedbOs4nKzysnsIy
Q8AAoOd7jQXImOyRbhDDoMHWhzZ1d/h4
=V0Rp
-----END PGP SIGNATURE-----

--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Stephen Smalley]

On 10/30/2013 04:36 PM, Daniel J Walsh wrote:
> Well we have done some work on combining like domains, see antivirus and
> spamassassin, but this is a lot of work which no one has time for.
> 
> I would love to see the mailserver and mailclients domains combined.
> 
> If people want to suggest or more importantly submit patches to combine other
> domains, I am all for it.
> 
> Problems with shipping policy within rpm still exists. although we (Red Hat)
> are at least moving toward layered products shipping their own policy.
> openstack-selinux, openshift-selinux, gluster-selinux.  This is more for them
> updating quicker then RHEL.
> 
> 1. semanage is slowwwwwwwww.  If we ran all pp files without combining them
> into a single transaction the installation  and yum updates would take a long
> time.

Yes, I have to wonder if we don't need a complete overhaul/replacement
of libsemanage (+ module portions of libsepol).  It seems like
semodule/semanage transactions are far slower than running the entire
policy through checkpolicy again (i.e. just using source modules and
running them through m4 + checkpolicy on each transaction, ala the
source policy module work that sadly has yet to reach maturity/completion).

> 2.  Cordination between domains, we put a fix into an interface and we need to
> trigger 10 packages to update.
> 
> For every apache bug in policy, do we want to wait for an update apache
> package, or do we ship lots more packages.

That's also fixed if we go with source modules, right, since interface
change would get applied by the m4 + checkpolicy cycle.  Or CIL.

> 3. Uninstall of types leaves unlabeled_t content on disk.

That's the only one that seems fundamental.  What if we pushed all file
type declarations into their own module linked to the base filesystem
package and just always installed that?  That won't affect policy size
substantially; it is the allow rules that are the issue IIUC, not just
the type decls.




--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Stephen Smalley]

On 10/30/2013 04:43 PM, Stephen Smalley wrote:
> On 10/30/2013 04:36 PM, Daniel J Walsh wrote:
>> Well we have done some work on combining like domains, see antivirus and
>> spamassassin, but this is a lot of work which no one has time for.
>>
>> I would love to see the mailserver and mailclients domains combined.
>>
>> If people want to suggest or more importantly submit patches to combine other
>> domains, I am all for it.
>>
>> Problems with shipping policy within rpm still exists. although we (Red Hat)
>> are at least moving toward layered products shipping their own policy.
>> openstack-selinux, openshift-selinux, gluster-selinux.  This is more for them
>> updating quicker then RHEL.
>>
>> 1. semanage is slowwwwwwwww.  If we ran all pp files without combining them
>> into a single transaction the installation  and yum updates would take a long
>> time.
> 
> Yes, I have to wonder if we don't need a complete overhaul/replacement
> of libsemanage (+ module portions of libsepol).  It seems like
> semodule/semanage transactions are far slower than running the entire
> policy through checkpolicy again (i.e. just using source modules and
> running them through m4 + checkpolicy on each transaction, ala the
> source policy module work that sadly has yet to reach maturity/completion).

However, on this note, I'm pretty sure that the rpm work allows you to
just collect up all of the policy modules and run semodule once at the
end (collections or whatever).  So that particular problem should be
solved already even for the binary modules.

> 
>> 2.  Cordination between domains, we put a fix into an interface and we need to
>> trigger 10 packages to update.
>>
>> For every apache bug in policy, do we want to wait for an update apache
>> package, or do we ship lots more packages.
> 
> That's also fixed if we go with source modules, right, since interface
> change would get applied by the m4 + checkpolicy cycle.  Or CIL.
> 
>> 3. Uninstall of types leaves unlabeled_t content on disk.
> 
> That's the only one that seems fundamental.  What if we pushed all file
> type declarations into their own module linked to the base filesystem
> package and just always installed that?  That won't affect policy size
> substantially; it is the allow rules that are the issue IIUC, not just
> the type decls.
> 
> 
> 


--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Colin Walters]

On Wed, 2013-10-30 at 15:31 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> We are trying to shrink out cloud image as small as possible.  One idea was to
> shrink SELinux Policy footprint by adding compression to it.
> 
> Here is a patch I have been fooling around with which would read a policy.29
> file if it was compressed with xz.

Given that security_load_policy() just copies the data from userspace,
rather than taking advantage of mmap in any way, it makes total sense to
me to ship it compressed.

xz is usually a better choice for new compression deployments since very
often you want its asymmetric tradeoff of good but expensive compression
and fast decompression, unlike the more symmetric gzip.

Since policy is only loaded occasionally, xz also makes sense to me.


--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Colin Walters]

On Wed, 2013-10-30 at 15:31 -0400, Daniel J Walsh wrote:

> Here is a patch I have been fooling around with which would read a policy.29
> file if it was compressed with xz.

Hm, it's kind of ugly to attempt to open the policy with LZMA and only
if that returns (any kind of error) fails fall back to the old code.
Wouldn't it be better to say check whether or not it starts with a new
magic number, like the kernel policydb_read() function does?

In other words have:

[New 32 bit magic number] [Compressed policy]



--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Stephen Smalley]

On 10/30/2013 06:01 PM, Colin Walters wrote:
> On Wed, 2013-10-30 at 15:31 -0400, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> We are trying to shrink out cloud image as small as possible.  One idea was to
>> shrink SELinux Policy footprint by adding compression to it.
>>
>> Here is a patch I have been fooling around with which would read a policy.29
>> file if it was compressed with xz.
> 
> Given that security_load_policy() just copies the data from userspace,
> rather than taking advantage of mmap in any way, it makes total sense to
> me to ship it compressed.

Maybe I misunderstood you, but the callers of security_load_policy()
(e.g. selinux_mkload_policy, selinux_init_load_policy) work by mmap'ing
the policy file and then passing that region to security_load_policy().
 They only currently have to copy it if they need to modify the policy
at load time (e.g. if the userspace policy version is newer than that
supported by the kernel and it needs to downgrade to the kernel version).

> 
> xz is usually a better choice for new compression deployments since very
> often you want its asymmetric tradeoff of good but expensive compression
> and fast decompression, unlike the more symmetric gzip.
> 
> Since policy is only loaded occasionally, xz also makes sense to me.
> 


--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Steve Lawrence]

On 10/30/2013 04:47 PM, Stephen Smalley wrote:
> On 10/30/2013 04:43 PM, Stephen Smalley wrote:
>> On 10/30/2013 04:36 PM, Daniel J Walsh wrote:
>>> Well we have done some work on combining like domains, see antivirus and
>>> spamassassin, but this is a lot of work which no one has time for.
>>>
>>> I would love to see the mailserver and mailclients domains combined.
>>>
>>> If people want to suggest or more importantly submit patches to combine other
>>> domains, I am all for it.
>>>
>>> Problems with shipping policy within rpm still exists. although we (Red Hat)
>>> are at least moving toward layered products shipping their own policy.
>>> openstack-selinux, openshift-selinux, gluster-selinux.  This is more for them
>>> updating quicker then RHEL.
>>>
>>> 1. semanage is slowwwwwwwww.  If we ran all pp files without combining them
>>> into a single transaction the installation  and yum updates would take a long
>>> time.
>>
>> Yes, I have to wonder if we don't need a complete overhaul/replacement
>> of libsemanage (+ module portions of libsepol).  It seems like
>> semodule/semanage transactions are far slower than running the entire
>> policy through checkpolicy again (i.e. just using source modules and
>> running them through m4 + checkpolicy on each transaction, ala the
>> source policy module work that sadly has yet to reach maturity/completion).
>
> However, on this note, I'm pretty sure that the rpm work allows you to
> just collect up all of the policy modules and run semodule once at the
> end (collections or whatever).  So that particular problem should be
> solved already even for the binary modules.
>

This is correct. the collection feature of RPM gathers up all selinux 
policies from all the rpms in the yum/rpm transaction and installs them 
all in a single semanage transaction. Note that although the work was 
upstreamed, last I checked, the building of the selinux plugin that 
performs the work to aggregate and install the policy modules is 
currently disabled on fedora.

>>
>>> 2.  Cordination between domains, we put a fix into an interface and we need to
>>> trigger 10 packages to update.
>>>
>>> For every apache bug in policy, do we want to wait for an update apache
>>> package, or do we ship lots more packages.
>>
>> That's also fixed if we go with source modules, right, since interface
>> change would get applied by the m4 + checkpolicy cycle.  Or CIL.
>>
>>> 3. Uninstall of types leaves unlabeled_t content on disk.
>>
>> That's the only one that seems fundamental.  What if we pushed all file
>> type declarations into their own module linked to the base filesystem
>> package and just always installed that?  That won't affect policy size
>> substantially; it is the allow rules that are the issue IIUC, not just
>> the type decls.
>>

The way this is handled in the RPM collection feature is modules are 
never uninstalled, even if the package that installed that module is. 
Not ideal, but it solves this problem.


--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Stephen Smalley]

On 10/31/2013 08:43 AM, Steve Lawrence wrote:
> On 10/30/2013 04:47 PM, Stephen Smalley wrote:
>> On 10/30/2013 04:43 PM, Stephen Smalley wrote:
>>> On 10/30/2013 04:36 PM, Daniel J Walsh wrote:
>>>> Well we have done some work on combining like domains, see antivirus
>>>> and
>>>> spamassassin, but this is a lot of work which no one has time for.
>>>>
>>>> I would love to see the mailserver and mailclients domains combined.
>>>>
>>>> If people want to suggest or more importantly submit patches to
>>>> combine other
>>>> domains, I am all for it.
>>>>
>>>> Problems with shipping policy within rpm still exists. although we
>>>> (Red Hat)
>>>> are at least moving toward layered products shipping their own policy.
>>>> openstack-selinux, openshift-selinux, gluster-selinux.  This is more
>>>> for them
>>>> updating quicker then RHEL.
>>>>
>>>> 1. semanage is slowwwwwwwww.  If we ran all pp files without
>>>> combining them
>>>> into a single transaction the installation  and yum updates would
>>>> take a long
>>>> time.
>>>
>>> Yes, I have to wonder if we don't need a complete overhaul/replacement
>>> of libsemanage (+ module portions of libsepol).  It seems like
>>> semodule/semanage transactions are far slower than running the entire
>>> policy through checkpolicy again (i.e. just using source modules and
>>> running them through m4 + checkpolicy on each transaction, ala the
>>> source policy module work that sadly has yet to reach
>>> maturity/completion).
>>
>> However, on this note, I'm pretty sure that the rpm work allows you to
>> just collect up all of the policy modules and run semodule once at the
>> end (collections or whatever).  So that particular problem should be
>> solved already even for the binary modules.
>>
> 
> This is correct. the collection feature of RPM gathers up all selinux
> policies from all the rpms in the yum/rpm transaction and installs them
> all in a single semanage transaction. Note that although the work was
> upstreamed, last I checked, the building of the selinux plugin that
> performs the work to aggregate and install the policy modules is
> currently disabled on fedora.

That seems surprising given that it was developed for Fedora originally.
 Can someone ping Panu or whoever is maintaining rpm these days and ask
why it is disabled or whether it can be enabled?

>>>> 3. Uninstall of types leaves unlabeled_t content on disk.
>>>
>>> That's the only one that seems fundamental.  What if we pushed all file
>>> type declarations into their own module linked to the base filesystem
>>> package and just always installed that?  That won't affect policy size
>>> substantially; it is the allow rules that are the issue IIUC, not just
>>> the type decls.
>>>
> 
> The way this is handled in the RPM collection feature is modules are
> never uninstalled, even if the package that installed that module is.
> Not ideal, but it solves this problem.

I guess the question is what behavior is desired here.  If you remove
the type itself, then these days it will get treated as unlabeled (so it
becomes inaccessible to anything that doesn't have permissions to
unlabeled, but that shouldn't be an issue for unconfined users) and if
someone later re-installs the package/policy, then it should get
remapped to its original context due to the deferred context mapping
support.  Is that sufficient?  If not, then my proposed approach above
of pushing all of the file type declarations into a single module
(probably the base module) and never removing them would allow the types
to always remain valid but they'd still be inaccessible except to
domains that are allowed access to file_type (e.g. unconfined) when you
remove the modules defining the allow rules.  Is that sufficient?  If
not, then your approach of never removing modules will work but seems
the least optimal to me.

--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/30/2013 07:54 PM, Colin Walters wrote:
> On Wed, 2013-10-30 at 15:31 -0400, Daniel J Walsh wrote:
> 
>> Here is a patch I have been fooling around with which would read a
>> policy.29 file if it was compressed with xz.
> 
> Hm, it's kind of ugly to attempt to open the policy with LZMA and only if
> that returns (any kind of error) fails fall back to the old code. Wouldn't
> it be better to say check whether or not it starts with a new magic number,
> like the kernel policydb_read() function does?
> 
> In other words have:
> 
> [New 32 bit magic number] [Compressed policy]
> 
> 
Yes I was first considering doing this, but went with the easy hack to get the
discussion going, and give me some numbers on speed of loading policy.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJyoSYACgkQrlYvE4MpobOK0wCgo0ybL6GQgf6e1JpoXRDwWdlh
JWkAn2UXnk55QusMCSmvU7t7/VhSVxF+
=jzi8
-----END PGP SIGNATURE-----

--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/31/2013 08:43 AM, Steve Lawrence wrote:
> On 10/30/2013 04:47 PM, Stephen Smalley wrote:
>> On 10/30/2013 04:43 PM, Stephen Smalley wrote:
>>> On 10/30/2013 04:36 PM, Daniel J Walsh wrote:
>>>> Well we have done some work on combining like domains, see antivirus
>>>> and spamassassin, but this is a lot of work which no one has time
>>>> for.
>>>> 
>>>> I would love to see the mailserver and mailclients domains combined.
>>>> 
>>>> If people want to suggest or more importantly submit patches to
>>>> combine other domains, I am all for it.
>>>> 
>>>> Problems with shipping policy within rpm still exists. although we
>>>> (Red Hat) are at least moving toward layered products shipping their
>>>> own policy. openstack-selinux, openshift-selinux, gluster-selinux.
>>>> This is more for them updating quicker then RHEL.
>>>> 
>>>> 1. semanage is slowwwwwwwww.  If we ran all pp files without
>>>> combining them into a single transaction the installation  and yum
>>>> updates would take a long time.
>>> 
>>> Yes, I have to wonder if we don't need a complete overhaul/replacement 
>>> of libsemanage (+ module portions of libsepol).  It seems like 
>>> semodule/semanage transactions are far slower than running the entire 
>>> policy through checkpolicy again (i.e. just using source modules and 
>>> running them through m4 + checkpolicy on each transaction, ala the 
>>> source policy module work that sadly has yet to reach
>>> maturity/completion).
>> 
>> However, on this note, I'm pretty sure that the rpm work allows you to 
>> just collect up all of the policy modules and run semodule once at the 
>> end (collections or whatever).  So that particular problem should be 
>> solved already even for the binary modules.
>> 
> 
> This is correct. the collection feature of RPM gathers up all selinux
> policies from all the rpms in the yum/rpm transaction and installs them all
> in a single semanage transaction. Note that although the work was
> upstreamed, last I checked, the building of the selinux plugin that
> performs the work to aggregate and install the policy modules is currently
> disabled on fedora.
> 
>>> 
>>>> 2.  Cordination between domains, we put a fix into an interface and
>>>> we need to trigger 10 packages to update.
>>>> 
>>>> For every apache bug in policy, do we want to wait for an update
>>>> apache package, or do we ship lots more packages.
>>> 
>>> That's also fixed if we go with source modules, right, since interface 
>>> change would get applied by the m4 + checkpolicy cycle.  Or CIL.
>>> 
>>>> 3. Uninstall of types leaves unlabeled_t content on disk.
>>> 
>>> That's the only one that seems fundamental.  What if we pushed all
>>> file type declarations into their own module linked to the base
>>> filesystem package and just always installed that?  That won't affect
>>> policy size substantially; it is the allow rules that are the issue
>>> IIUC, not just the type decls.
>>> 
> 
> The way this is handled in the RPM collection feature is modules are never 
> uninstalled, even if the package that installed that module is. Not ideal,
> but it solves this problem.
> 
> 
> -- 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.
Can you open a bugzilla on this, and show me point me at documentation on how
to use this.

In current Fedora we are attempting to ship a binary policy precompiled so we
do not take a long time/memory in initial install.  But it would be nice to
tell people to use the new feature to run their policy load in a transaction.

It would also be nice if we could do semanage commands within this transaction.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJypfQACgkQrlYvE4MpobOYvgCeKNApBdzF79GRlgxylcyacwGp
siQAoKdnXhyIa/x1ezXb0bMKCA0ZoOjq
=oReg
-----END PGP SIGNATURE-----

--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/31/2013 08:56 AM, Stephen Smalley wrote:
> On 10/31/2013 08:43 AM, Steve Lawrence wrote:
>> On 10/30/2013 04:47 PM, Stephen Smalley wrote:
>>> On 10/30/2013 04:43 PM, Stephen Smalley wrote:
>>>> On 10/30/2013 04:36 PM, Daniel J Walsh wrote:
>>>>> Well we have done some work on combining like domains, see
>>>>> antivirus and spamassassin, but this is a lot of work which no one
>>>>> has time for.
>>>>> 
>>>>> I would love to see the mailserver and mailclients domains
>>>>> combined.
>>>>> 
>>>>> If people want to suggest or more importantly submit patches to 
>>>>> combine other domains, I am all for it.
>>>>> 
>>>>> Problems with shipping policy within rpm still exists. although we 
>>>>> (Red Hat) are at least moving toward layered products shipping
>>>>> their own policy. openstack-selinux, openshift-selinux,
>>>>> gluster-selinux.  This is more for them updating quicker then
>>>>> RHEL.
>>>>> 
>>>>> 1. semanage is slowwwwwwwww.  If we ran all pp files without 
>>>>> combining them into a single transaction the installation  and yum
>>>>> updates would take a long time.
>>>> 
>>>> Yes, I have to wonder if we don't need a complete
>>>> overhaul/replacement of libsemanage (+ module portions of libsepol).
>>>> It seems like semodule/semanage transactions are far slower than
>>>> running the entire policy through checkpolicy again (i.e. just using
>>>> source modules and running them through m4 + checkpolicy on each
>>>> transaction, ala the source policy module work that sadly has yet to
>>>> reach maturity/completion).
>>> 
>>> However, on this note, I'm pretty sure that the rpm work allows you to 
>>> just collect up all of the policy modules and run semodule once at the 
>>> end (collections or whatever).  So that particular problem should be 
>>> solved already even for the binary modules.
>>> 
>> 
>> This is correct. the collection feature of RPM gathers up all selinux 
>> policies from all the rpms in the yum/rpm transaction and installs them 
>> all in a single semanage transaction. Note that although the work was 
>> upstreamed, last I checked, the building of the selinux plugin that 
>> performs the work to aggregate and install the policy modules is 
>> currently disabled on fedora.
> 
> That seems surprising given that it was developed for Fedora originally. 
> Can someone ping Panu or whoever is maintaining rpm these days and ask why
> it is disabled or whether it can be enabled?
> 
>>>>> 3. Uninstall of types leaves unlabeled_t content on disk.
>>>> 
>>>> That's the only one that seems fundamental.  What if we pushed all
>>>> file type declarations into their own module linked to the base
>>>> filesystem package and just always installed that?  That won't affect
>>>> policy size substantially; it is the allow rules that are the issue
>>>> IIUC, not just the type decls.
>>>> 
>> 
>> The way this is handled in the RPM collection feature is modules are 
>> never uninstalled, even if the package that installed that module is. Not
>> ideal, but it solves this problem.
> 
> I guess the question is what behavior is desired here.  If you remove the
> type itself, then these days it will get treated as unlabeled (so it 
> becomes inaccessible to anything that doesn't have permissions to 
> unlabeled, but that shouldn't be an issue for unconfined users) and if 
> someone later re-installs the package/policy, then it should get remapped
> to its original context due to the deferred context mapping support.  Is
> that sufficient?  If not, then my proposed approach above of pushing all of
> the file type declarations into a single module (probably the base module)
> and never removing them would allow the types to always remain valid but
> they'd still be inaccessible except to domains that are allowed access to
> file_type (e.g. unconfined) when you remove the modules defining the allow
> rules.  Is that sufficient?  If not, then your approach of never removing
> modules will work but seems the least optimal to me.
> 
Well I like the idea of defining alias for modules when they are not
installed.  The biggest problem I see is around executables and potentially
readable content.  If I install a package that labels something as
foobar_exec_t and leaves the content on uninstall, a confined domain that was
able to execute foobar_exec_t will now not be able to execute unlabeled_t.

If we could alias foobar_exec_t to bin_t when foobar.pp is not installed, then
we get a little closer to the default, and I don;t have restorecon -R -v
fixing unlabeled_t files.

similarly  foobar_usr content to -> usr_t, and foobar_etc_t to etc_t
foobar_var_t -> var_t ...


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJypu0ACgkQrlYvE4MpobPR7QCfbNb+dv1mBHrBXsXNK/v97t36
7lMAoODN4Uk/JtjsEVw3ksDNF2u+HpvT
=YwCv
-----END PGP SIGNATURE-----

--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Sven Vermeulen]

On Wed, Oct 30, 2013 at 9:36 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
[...]
>> On 10/30/2013 03:31 PM, Daniel J Walsh wrote:
>>> We are trying to shrink out cloud image as small as possible.  One idea
>>> was to shrink SELinux Policy footprint by adding compression to it.
[...]
>> Personally, I'd much rather see work done on shrinking the actual policy
>> size in Fedora rather than just compressing it.  Both by reducing the
>> overall size of refpolicy through coalescing similar domains/types and by
>> making better use of the work that has already been done to support putting
>> policy modules into rpms and only installing what actually get used.
[...]
> Well we have done some work on combining like domains, see antivirus and
> spamassassin, but this is a lot of work which no one has time for.
>
> I would love to see the mailserver and mailclients domains combined.
>
> If people want to suggest or more importantly submit patches to combine other
> domains, I am all for it.
>
> Problems with shipping policy within rpm still exists. although we (Red Hat)
> are at least moving toward layered products shipping their own policy.
> openstack-selinux, openshift-selinux, gluster-selinux.  This is more for them
> updating quicker then RHEL.

In Gentoo, we try to only install the SELinux policies related to the
package that is installed. So if a system does not have a web server,
no httpd policies are loaded. This works pretty well. My workstation
(which is where I do all my SELinux policy development on) has 100
policy modules loaded; my servers usually have around 50 to 60 modules
loaded. That makes running things like "semodule -B" rather smooth.
Not really fast, but one doesn't need to switch to another thing to do
while waiting (4 seconds on a VM I'm currently playing with).

When updates occur only on a module's .te file, it could even be
distributed towards the users easily (no need to do a full policy
refresh), although I usually wait and make a full policy release.

It probably doesn't take long for Fedora/RedHat to find out which
packages need which SELinux policy modules. A quick way to find them
is to parse the RPM file list and check the file contexts of the
SELinux policy tree for matches.

> For every apache bug in policy, do we want to wait for an update apache
> package, or do we ship lots more packages.

I'd go for the latter. Put the policies in their own RPMs.

Wkr,
  Sven Vermeulen

--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Casey Schaufler]

On 11/2/2013 9:42 AM, Sven Vermeulen wrote:
> On Wed, Oct 30, 2013 at 9:36 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> [...]
>>> On 10/30/2013 03:31 PM, Daniel J Walsh wrote:
>>>> We are trying to shrink out cloud image as small as possible.  One idea
>>>> was to shrink SELinux Policy footprint by adding compression to it.
> [...]
>>> Personally, I'd much rather see work done on shrinking the actual policy
>>> size in Fedora rather than just compressing it.  Both by reducing the
>>> overall size of refpolicy through coalescing similar domains/types and by
>>> making better use of the work that has already been done to support putting
>>> policy modules into rpms and only installing what actually get used.
> [...]
>> Well we have done some work on combining like domains, see antivirus and
>> spamassassin, but this is a lot of work which no one has time for.
>>
>> I would love to see the mailserver and mailclients domains combined.
>>
>> If people want to suggest or more importantly submit patches to combine other
>> domains, I am all for it.
>>
>> Problems with shipping policy within rpm still exists. although we (Red Hat)
>> are at least moving toward layered products shipping their own policy.
>> openstack-selinux, openshift-selinux, gluster-selinux.  This is more for them
>> updating quicker then RHEL.
> In Gentoo, we try to only install the SELinux policies related to the
> package that is installed. So if a system does not have a web server,
> no httpd policies are loaded. This works pretty well. My workstation
> (which is where I do all my SELinux policy development on) has 100
> policy modules loaded; my servers usually have around 50 to 60 modules
> loaded. That makes running things like "semodule -B" rather smooth.
> Not really fast, but one doesn't need to switch to another thing to do
> while waiting (4 seconds on a VM I'm currently playing with).

A lot of work is being done to improve the start-up time
of consumer (e.g. phones) devices and "disposable" VMs. We're
talking about people getting their knickers in a twist over
security adding 20 milliseconds to the boot process. Your
4 second semodule run is not going to fly.

> When updates occur only on a module's .te file, it could even be
> distributed towards the users easily (no need to do a full policy
> refresh), although I usually wait and make a full policy release.
>
> It probably doesn't take long for Fedora/RedHat to find out which
> packages need which SELinux policy modules. A quick way to find them
> is to parse the RPM file list and check the file contexts of the
> SELinux policy tree for matches.
>
>> For every apache bug in policy, do we want to wait for an update apache
>> package, or do we ship lots more packages.
> I'd go for the latter. Put the policies in their own RPMs.
>
> Wkr,
>   Sven Vermeulen
>
> --
> 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.
>


--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Joshua Brindle]

Casey Schaufler wrote:
> On 11/2/2013 9:42 AM, Sven Vermeulen wrote:
>> On Wed, Oct 30, 2013 at 9:36 PM, Daniel J Walsh<dwalsh@redhat.com>  wrote:
>> [...]
>>>> On 10/30/2013 03:31 PM, Daniel J Walsh wrote:
>>>>> We are trying to shrink out cloud image as small as possible.  One idea
>>>>> was to shrink SELinux Policy footprint by adding compression to it.
>> [...]
>>>> Personally, I'd much rather see work done on shrinking the actual policy
>>>> size in Fedora rather than just compressing it.  Both by reducing the
>>>> overall size of refpolicy through coalescing similar domains/types and by
>>>> making better use of the work that has already been done to support putting
>>>> policy modules into rpms and only installing what actually get used.
>> [...]
>>> Well we have done some work on combining like domains, see antivirus and
>>> spamassassin, but this is a lot of work which no one has time for.
>>>
>>> I would love to see the mailserver and mailclients domains combined.
>>>
>>> If people want to suggest or more importantly submit patches to combine other
>>> domains, I am all for it.
>>>
>>> Problems with shipping policy within rpm still exists. although we (Red Hat)
>>> are at least moving toward layered products shipping their own policy.
>>> openstack-selinux, openshift-selinux, gluster-selinux.  This is more for them
>>> updating quicker then RHEL.
>> In Gentoo, we try to only install the SELinux policies related to the
>> package that is installed. So if a system does not have a web server,
>> no httpd policies are loaded. This works pretty well. My workstation
>> (which is where I do all my SELinux policy development on) has 100
>> policy modules loaded; my servers usually have around 50 to 60 modules
>> loaded. That makes running things like "semodule -B" rather smooth.
>> Not really fast, but one doesn't need to switch to another thing to do
>> while waiting (4 seconds on a VM I'm currently playing with).
>
> A lot of work is being done to improve the start-up time
> of consumer (e.g. phones) devices and "disposable" VMs. We're
> talking about people getting their knickers in a twist over
> security adding 20 milliseconds to the boot process. Your
> 4 second semodule run is not going to fly.

semodule has nothing to do with the boot process. It is used to rebuild 
policies when something changes, e.g., a module is added or removed from 
the policy.




--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/02/2013 12:42 PM, Sven Vermeulen wrote:
> On Wed, Oct 30, 2013 at 9:36 PM, Daniel J Walsh <dwalsh@redhat.com> wrote: 
> [...]
>>> On 10/30/2013 03:31 PM, Daniel J Walsh wrote:
>>>> We are trying to shrink out cloud image as small as possible.  One
>>>> idea was to shrink SELinux Policy footprint by adding compression to
>>>> it.
> [...]
>>> Personally, I'd much rather see work done on shrinking the actual
>>> policy size in Fedora rather than just compressing it.  Both by
>>> reducing the overall size of refpolicy through coalescing similar
>>> domains/types and by making better use of the work that has already
>>> been done to support putting policy modules into rpms and only
>>> installing what actually get used.
> [...]
>> Well we have done some work on combining like domains, see antivirus and 
>> spamassassin, but this is a lot of work which no one has time for.
>> 
>> I would love to see the mailserver and mailclients domains combined.
>> 
>> If people want to suggest or more importantly submit patches to combine
>> other domains, I am all for it.
>> 
>> Problems with shipping policy within rpm still exists. although we (Red
>> Hat) are at least moving toward layered products shipping their own
>> policy. openstack-selinux, openshift-selinux, gluster-selinux.  This is
>> more for them updating quicker then RHEL.
> 
> In Gentoo, we try to only install the SELinux policies related to the 
> package that is installed. So if a system does not have a web server, no
> httpd policies are loaded. This works pretty well. My workstation (which is
> where I do all my SELinux policy development on) has 100 policy modules
> loaded; my servers usually have around 50 to 60 modules loaded. That makes
> running things like "semodule -B" rather smooth. Not really fast, but one
> doesn't need to switch to another thing to do while waiting (4 seconds on a
> VM I'm currently playing with).
> 
> When updates occur only on a module's .te file, it could even be 
> distributed towards the users easily (no need to do a full policy refresh),
> although I usually wait and make a full policy release.
> 
> It probably doesn't take long for Fedora/RedHat to find out which packages
> need which SELinux policy modules. A quick way to find them is to parse the
> RPM file list and check the file contexts of the SELinux policy tree for
> matches.
> 
>> For every apache bug in policy, do we want to wait for an update apache 
>> package, or do we ship lots more packages.
> 
> I'd go for the latter. Put the policies in their own RPMs.
> 
> Wkr, Sven Vermeulen
> 
> -- 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.
> 
And how do  you handle the problem of removing policy when packages get
removed?  What happens to the programs content?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ3sloACgkQrlYvE4MpobN2vQCg5mjJMYrd+AlXec2uTlxIAPuq
bwIAoIOq4f6eU59dwtjO2s+aXZEmbqC8
=zEME
-----END PGP SIGNATURE-----

--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Sven Vermeulen]

On Mon, Nov 4, 2013 at 3:42 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
>> In Gentoo, we try to only install the SELinux policies related to the
>> package that is installed. So if a system does not have a web server, no
>> httpd policies are loaded.
[...]
> And how do  you handle the problem of removing policy when packages get
> removed?  What happens to the programs content?

Good point. We don't handle that - if the package is removed and no
other package exists that has a dependency on the SELinux policy, then
the SELinux policy is also removed. Which invalidates the contexts of
the files. I reckon that users who hit issues with that would relabel
the files, which usually labels them to the "parent" type (such as
var_t for things in /var/www then). But I have not received such
case(s) for review yet.

Wkr,
  Sven Vermeulen

--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/06/2013 10:35 AM, Sven Vermeulen wrote:
> On Mon, Nov 4, 2013 at 3:42 PM, Daniel J Walsh <dwalsh@redhat.com> wrote:
>>> In Gentoo, we try to only install the SELinux policies related to the 
>>> package that is installed. So if a system does not have a web server,
>>> no httpd policies are loaded.
> [...]
>> And how do  you handle the problem of removing policy when packages get 
>> removed?  What happens to the programs content?
> 
> Good point. We don't handle that - if the package is removed and no other
> package exists that has a dependency on the SELinux policy, then the
> SELinux policy is also removed. Which invalidates the contexts of the
> files. I reckon that users who hit issues with that would relabel the
> files, which usually labels them to the "parent" type (such as var_t for
> things in /var/www then). But I have not received such case(s) for review
> yet.
> 
> Wkr, Sven Vermeulen
> 
These are the types of things that I have to worry about with a Huge installed
base.  Just removing the apache.pp would instantaneously would invalidate all
content in /var/www, but also types in any other policy that was installed
that uses apache_content_template.

# grep apache_content_template *.te
apache.te:apache_content_template(httpd_sys)
apache.te:apache_content_template(httpd_user)
apcupsd.te:	apache_content_template(apcupsd_cgi)
awstats.te:apache_content_template(awstats)
bugzilla.te:apache_content_template(bugzilla)
collectd.te:apache_content_template(collectd)
cvs.te:	apache_content_template(cvs)
dirsrv-admin.te:	apache_content_template(dirsrvadmin)
dspam.te:	apache_content_template(dspam)
git.te:apache_content_template(git)
lightsquid.te:	apache_content_template(lightsquid)
man2html.te:	apache_content_template(man2html)
mediawiki.te:	apache_content_template(mediawiki)
mojomojo.te:	apache_content_template(mojomojo)
munin.te:apache_content_template(munin)
mythtv.te:apache_content_template(mythtv)
nagios.te:	apache_content_template(nagios)
nut.te:	apache_content_template(nutups_cgi)
openshift.te:	apache_content_template(openshift)
prelude.te:	apache_content_template(prewikka)
smokeping.te:	apache_content_template(smokeping_cgi)
squid.te:	apache_content_template(squid)
w3c.te:apache_content_template(w3c_validator)
webalizer.te:	apache_content_template(webalizer)
zoneminder.te:	apache_content_template(zoneminder)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJ6YtoACgkQrlYvE4MpobPKGQCgkSWaIi99d8HtcxPV6M0DF/Wb
qwoAmwYmiREd5koNXu1RYI7TJDDnvPsG
=ZeKi
-----END PGP SIGNATURE-----

--
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: Been looking at further shrinkage of the SELinux footprint on Linux.

[Timothée Ravier]

On 31/10/2013 19:52, Daniel J Walsh wrote:
> On 10/31/2013 08:56 AM, Stephen Smalley wrote:
>> I guess the question is what behavior is desired here.  If you remove the
>> type itself, then these days it will get treated as unlabeled (so it 
>> becomes inaccessible to anything that doesn't have permissions to 
>> unlabeled, but that shouldn't be an issue for unconfined users) and if 
>> someone later re-installs the package/policy, then it should get remapped
>> to its original context due to the deferred context mapping support.  Is
>> that sufficient?  If not, then my proposed approach above of pushing all of
>> the file type declarations into a single module (probably the base module)
>> and never removing them would allow the types to always remain valid but
>> they'd still be inaccessible except to domains that are allowed access to
>> file_type (e.g. unconfined) when you remove the modules defining the allow
>> rules.  Is that sufficient?  If not, then your approach of never removing
>> modules will work but seems the least optimal to me.
> 
> Well I like the idea of defining alias for modules when they are not
> installed.  The biggest problem I see is around executables and potentially
> readable content.  If I install a package that labels something as
> foobar_exec_t and leaves the content on uninstall, a confined domain that was
> able to execute foobar_exec_t will now not be able to execute unlabeled_t.
> 
> If we could alias foobar_exec_t to bin_t when foobar.pp is not installed, then
> we get a little closer to the default, and I don;t have restorecon -R -v
> fixing unlabeled_t files.
> 
> similarly  foobar_usr content to -> usr_t, and foobar_etc_t to etc_t
> foobar_var_t -> var_t ...

Hi,

I'm afraid this would cause undesired and unexpected "un-confining" of
programs / content that used to be confined which could lead to
information leaks for example.

Are programs needing access to data from an uninstalled packages
something that does effectively happen ? Requiring a custom policy to
allow such corner cases does not feel excessive here.

Moreover, changing the labels to some other valid ones may confuse the
admin/user more than if files were to be kept with their original labels
(if all the types are kept available at all times) or if the labels are
set to unlabeled_t which is explicitly telling what happened.

Cheers,

Tim

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