[ SEMANAGE ] Stub pserver backend

[ SEMANAGE ] Stub pserver backend

[Ivan Gyurdiev]

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

The purpose of stubs is to reduce size of future patches, and to point 
to the right place to add functionality (if people want to help 
implement it).

Changes: stub the pserver dbase backend.

[-- Attachment #2: libsemanage.stub_pserver_backend.diff --]
[-- Type: text/x-patch, Size: 4860 bytes --]

diff -Naurp --exclude CVS --exclude ChangeLog --exclude VERSION old/libsemanage/src/database_pserver.c new/libsemanage/src/database_pserver.c
--- old/libsemanage/src/database_pserver.c	1969-12-31 19:00:00.000000000 -0500
+++ new/libsemanage/src/database_pserver.c	2005-11-14 16:51:36.000000000 -0500
@@ -0,0 +1,214 @@
+/* Copyright (C) 2005 Red Hat, Inc. */
+
+struct dbase_pserver;
+typedef struct dbase_pserver dbase_t;
+#define DBASE_DEFINED
+
+#include "debug.h"
+#include "handle.h"
+#include "database_pserver.h"
+
+/* PSERVER dbase */ 
+struct dbase_pserver {
+
+	/* Base record table */
+	record_table_t* rtable;
+
+	/* Stub */
+};
+
+static int dbase_pserver_cache(
+	semanage_handle_t* handle,
+	dbase_pserver_t* dbase) {
+
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	return STATUS_ERR;
+}
+
+static void dbase_pserver_drop_cache(
+	dbase_pserver_t* dbase) {
+}	
+
+/* Flush database to pserver */
+static int dbase_pserver_flush(
+	semanage_handle_t* handle,
+	dbase_pserver_t* dbase) {
+
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	return STATUS_ERR;
+}
+
+/* Check if modified */
+static int dbase_pserver_is_modified(
+	dbase_pserver_t* dbase) {
+
+	/* Stub */
+	return 0;
+}
+
+/* Release dbase resources */
+void dbase_pserver_release(
+	dbase_pserver_t* dbase) {
+
+	/* Stub */
+	dbase = NULL;
+}
+
+static int dbase_pserver_exists(
+	semanage_handle_t* handle,
+	dbase_pserver_t* dbase,
+	record_key_t* key,
+	int* response) {
+
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	key = NULL;
+	response = NULL;
+	return STATUS_ERR;
+}
+
+static int dbase_pserver_add(
+	semanage_handle_t* handle,
+	dbase_pserver_t* dbase,
+	record_key_t* key,
+	record_t* data) {
+
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	key = NULL;
+	data = NULL;
+	return STATUS_ERR;
+}
+
+static int dbase_pserver_set(
+	semanage_handle_t* handle,
+	dbase_pserver_t* dbase,
+	record_key_t* key,
+	record_t* data) {
+	
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	key = NULL;
+	data = NULL;
+	return STATUS_ERR;
+}
+
+
+static int dbase_pserver_modify(
+	semanage_handle_t* handle,
+	dbase_pserver_t* dbase,
+	record_key_t* key,
+	record_t* data) {
+
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	key = NULL;
+	data = NULL;
+	return STATUS_ERR;
+}
+
+static int dbase_pserver_count(
+        semanage_handle_t* handle,
+        dbase_pserver_t* dbase,
+        unsigned int* response) {
+
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	response = NULL;
+	return STATUS_ERR;
+}
+
+static int dbase_pserver_query(
+	semanage_handle_t* handle,
+	dbase_pserver_t* dbase,
+	record_key_t* key,
+	record_t** response) {
+
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	key = NULL;
+	response = NULL;
+	return STATUS_ERR;
+}
+
+static int dbase_pserver_iterate(
+	semanage_handle_t* handle,
+	dbase_pserver_t* dbase, 
+	int (*fn) (record_t* record, void* fn_arg),
+	void* arg) {
+
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	fn = NULL;
+	arg = NULL;
+	return STATUS_ERR;
+}
+
+static int dbase_pserver_del(
+	semanage_handle_t* handle,
+	dbase_pserver_t* dbase,
+	record_key_t* key) {
+
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	key = NULL;
+	return STATUS_ERR;
+}
+
+static int dbase_pserver_list(
+	semanage_handle_t* handle,
+	dbase_pserver_t* dbase,
+	record_t*** records,
+	size_t* count) {
+
+	/* Stub */
+	handle = NULL;
+	dbase = NULL;
+	records = NULL;
+	count = NULL;
+	return STATUS_ERR;
+}
+
+static record_table_t* dbase_pserver_get_rtable(
+	dbase_pserver_t* dbase) {
+
+	/* Stub */
+	return NULL;
+}
+
+
+/* PSERVER dbase - method table implementation */
+dbase_table_t SEMANAGE_PSERVER_DTABLE = {
+
+	/* Cache/Transactions */
+	.cache = dbase_pserver_cache,
+	.drop_cache = dbase_pserver_drop_cache,
+	.flush = dbase_pserver_flush,
+	.is_modified = dbase_pserver_is_modified,
+
+	/* Database API */
+	.iterate = dbase_pserver_iterate,
+	.exists = dbase_pserver_exists, 
+	.list = dbase_pserver_list,   
+	.add = dbase_pserver_add,
+	.set = dbase_pserver_set,
+	.del = dbase_pserver_del, 
+	.modify = dbase_pserver_modify, 
+	.query = dbase_pserver_query, 
+	.count = dbase_pserver_count, 
+
+	/* Polymorphism */
+	.get_rtable = dbase_pserver_get_rtable
+};
diff -Naurp --exclude CVS --exclude ChangeLog --exclude VERSION old/libsemanage/src/database_pserver.h new/libsemanage/src/database_pserver.h
--- old/libsemanage/src/database_pserver.h	1969-12-31 19:00:00.000000000 -0500
+++ new/libsemanage/src/database_pserver.h	2005-11-14 16:51:26.000000000 -0500
@@ -0,0 +1,15 @@
+/* Copyright (C) 2005 Red Hat, Inc. */
+
+#ifndef _SEMANAGE_DATABASE_PSERVER_INTERNAL_H_
+#define _SEMANAGE_DATABASE_PSERVER_INTERNAL_H_
+
+#include "database.h"
+#include "handle.h"
+
+struct dbase_pserver;
+typedef struct dbase_pserver dbase_pserver_t;
+
+/* PSERVER - method table implementation */
+extern dbase_table_t SEMANAGE_PSERVER_DTABLE;
+
+#endif

Re: [ SEMANAGE ] Stub pserver backend

[Stephen Smalley]

On Mon, 2005-11-14 at 16:55 -0500, Ivan Gyurdiev wrote:
> The purpose of stubs is to reduce size of future patches, and to point 
> to the right place to add functionality (if people want to help 
> implement it).
> 
> Changes: stub the pserver dbase backend.

I'd prefer to wait until we have a basic working implementation and a
user ready for merging.  Posting stubs or function prototypes to the
list as examples is fine, but I don't see much value in merging them.
It was ok for early development of libsemanage in order to build up
infrastructure and allow early collaboration/feedback, but I'd prefer to
move to merging actual implementations now.  I'd especially like to see
sample users (even just dummy test programs) that allow the code to be
trivially exercised along with the submissions to help put it in
context.

-- 
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: [ SEMANAGE ] Stub pserver backend

[Stephen Smalley]

On Tue, 2005-11-15 at 06:29 -0500, Stephen Smalley wrote:
> On Mon, 2005-11-14 at 16:55 -0500, Ivan Gyurdiev wrote:
> > The purpose of stubs is to reduce size of future patches, and to point 
> > to the right place to add functionality (if people want to help 
> > implement it).
> > 
> > Changes: stub the pserver dbase backend.
> 
> I'd prefer to wait until we have a basic working implementation and a
> user ready for merging.  Posting stubs or function prototypes to the
> list as examples is fine, but I don't see much value in merging them.
> It was ok for early development of libsemanage in order to build up
> infrastructure and allow early collaboration/feedback, but I'd prefer to
> move to merging actual implementations now.  I'd especially like to see
> sample users (even just dummy test programs) that allow the code to be
> trivially exercised along with the submissions to help put it in
> context.

Also, I think we need to think about priorities of tasks; policy server
backend and runtime boolean manipulation via libsemanage seem fairly low
to me right now.  Of greater importance would be:
- Finalizing the refpolicy-based targeted policy package and getting it
into rawhide,
- Solving the default role problem in semanage/sepol,
- Finalizing the genhomedircon rewrite and getting it upstreamed
(depends on prior item),
- Adding options to audit2allow to allow it to generate well-formed
source policy modules (including module statement and all necessary
required statements) so that users can continue using audit2allow on
managed systems for local additions to rules.  Likely separate options
to allow generation of a complete module versus generation of additional
require and allow rules to append to an existing module.
- Creating a utility for managing seusers via libsemanage so that users
don't need to directly edit the sandbox copy and then run semodule -B to
force a rebuild,
- Finishing the ports functionality and exporting those interfaces,
- Creating utilities for managing the other policy components via
libsemanage.

-- 
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: [ SEMANAGE ] Stub pserver backend

[Daniel J Walsh]

Stephen Smalley wrote:
> On Tue, 2005-11-15 at 06:29 -0500, Stephen Smalley wrote:
>   
>> On Mon, 2005-11-14 at 16:55 -0500, Ivan Gyurdiev wrote:
>>     
>>> The purpose of stubs is to reduce size of future patches, and to point 
>>> to the right place to add functionality (if people want to help 
>>> implement it).
>>>
>>> Changes: stub the pserver dbase backend.
>>>       
>> I'd prefer to wait until we have a basic working implementation and a
>> user ready for merging.  Posting stubs or function prototypes to the
>> list as examples is fine, but I don't see much value in merging them.
>> It was ok for early development of libsemanage in order to build up
>> infrastructure and allow early collaboration/feedback, but I'd prefer to
>> move to merging actual implementations now.  I'd especially like to see
>> sample users (even just dummy test programs) that allow the code to be
>> trivially exercised along with the submissions to help put it in
>> context.
>>     
>
> Also, I think we need to think about priorities of tasks; policy server
> backend and runtime boolean manipulation via libsemanage seem fairly low
> to me right now.  Of greater importance would be:
> - Finalizing the refpolicy-based targeted policy package and getting it
> into rawhide,
>   
refpolicy went in last night.   Now we need to get strict/mls working.  
As well as clean up the bugs that
refpolicy will cause.
> - Solving the default role problem in semanage/sepol,
> - Finalizing the genhomedircon rewrite and getting it upstreamed
> (depends on prior item),
> - Adding options to audit2allow to allow it to generate well-formed
> source policy modules (including module statement and all necessary
> required statements) so that users can continue using audit2allow on
> managed systems for local additions to rules.  Likely separate options
> to allow generation of a complete module versus generation of additional
> require and allow rules to append to an existing module.
>   
I have begun working on this as well as porting it to python.
> - Creating a utility for managing seusers via libsemanage so that users
> don't need to directly edit the sandbox copy and then run semodule -B to
> force a rebuild,
>   
Ditto
> - Finishing the ports functionality and exporting those interfaces,
>   
> - Creating utilities for managing the other policy components via
> libsemanage.
>
>   
Giving me the tools in libsemanage to build the manipulation of ports, 
seusers and potentially
user modules (local.pp) from python.





-- 



--
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: [ SEMANAGE ] Stub pserver backend

[Stephen Smalley]

On Tue, 2005-11-15 at 06:58 -0500, Stephen Smalley wrote:
> Also, I think we need to think about priorities of tasks; policy server
> backend and runtime boolean manipulation via libsemanage seem fairly low
> to me right now.  Of greater importance would be:
> - Finalizing the refpolicy-based targeted policy package and getting it
> into rawhide,

Ok, I see that the new selinux-policy has appeared in rawhide.

> - Solving the default role problem in semanage/sepol,
> - Finalizing the genhomedircon rewrite and getting it upstreamed
> (depends on prior item),
> - Adding options to audit2allow to allow it to generate well-formed
> source policy modules (including module statement and all necessary
> required statements) so that users can continue using audit2allow on
> managed systems for local additions to rules.  Likely separate options
> to allow generation of a complete module versus generation of additional
> require and allow rules to append to an existing module.
> - Creating a utility for managing seusers via libsemanage so that users
> don't need to directly edit the sandbox copy and then run semodule -B to
> force a rebuild,
> - Finishing the ports functionality and exporting those interfaces,
> - Creating utilities for managing the other policy components via
> libsemanage.

-- 
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: [ SEMANAGE ] Stub pserver backend

[Stephen Smalley]

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

On Tue, 2005-11-15 at 08:38 -0500, Daniel J Walsh wrote:
> refpolicy went in last night.   Now we need to get strict/mls working.  
> As well as clean up the bugs that
> refpolicy will cause.

Ok, I'm presently updated a rawhide targeted system, and have attached
three files with relevant output from yum, dmesg, and avc audit.  The
yum output shows what booleans were lost in translation and what files
were relabeled by restorecon.  The dmesg output shows what security
contexts were no longer valid in the new policy, which then triggers
subsequent inode_doinit errors upon the relabeling.  The avc audit
output shows the denials that would have occurred during the restorecon
if I had done this in enforcing mode.  I also noticed that policy is
reloaded twice; second load occurs during cleanup phase for some reason.

-- 
Stephen Smalley
National Security Agency

[-- Attachment #2: yum.out --]
[-- Type: text/plain, Size: 13867 bytes --]

  Updating  : selinux-policy-targeted      ####################### [39/76]
Attempting to install base module '/usr/share/selinux/targeted/base.pp':
Ok: return value of 0.
Committing changes:
libsepol.sepol_genbools_array: boolean allow_postgresql_use_pam no longer in policy
libsepol.sepol_genbools_array: boolean allow_write_xshm no longer in policy
libsepol.sepol_genbools_array: boolean getty_disable_trans no longer in policy
libsepol.sepol_genbools_array: boolean pppd_for_user no longer in policy
libsepol.sepol_genbools_array: boolean system_dbusd_disable_trans no longer in policy
/var/lib is already defined in /etc/selinux/targeted/contexts/files/file_contexts,
/usr/sbin/genhomedircon will not create a new context.
Ok: transaction number 0.
/sbin/restorecon reset /usr/X11R6/lib/X11/xkb/xkbcomp context system_u:object_r:lib_t->system_u:object_r:bin_t
/sbin/restorecon reset /usr/share/texmf/web2c/pdfxmltex.fmt context root:object_r:tmp_t->system_u:object_r:usr_t
/sbin/restorecon reset /usr/share/texmf/web2c/xmltex.log context root:object_r:tmp_t->system_u:object_r:usr_t
/sbin/restorecon reset /usr/share/texmf/web2c/xmltex.fmt context root:object_r:tmp_t->system_u:object_r:usr_t
/sbin/restorecon reset /usr/share/texmf/web2c/pdfxmltex.log context root:object_r:tmp_t->system_u:object_r:usr_t
/sbin/restorecon reset /usr/share/texmf/web2c/jadetex.log context root:object_r:tmp_t->system_u:object_r:usr_t
/sbin/restorecon reset /usr/share/texmf/web2c/pdfjadetex.log context root:object_r:tmp_t->system_u:object_r:usr_t
/sbin/restorecon reset /usr/share/texmf/web2c/pdfjadetex.fmt context root:object_r:tmp_t->system_u:object_r:usr_t
/sbin/restorecon reset /usr/share/texmf/web2c/jadetex.fmt context root:object_r:tmp_t->system_u:object_r:usr_t
/sbin/restorecon reset /usr/share/cracklib context system_u:object_r:usr_t->system_u:object_r:crack_db_t
/sbin/restorecon reset /usr/share/cracklib/pw_dict.pwd context system_u:object_r:usr_t->system_u:object_r:crack_db_t
/sbin/restorecon reset /usr/share/cracklib/pw_dict.hwm context system_u:object_r:usr_t->system_u:object_r:crack_db_t
/sbin/restorecon reset /usr/share/cracklib/cracklib.magic context system_u:object_r:usr_t->system_u:object_r:crack_db_t
/sbin/restorecon reset /usr/share/cracklib/pw_dict.pwi context system_u:object_r:usr_t->system_u:object_r:crack_db_t
/sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin context system_u:object_r:bin_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/rmiregistry context system_u:object_r:bin_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javac context system_u:object_r:bin_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/rebuild-gcj-db context system_u:object_r:bin_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/rmic context system_u:object_r:bin_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/aot-compile-rpm context system_u:object_r:bin_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/jar context system_u:object_r:bin_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah context system_u:object_r:bin_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javadoc context system_u:object_r:bin_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/java context system_u:object_r:bin_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/qt-3.3/etc/settings context system_u:object_r:unlabeled_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/qt-3.3/etc/settings/kstylerc context system_u:object_r:unlabeled_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/lib/qt-3.3/etc/settings/qtrc context system_u:object_r:unlabeled_t->system_u:object_r:lib_t
/sbin/restorecon reset /usr/bin/at context system_u:object_r:bin_t->system_u:object_r:crontab_exec_t
/sbin/restorecon reset /usr/bin/smbmnt context system_u:object_r:bin_t->system_u:object_r:smbmount_exec_t
/sbin/restorecon reset /usr/bin/gpasswd context system_u:object_r:bin_t->system_u:object_r:groupadd_exec_t
/sbin/restorecon reset /usr/bin/crontab context system_u:object_r:bin_t->system_u:object_r:crontab_exec_t
/sbin/restorecon reset /usr/bin/nmap context system_u:object_r:bin_t->system_u:object_r:traceroute_exec_t
/sbin/restorecon reset /usr/bin/smbmount context system_u:object_r:bin_t->system_u:object_r:smbmount_exec_t
/sbin/restorecon reset /usr/bin/spamassassin context system_u:object_r:bin_t->system_u:object_r:spamassassin_exec_t
/sbin/restorecon reset /usr/sbin/cracklib-format context system_u:object_r:sbin_t->system_u:object_r:crack_exec_t
/sbin/restorecon reset /usr/sbin/logrotate context system_u:object_r:sbin_t->system_u:object_r:logrotate_exec_t
/sbin/restorecon reset /usr/sbin/cracklib-check context system_u:object_r:sbin_t->system_u:object_r:crack_exec_t
/sbin/restorecon reset /usr/sbin/groupdel context system_u:object_r:sbin_t->system_u:object_r:groupadd_exec_t
/sbin/restorecon reset /usr/sbin/cracklib-packer context system_u:object_r:sbin_t->system_u:object_r:crack_exec_t
/sbin/restorecon reset /usr/sbin/tmpwatch context system_u:object_r:sbin_t->system_u:object_r:tmpreaper_exec_t
/sbin/restorecon reset /usr/sbin/utempter context system_u:object_r:sbin_t->system_u:object_r:utempter_exec_t
/sbin/restorecon reset /usr/sbin/groupadd context system_u:object_r:sbin_t->system_u:object_r:groupadd_exec_t
/sbin/restorecon reset /usr/sbin/userdel context system_u:object_r:sbin_t->system_u:object_r:useradd_exec_t
/sbin/restorecon reset /usr/sbin/groupmod context system_u:object_r:sbin_t->system_u:object_r:groupadd_exec_t
/sbin/restorecon reset /usr/sbin/usermod context system_u:object_r:sbin_t->system_u:object_r:useradd_exec_t
/sbin/restorecon reset /usr/sbin/gdm-binary context system_u:object_r:xdm_exec_t->system_u:object_r:sbin_t
/sbin/restorecon reset /usr/sbin/tcpd context system_u:object_r:sbin_t->system_u:object_r:tcpd_exec_t
/sbin/restorecon reset /usr/sbin/cracklib-unpacker context system_u:object_r:sbin_t->system_u:object_r:crack_exec_t
/sbin/restorecon reset /usr/sbin/useradd context system_u:object_r:sbin_t->system_u:object_r:useradd_exec_t
/sbin/restorecon reset /boot/System.map context system_u:object_r:system_map_t->system_u:object_r:boot_t
/sbin/restorecon reset /lib/security/pam_krb5/pam_krb5_storetmp context system_u:object_r:lib_t->system_u:object_r:pam_exec_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.seriomap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.inputmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.ccwmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.isapnpmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.usbmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.dep context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.alias context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.pcimap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.ieee1394map context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.symbols context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.seriomap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.inputmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.ccwmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.isapnpmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.usbmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.dep context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.alias context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.pcimap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.ieee1394map context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.symbols context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
/sbin/restorecon reset /var/lock/subsys/sm-client context system_u:object_r:unlabeled_t->system_u:object_r:var_lock_t
/sbin/restorecon reset /var/lock/subsys/sendmail context system_u:object_r:unlabeled_t->system_u:object_r:var_lock_t
/sbin/restorecon reset /var/gdm context system_u:object_r:unlabeled_t->system_u:object_r:var_t
/sbin/restorecon reset /var/gdm/.cookie context system_u:object_r:unlabeled_t->system_u:object_r:var_t
/sbin/restorecon reset /var/gdm/:0.Xauth context system_u:object_r:unlabeled_t->system_u:object_r:var_t
/sbin/restorecon reset /var/gdm/.gdmfifo context system_u:object_r:unlabeled_t->system_u:object_r:var_t
/sbin/restorecon reset /var/lib/logrotate.status context system_u:object_r:var_lib_t->system_u:object_r:logrotate_var_lib_t
/sbin/restorecon reset /var/log/rpmpkgs context system_u:object_r:var_log_t->system_u:object_r:rpm_log_t
/sbin/restorecon reset /var/log/gdm context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
/sbin/restorecon reset /var/log/gdm/:0.log.1 context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
/sbin/restorecon reset /var/log/gdm/:0.log context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
/sbin/restorecon reset /var/log/gdm/:0.log.3 context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
/sbin/restorecon reset /var/log/gdm/:0.log.2 context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
/sbin/restorecon reset /var/log/gdm/:0.log.4 context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
/sbin/restorecon reset /var/log/yum.log context system_u:object_r:var_log_t->system_u:object_r:rpm_log_t
/sbin/restorecon reset /var/log/yum.log.1 context system_u:object_r:rpm_log_t->system_u:object_r:var_log_t
/sbin/restorecon reset /var/run/sudo context system_u:object_r:var_run_t->system_u:object_r:pam_var_run_t
/sbin/restorecon reset /var/run/sudo/sds context system_u:object_r:var_run_t->system_u:object_r:pam_var_run_t
/sbin/restorecon reset /var/run/sudo/root context system_u:object_r:var_run_t->system_u:object_r:pam_var_run_t
/sbin/restorecon reset /var/run/sudo/_pam_timestamp_key context system_u:object_r:var_run_t->system_u:object_r:pam_var_run_t
/sbin/restorecon reset /var/run/console context system_u:object_r:var_run_t->system_u:object_r:pam_var_console_t
/sbin/restorecon reset /bin/tracepath context system_u:object_r:bin_t->system_u:object_r:traceroute_exec_t
/sbin/restorecon reset /bin/mount context system_u:object_r:bin_t->system_u:object_r:mount_exec_t
/sbin/restorecon reset /bin/traceroute context system_u:object_r:bin_t->system_u:object_r:traceroute_exec_t
/sbin/restorecon reset /bin/umount context system_u:object_r:bin_t->system_u:object_r:mount_exec_t
/sbin/restorecon reset /bin/tracepath6 context system_u:object_r:bin_t->system_u:object_r:traceroute_exec_t
/sbin/restorecon reset /sbin/dmsetup.static context system_u:object_r:unlabeled_t->system_u:object_r:sbin_t
/sbin/restorecon reset /sbin/mkinitrd context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
/sbin/restorecon reset /sbin/grubby context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
/sbin/restorecon reset /sbin/sulogin context system_u:object_r:sbin_t->system_u:object_r:sulogin_exec_t
/sbin/restorecon reset /sbin/cryptsetup context system_u:object_r:unlabeled_t->system_u:object_r:sbin_t
/sbin/restorecon reset /sbin/grub-terminfo context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
/sbin/restorecon reset /sbin/grub-install context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
/sbin/restorecon reset /sbin/grub-md5-crypt context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
/sbin/restorecon reset /sbin/grub context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
/sbin/restorecon reset /sbin/pam_timestamp_check context system_u:object_r:sbin_t->system_u:object_r:pam_exec_t
/sbin/restorecon reset /sbin/pam_console_apply context system_u:object_r:sbin_t->system_u:object_r:pam_console_exec_t
/sbin/restorecon reset /etc/ld.so.cache context root:object_r:etc_t->system_u:object_r:ld_so_cache_t
/sbin/restorecon reset /etc/rc.d/init.d/sendmail context system_u:object_r:unlabeled_t->system_u:object_r:initrc_exec_t
/sbin/restorecon reset /etc/X11/xdm/Xsession context system_u:object_r:unlabeled_t->system_u:object_r:etc_t




[-- Attachment #3: dmesg.out --]
[-- Type: text/plain, Size: 2650 bytes --]

security:  3 users, 6 roles, 1044 types, 116 bools, 1 sens, 256 cats
security:  55 classes, 31351 rules
security:  invalidating context system_u:system_r:sendmail_launch_t:s0
security:  invalidating context system_u:object_r:sendmail_launch_exec_t:s0
security:  invalidating context system_u:object_r:sendmail_launch_lock_t:s0
security:  invalidating context user_u:system_r:ypxfr_t:s0
security:  invalidating context system_u:object_r:xserver_log_t:s0
security:  invalidating context system_u:object_r:xdm_xserver_tmp_t:s0
security:  invalidating context system_u:object_r:xsession_exec_t:s0
security:  invalidating context system_u:object_r:xdm_rw_etc_t:s0
security:  invalidating context system_u:object_r:xdm_var_run_t:s0
security:  invalidating context system_u:object_r:xdm_var_lib_t:s0
security:  invalidating context user_u:sysadm_r:ypxfr_t:s0
security:  invalidating context system_u:system_r:procmail_t:s0
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xdm_var_run_t:s0) returned 22 for dev=dm-0 ino=2494768
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xdm_var_run_t:s0) returned 22 for dev=dm-0 ino=2494119
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:sendmail_launch_lock_t:s0) returned 22 for dev=dm-0 ino=5626272
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:sendmail_launch_lock_t:s0) returned 22 for dev=dm-0 ino=5626270
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657925
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657949
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657950
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657928
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657952
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657931
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:lvm_exec_t:s0) returned 22 for dev=dm-0 ino=7685553
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:lvm_exec_t:s0) returned 22 for dev=dm-0 ino=7685538
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:sendmail_launch_exec_t:s0) returned 22 for dev=dm-0 ino=5102806
inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xsession_exec_t) returned 22 for dev=dm-0 ino=5103774
security:  3 users, 6 roles, 1044 types, 116 bools, 1 sens, 256 cats
security:  55 classes, 31351 rules

[-- Attachment #4: audit.out --]
[-- Type: text/plain, Size: 721 bytes --]

type=AVC msg=audit(1132062016.379:234): avc:  denied  { getattr } for  pid=25793 comm="find" name="gdm-binary" dev=dm-0 ino=2035791 scontext=root:system_r:rpm_script_t:s0-s0:c0.c255 tcontext=system_u:object_r:xdm_exec_t:s0 tclass=file
type=AVC msg=audit(1132062016.831:235): avc:  denied  { getattr } for  pid=25789 comm="restorecon" name="gdm-binary" dev=dm-0 ino=2035791 scontext=root:system_r:restorecon_t:s0-s0:c0.c255 tcontext=system_u:object_r:xdm_exec_t:s0 tclass=file
type=AVC msg=audit(1132062016.831:236): avc:  denied  { relabelfrom } for  pid=25789 comm="restorecon" name="gdm-binary" dev=dm-0 ino=2035791 scontext=root:system_r:restorecon_t:s0-s0:c0.c255 tcontext=system_u:object_r:xdm_exec_t:s0 tclass=file

Policy mods in last nights refpolicy

[Daniel J Walsh]

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



-- 



[-- Attachment #2: policy-20051114.patch --]
[-- Type: text/x-patch, Size: 11458 bytes --]

diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/booleans.conf serefpolicy-2.0.1/policy/booleans.conf
--- nsaserefpolicy/policy/booleans.conf	1969-12-31 19:00:00.000000000 -0500
+++ serefpolicy-2.0.1/policy/booleans.conf	2005-11-15 09:19:21.000000000 -0500
@@ -0,0 +1,208 @@
+# Allow making anonymous memory executable, e.g.for runtime-code generation or executable stack.
+# 
+allow_execmem = true
+
+# Allow making a modified private filemapping executable (text relocation).
+# 
+allow_execmod = true
+
+# Allow making the stack executable via mprotect.Also requires allow_execmem.
+# 
+allow_execstack = true
+
+# Allow ftp servers to modify public filesused for public file transfer services.
+# 
+allow_ftpd_anon_write = false
+
+# Allow gssd to read temp directory.
+# 
+allow_gssd_read_tmp = true
+
+# Allow Apache to modify public filesused for public file transfer services.
+# 
+allow_httpd_anon_write = false
+
+# Allow system to run with kerberos
+# 
+allow_kerberos = true
+
+# Allow rsync to modify public filesused for public file transfer services.
+# 
+allow_rsync_anon_write = false
+
+# Allow sasl to read shadow
+# 
+allow_saslauthd_read_shadow = false
+
+# Allow samba to modify public filesused for public file transfer services.
+# 
+allow_smbd_anon_write = false
+
+# Allow sysadm to ptrace all processes
+# 
+allow_ptrace = false
+
+# Allow system to run with NIS
+# 
+allow_ypbind = false
+
+# Enable extra rules in the cron domainto support fcron.
+# 
+fcron_crond = false
+
+# Allow ftp to read and write files in the user home directories
+# 
+ftp_home_dir = false
+
+# Allow ftpd to run directly without inetd
+# 
+ftpd_is_daemon = true
+
+# Allow httpd to use built in scripting (usually php)
+# 
+httpd_builtin_scripting = true
+
+# Allow http daemon to tcp connect
+# 
+httpd_can_network_connect = false
+
+# Allow httpd cgi support
+# 
+httpd_enable_cgi = true
+
+# Allow httpd to act as a FTP server bylistening on the ftp port.
+# 
+httpd_enable_ftp_server = false
+
+# Allow httpd to read home directories
+# 
+httpd_enable_homedirs = true
+
+# Run SSI execs in system CGI script domain.
+# 
+httpd_ssi_exec = true
+
+# Allow http daemon to communicate with the TTY
+# 
+httpd_tty_comm = false
+
+# Run CGI in the main httpd domain
+# 
+httpd_unified = true
+
+# Allow BIND to write the master zone files.Generally this is used for dynamic DNS.
+# 
+named_write_master_zones = false
+
+# Allow nfs to be exported read/write.
+# 
+nfs_export_all_rw = true
+
+# Allow nfs to be exported read only
+# 
+nfs_export_all_ro = true
+
+# Allow pppd to load kernel modules for certain modems
+# 
+pppd_can_insmod = false
+
+# Allow reading of default_t files.
+# 
+read_default_t = true
+
+# Allow ssh to run from inetd instead of as a daemon.
+# 
+run_ssh_inetd = false
+
+# Allow samba to export user home directories.
+# 
+samba_enable_home_dirs = false
+
+# Allow squid to connect to all ports, not justHTTP, FTP, and Gopher ports.
+# 
+squid_connect_any = false
+
+# Allow ssh logins as sysadm_r:sysadm_t
+# 
+ssh_sysadm_login = false
+
+# Configure stunnel to be a standalone daemon orinetd service.
+# 
+stunnel_is_daemon = false
+
+# Support NFS home directories
+# 
+use_nfs_home_dirs = false
+
+# Support SAMBA home directories
+# 
+use_samba_home_dirs = false
+
+# Control users use of ping and traceroute
+# 
+user_ping = true
+
+# Allow gpg executable stack
+# 
+allow_gpg_execstack = false
+
+# allow host key based authentication
+# 
+allow_ssh_keysign = false
+
+# Allow users to connect to mysql
+# 
+allow_user_mysql_connect = false
+
+# Allow system cron jobs to relabel filesystemfor restoring file contexts.
+# 
+cron_can_relabel = false
+
+# Allow pppd to be run for a regular user
+# 
+pppd_for_user = false
+
+# Allow applications to read untrusted contentIf this is disallowed, Internet content hasto be manually relabeled for read access to be granted
+# 
+read_untrusted_content = false
+
+# Allow user spamassassin clients to use the network.
+# 
+spamassassin_can_network = false
+
+# Allow staff_r users to search the sysadm homedir and read files (such as ~/.bashrc)
+# 
+staff_read_sysadm_file = false
+
+# Allow regular users direct mouse access
+# 
+user_direct_mouse = false
+
+# Allow users to read system messages.
+# 
+user_dmesg = false
+
+# Allow users to control network interfaces(also needs USERCTL=true)
+# 
+user_net_control = false
+
+# Allow user to r/w files on filesystemsthat do not have extended attributes (FAT, CDROM, FLOPPY)
+# 
+user_rw_noexattrfile = false
+
+# Allow users to rw usb devices
+# 
+user_rw_usb = false
+
+# Allow users to run TCP servers (bind to ports and accept connection fromthe same domain and outside users)  disabling this forces FTP passive modeand may change other protocols.
+# 
+user_tcp_server = false
+
+# Allow w to display everyone
+# 
+user_ttyfile_stat = false
+
+# Allow applications to write untrusted contentIf this is disallowed, no Internet contentwill be stored.
+# 
+write_untrusted_content = false
+
diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/apps/gpg.fc serefpolicy-2.0.1/policy/modules/apps/gpg.fc
--- nsaserefpolicy/policy/modules/apps/gpg.fc	2005-11-14 18:24:05.000000000 -0500
+++ serefpolicy-2.0.1/policy/modules/apps/gpg.fc	2005-11-15 09:19:21.000000000 -0500
@@ -8,5 +8,5 @@
 /usr/lib/gnupg/gpgkeys.* --	gen_context(system_u:object_r:gpg_helper_exec_t,s0)
 
 ifdef(`targeted_policy',`',`
-HOME_DIR/\.gnupg(/.+)?		gen_context(system_u:object_r:ROLE_gpg_secret_t,s0)
+HOME_DIR/\.gnupg(/.+)?		gen_context(system_u:object_r:user_gpg_secret_t,s0)
 ')
diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/services/ldap.te serefpolicy-2.0.1/policy/modules/services/ldap.te
--- nsaserefpolicy/policy/modules/services/ldap.te	2005-11-14 18:24:08.000000000 -0500
+++ serefpolicy-2.0.1/policy/modules/services/ldap.te	2005-11-15 09:19:21.000000000 -0500
@@ -25,6 +25,13 @@
 type slapd_var_run_t;
 files_pid_file(slapd_var_run_t)
 
+type slapd_lock_t;
+files_lock_file(slapd_lock_t)
+
+type slapd_cert_t;
+files_type(slapd_cert_t)
+
+
 ########################################
 #
 # Local policy
@@ -61,6 +68,13 @@
 allow slapd_t slapd_var_run_t:dir rw_dir_perms;
 files_create_pid(slapd_t,slapd_var_run_t)
 
+allow slapd_t slapd_cert_t:dir { getattr read search };
+allow slapd_t slapd_cert_t:file { read getattr ioctl lock };
+allow slapd_t slapd_cert_t:lnk_file { getattr read };
+
+allow slapd_t slapd_lock_t:file create_file_perms;
+files_create_lock(slapd_t,slapd_lock_t)
+
 kernel_read_system_state(slapd_t)
 kernel_read_kernel_sysctl(slapd_t)
 kernel_tcp_recvfrom(slapd_t)
diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/services/spamassassin.fc serefpolicy-2.0.1/policy/modules/services/spamassassin.fc
--- nsaserefpolicy/policy/modules/services/spamassassin.fc	2005-11-14 18:24:07.000000000 -0500
+++ serefpolicy-2.0.1/policy/modules/services/spamassassin.fc	2005-11-15 09:19:21.000000000 -0500
@@ -7,5 +7,5 @@
 /usr/bin/spamassassin	--	gen_context(system_u:object_r:spamassassin_exec_t,s0)
 
 ifdef(`targeted_policy',`',`
-HOME_DIR/\.spamassassin(/.*)?	gen_context(system_u:object_r:ROLE_spamassassin_home_t,s0)
+HOME_DIR/\.spamassassin(/.*)?	gen_context(system_u:object_r:user_spamassassin_home_t,s0)
 ')
diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/services/ssh.fc serefpolicy-2.0.1/policy/modules/services/ssh.fc
--- nsaserefpolicy/policy/modules/services/ssh.fc	2005-11-14 18:24:08.000000000 -0500
+++ serefpolicy-2.0.1/policy/modules/services/ssh.fc	2005-11-15 09:19:21.000000000 -0500
@@ -15,5 +15,5 @@
 ifdef(`targeted_policy', `', `
 /usr/bin/ssh-agent		--	gen_context(system_u:object_r:ssh_agent_exec_t,s0)
 
-HOME_DIR/\.ssh(/.*)?			gen_context(system_u:object_r:ROLE_home_ssh_t,s0)
+HOME_DIR/\.ssh(/.*)?			gen_context(system_u:object_r:user_home_ssh_t,s0)
 ')
diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/system/authlogin.if serefpolicy-2.0.1/policy/modules/system/authlogin.if
--- nsaserefpolicy/policy/modules/system/authlogin.if	2005-11-14 18:24:06.000000000 -0500
+++ serefpolicy-2.0.1/policy/modules/system/authlogin.if	2005-11-15 09:19:21.000000000 -0500
@@ -931,6 +931,9 @@
 	optional_policy(`samba.te',`
 		samba_connect_winbind($1)
 	')
+	allow $1 var_auth_t:dir r_dir_perms;
+	allow $1 var_auth_t:file create_file_perms;
+
 ')
 
 ########################################
diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/system/files.fc serefpolicy-2.0.1/policy/modules/system/files.fc
--- nsaserefpolicy/policy/modules/system/files.fc	2005-11-14 18:24:06.000000000 -0500
+++ serefpolicy-2.0.1/policy/modules/system/files.fc	2005-11-15 09:19:21.000000000 -0500
@@ -214,3 +214,4 @@
 /var/tmp/lost\+found	-d	gen_context(system_u:object_r:lost_found_t,s0)
 /var/tmp/lost\+found/.*		<<none>>
 /var/tmp/vi\.recover	-d	gen_context(system_u:object_r:tmp_t,s0)
+/var/lib/abl(/.*)?		gen_context(system_u:object_r:var_auth_t,s0)
diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/system/files.te serefpolicy-2.0.1/policy/modules/system/files.te
--- nsaserefpolicy/policy/modules/system/files.te	2005-11-14 18:24:06.000000000 -0500
+++ serefpolicy-2.0.1/policy/modules/system/files.te	2005-11-15 09:19:21.000000000 -0500
@@ -167,3 +167,12 @@
 #
 type var_spool_t;
 files_tmp_file(var_spool_t)
+
+#
+# var_auth_t is the type of /var/lib/auth, usually
+# used for auth data in pam_able
+#
+type var_auth_t, file_type;
+fs_associate(var_auth_t)
+fs_associate_noxattr(var_auth_t)
+
diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/system/logging.te serefpolicy-2.0.1/policy/modules/system/logging.te
--- nsaserefpolicy/policy/modules/system/logging.te	2005-11-14 18:24:06.000000000 -0500
+++ serefpolicy-2.0.1/policy/modules/system/logging.te	2005-11-15 09:19:21.000000000 -0500
@@ -108,6 +108,7 @@
 allow auditd_t self:file { getattr read write };
 allow auditd_t self:unix_dgram_socket create_socket_perms;
 allow auditd_t self:netlink_audit_socket { create_netlink_socket_perms nlmsg_relay nlmsg_readpriv };
+allow auditd_t self:fifo_file rw_file_perms;
 
 allow auditd_t auditd_etc_t:file r_file_perms;
 
diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/system/userdomain.fc serefpolicy-2.0.1/policy/modules/system/userdomain.fc
--- nsaserefpolicy/policy/modules/system/userdomain.fc	2005-11-15 09:13:40.000000000 -0500
+++ serefpolicy-2.0.1/policy/modules/system/userdomain.fc	2005-11-15 09:19:21.000000000 -0500
@@ -4,6 +4,6 @@
 HOME_DIR		-d	gen_context(system_u:object_r:user_home_dir_t,s0)
 HOME_DIR/.+			gen_context(system_u:object_r:user_home_t,s0)
 ',`
-HOME_DIR		-d	gen_context(system_u:object_r:ROLE_home_dir_t,s0)
-HOME_DIR/.+			gen_context(system_u:object_r:ROLE_home_t,s0)
+HOME_DIR		-d	gen_context(system_u:object_r:user_home_dir_t,s0)
+HOME_DIR/.+			gen_context(system_u:object_r:user_home_t,s0)
 ')
diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules.conf serefpolicy-2.0.1/policy/modules.conf
--- nsaserefpolicy/policy/modules.conf	2005-11-15 09:13:36.000000000 -0500
+++ serefpolicy-2.0.1/policy/modules.conf	2005-11-15 09:19:21.000000000 -0500
@@ -189,7 +189,7 @@
 #
 # Virtual Private Networking client
 # 
-vpn = base
+vpn = off
 
 # Layer: admin
 # Module: consoletype
@@ -632,7 +632,7 @@
 #
 # X windows login display manager
 # 
-xdm = base
+xdm = off
 
 # Layer: services
 # Module: networkmanager

Re: [ SEMANAGE ] Stub pserver backend

[Daniel J Walsh]

Stephen Smalley wrote:
> On Tue, 2005-11-15 at 08:38 -0500, Daniel J Walsh wrote:
>   
>> refpolicy went in last night.   Now we need to get strict/mls working.  
>> As well as clean up the bugs that
>> refpolicy will cause.
>>     
>
> Ok, I'm presently updated a rawhide targeted system, and have attached
> three files with relevant output from yum, dmesg, and avc audit.  The
> yum output shows what booleans were lost in translation and what files
> were relabeled by restorecon.  The dmesg output shows what security
> contexts were no longer valid in the new policy, which then triggers
> subsequent inode_doinit errors upon the relabeling.  The avc audit
> output shows the denials that would have occurred during the restorecon
> if I had done this in enforcing mode.  I also noticed that policy is
> reloaded twice; second load occurs during cleanup phase for some reason.
>   

Ok I should not have turned off xdm, there is a bug in the spec for jvm.

sendmail_launch was a last minute change to targeted from Russell that 
has not been ported into refpolicy yet.

ypxfr is a partial policy to implement ypxfr, but is not used yet.

We need to get procmail ported to reference policy

I turned off lvm, because it brought a lot of other pieces in that I did 
not want to deal with.   We can revisit this decision.

reference policy has added some confinement of some user space tools, 
which we will have to monitor for breakage.

Dan
>   
> ------------------------------------------------------------------------
>
>   Updating  : selinux-policy-targeted      ####################### [39/76]
> Attempting to install base module '/usr/share/selinux/targeted/base.pp':
> Ok: return value of 0.
> Committing changes:
> libsepol.sepol_genbools_array: boolean allow_postgresql_use_pam no longer in policy
> libsepol.sepol_genbools_array: boolean allow_write_xshm no longer in policy
> libsepol.sepol_genbools_array: boolean getty_disable_trans no longer in policy
> libsepol.sepol_genbools_array: boolean pppd_for_user no longer in policy
> libsepol.sepol_genbools_array: boolean system_dbusd_disable_trans no longer in policy
> /var/lib is already defined in /etc/selinux/targeted/contexts/files/file_contexts,
> /usr/sbin/genhomedircon will not create a new context.
> Ok: transaction number 0.
> /sbin/restorecon reset /usr/X11R6/lib/X11/xkb/xkbcomp context system_u:object_r:lib_t->system_u:object_r:bin_t
> /sbin/restorecon reset /usr/share/texmf/web2c/pdfxmltex.fmt context root:object_r:tmp_t->system_u:object_r:usr_t
> /sbin/restorecon reset /usr/share/texmf/web2c/xmltex.log context root:object_r:tmp_t->system_u:object_r:usr_t
> /sbin/restorecon reset /usr/share/texmf/web2c/xmltex.fmt context root:object_r:tmp_t->system_u:object_r:usr_t
> /sbin/restorecon reset /usr/share/texmf/web2c/pdfxmltex.log context root:object_r:tmp_t->system_u:object_r:usr_t
> /sbin/restorecon reset /usr/share/texmf/web2c/jadetex.log context root:object_r:tmp_t->system_u:object_r:usr_t
> /sbin/restorecon reset /usr/share/texmf/web2c/pdfjadetex.log context root:object_r:tmp_t->system_u:object_r:usr_t
> /sbin/restorecon reset /usr/share/texmf/web2c/pdfjadetex.fmt context root:object_r:tmp_t->system_u:object_r:usr_t
> /sbin/restorecon reset /usr/share/texmf/web2c/jadetex.fmt context root:object_r:tmp_t->system_u:object_r:usr_t
> /sbin/restorecon reset /usr/share/cracklib context system_u:object_r:usr_t->system_u:object_r:crack_db_t
> /sbin/restorecon reset /usr/share/cracklib/pw_dict.pwd context system_u:object_r:usr_t->system_u:object_r:crack_db_t
> /sbin/restorecon reset /usr/share/cracklib/pw_dict.hwm context system_u:object_r:usr_t->system_u:object_r:crack_db_t
> /sbin/restorecon reset /usr/share/cracklib/cracklib.magic context system_u:object_r:usr_t->system_u:object_r:crack_db_t
> /sbin/restorecon reset /usr/share/cracklib/pw_dict.pwi context system_u:object_r:usr_t->system_u:object_r:crack_db_t
> /sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin context system_u:object_r:bin_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/rmiregistry context system_u:object_r:bin_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javac context system_u:object_r:bin_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/rebuild-gcj-db context system_u:object_r:bin_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/rmic context system_u:object_r:bin_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/aot-compile-rpm context system_u:object_r:bin_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/jar context system_u:object_r:bin_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javah context system_u:object_r:bin_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/javadoc context system_u:object_r:bin_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/bin/java context system_u:object_r:bin_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/qt-3.3/etc/settings context system_u:object_r:unlabeled_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/qt-3.3/etc/settings/kstylerc context system_u:object_r:unlabeled_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/lib/qt-3.3/etc/settings/qtrc context system_u:object_r:unlabeled_t->system_u:object_r:lib_t
> /sbin/restorecon reset /usr/bin/at context system_u:object_r:bin_t->system_u:object_r:crontab_exec_t
> /sbin/restorecon reset /usr/bin/smbmnt context system_u:object_r:bin_t->system_u:object_r:smbmount_exec_t
> /sbin/restorecon reset /usr/bin/gpasswd context system_u:object_r:bin_t->system_u:object_r:groupadd_exec_t
> /sbin/restorecon reset /usr/bin/crontab context system_u:object_r:bin_t->system_u:object_r:crontab_exec_t
> /sbin/restorecon reset /usr/bin/nmap context system_u:object_r:bin_t->system_u:object_r:traceroute_exec_t
> /sbin/restorecon reset /usr/bin/smbmount context system_u:object_r:bin_t->system_u:object_r:smbmount_exec_t
> /sbin/restorecon reset /usr/bin/spamassassin context system_u:object_r:bin_t->system_u:object_r:spamassassin_exec_t
> /sbin/restorecon reset /usr/sbin/cracklib-format context system_u:object_r:sbin_t->system_u:object_r:crack_exec_t
> /sbin/restorecon reset /usr/sbin/logrotate context system_u:object_r:sbin_t->system_u:object_r:logrotate_exec_t
> /sbin/restorecon reset /usr/sbin/cracklib-check context system_u:object_r:sbin_t->system_u:object_r:crack_exec_t
> /sbin/restorecon reset /usr/sbin/groupdel context system_u:object_r:sbin_t->system_u:object_r:groupadd_exec_t
> /sbin/restorecon reset /usr/sbin/cracklib-packer context system_u:object_r:sbin_t->system_u:object_r:crack_exec_t
> /sbin/restorecon reset /usr/sbin/tmpwatch context system_u:object_r:sbin_t->system_u:object_r:tmpreaper_exec_t
> /sbin/restorecon reset /usr/sbin/utempter context system_u:object_r:sbin_t->system_u:object_r:utempter_exec_t
> /sbin/restorecon reset /usr/sbin/groupadd context system_u:object_r:sbin_t->system_u:object_r:groupadd_exec_t
> /sbin/restorecon reset /usr/sbin/userdel context system_u:object_r:sbin_t->system_u:object_r:useradd_exec_t
> /sbin/restorecon reset /usr/sbin/groupmod context system_u:object_r:sbin_t->system_u:object_r:groupadd_exec_t
> /sbin/restorecon reset /usr/sbin/usermod context system_u:object_r:sbin_t->system_u:object_r:useradd_exec_t
> /sbin/restorecon reset /usr/sbin/gdm-binary context system_u:object_r:xdm_exec_t->system_u:object_r:sbin_t
> /sbin/restorecon reset /usr/sbin/tcpd context system_u:object_r:sbin_t->system_u:object_r:tcpd_exec_t
> /sbin/restorecon reset /usr/sbin/cracklib-unpacker context system_u:object_r:sbin_t->system_u:object_r:crack_exec_t
> /sbin/restorecon reset /usr/sbin/useradd context system_u:object_r:sbin_t->system_u:object_r:useradd_exec_t
> /sbin/restorecon reset /boot/System.map context system_u:object_r:system_map_t->system_u:object_r:boot_t
> /sbin/restorecon reset /lib/security/pam_krb5/pam_krb5_storetmp context system_u:object_r:lib_t->system_u:object_r:pam_exec_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.seriomap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.inputmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.ccwmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.isapnpmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.usbmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.dep context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.alias context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.pcimap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.ieee1394map context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1674_FC5smp/modules.symbols context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.seriomap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.inputmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.ccwmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.isapnpmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.usbmap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.dep context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.alias context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.pcimap context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.ieee1394map context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /lib/modules/2.6.14-1.1665_FC5smp/modules.symbols context root:object_r:modules_object_t->system_u:object_r:modules_dep_t
> /sbin/restorecon reset /var/lock/subsys/sm-client context system_u:object_r:unlabeled_t->system_u:object_r:var_lock_t
> /sbin/restorecon reset /var/lock/subsys/sendmail context system_u:object_r:unlabeled_t->system_u:object_r:var_lock_t
> /sbin/restorecon reset /var/gdm context system_u:object_r:unlabeled_t->system_u:object_r:var_t
> /sbin/restorecon reset /var/gdm/.cookie context system_u:object_r:unlabeled_t->system_u:object_r:var_t
> /sbin/restorecon reset /var/gdm/:0.Xauth context system_u:object_r:unlabeled_t->system_u:object_r:var_t
> /sbin/restorecon reset /var/gdm/.gdmfifo context system_u:object_r:unlabeled_t->system_u:object_r:var_t
> /sbin/restorecon reset /var/lib/logrotate.status context system_u:object_r:var_lib_t->system_u:object_r:logrotate_var_lib_t
> /sbin/restorecon reset /var/log/rpmpkgs context system_u:object_r:var_log_t->system_u:object_r:rpm_log_t
> /sbin/restorecon reset /var/log/gdm context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
> /sbin/restorecon reset /var/log/gdm/:0.log.1 context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
> /sbin/restorecon reset /var/log/gdm/:0.log context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
> /sbin/restorecon reset /var/log/gdm/:0.log.3 context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
> /sbin/restorecon reset /var/log/gdm/:0.log.2 context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
> /sbin/restorecon reset /var/log/gdm/:0.log.4 context system_u:object_r:unlabeled_t->system_u:object_r:var_log_t
> /sbin/restorecon reset /var/log/yum.log context system_u:object_r:var_log_t->system_u:object_r:rpm_log_t
> /sbin/restorecon reset /var/log/yum.log.1 context system_u:object_r:rpm_log_t->system_u:object_r:var_log_t
> /sbin/restorecon reset /var/run/sudo context system_u:object_r:var_run_t->system_u:object_r:pam_var_run_t
> /sbin/restorecon reset /var/run/sudo/sds context system_u:object_r:var_run_t->system_u:object_r:pam_var_run_t
> /sbin/restorecon reset /var/run/sudo/root context system_u:object_r:var_run_t->system_u:object_r:pam_var_run_t
> /sbin/restorecon reset /var/run/sudo/_pam_timestamp_key context system_u:object_r:var_run_t->system_u:object_r:pam_var_run_t
> /sbin/restorecon reset /var/run/console context system_u:object_r:var_run_t->system_u:object_r:pam_var_console_t
> /sbin/restorecon reset /bin/tracepath context system_u:object_r:bin_t->system_u:object_r:traceroute_exec_t
> /sbin/restorecon reset /bin/mount context system_u:object_r:bin_t->system_u:object_r:mount_exec_t
> /sbin/restorecon reset /bin/traceroute context system_u:object_r:bin_t->system_u:object_r:traceroute_exec_t
> /sbin/restorecon reset /bin/umount context system_u:object_r:bin_t->system_u:object_r:mount_exec_t
> /sbin/restorecon reset /bin/tracepath6 context system_u:object_r:bin_t->system_u:object_r:traceroute_exec_t
> /sbin/restorecon reset /sbin/dmsetup.static context system_u:object_r:unlabeled_t->system_u:object_r:sbin_t
> /sbin/restorecon reset /sbin/mkinitrd context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
> /sbin/restorecon reset /sbin/grubby context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
> /sbin/restorecon reset /sbin/sulogin context system_u:object_r:sbin_t->system_u:object_r:sulogin_exec_t
> /sbin/restorecon reset /sbin/cryptsetup context system_u:object_r:unlabeled_t->system_u:object_r:sbin_t
> /sbin/restorecon reset /sbin/grub-terminfo context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
> /sbin/restorecon reset /sbin/grub-install context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
> /sbin/restorecon reset /sbin/grub-md5-crypt context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
> /sbin/restorecon reset /sbin/grub context system_u:object_r:sbin_t->system_u:object_r:bootloader_exec_t
> /sbin/restorecon reset /sbin/pam_timestamp_check context system_u:object_r:sbin_t->system_u:object_r:pam_exec_t
> /sbin/restorecon reset /sbin/pam_console_apply context system_u:object_r:sbin_t->system_u:object_r:pam_console_exec_t
> /sbin/restorecon reset /etc/ld.so.cache context root:object_r:etc_t->system_u:object_r:ld_so_cache_t
> /sbin/restorecon reset /etc/rc.d/init.d/sendmail context system_u:object_r:unlabeled_t->system_u:object_r:initrc_exec_t
> /sbin/restorecon reset /etc/X11/xdm/Xsession context system_u:object_r:unlabeled_t->system_u:object_r:etc_t
>
>
>
>   
> ------------------------------------------------------------------------
>
> security:  3 users, 6 roles, 1044 types, 116 bools, 1 sens, 256 cats
> security:  55 classes, 31351 rules
> security:  invalidating context system_u:system_r:sendmail_launch_t:s0
> security:  invalidating context system_u:object_r:sendmail_launch_exec_t:s0
> security:  invalidating context system_u:object_r:sendmail_launch_lock_t:s0
> security:  invalidating context user_u:system_r:ypxfr_t:s0
> security:  invalidating context system_u:object_r:xserver_log_t:s0
> security:  invalidating context system_u:object_r:xdm_xserver_tmp_t:s0
> security:  invalidating context system_u:object_r:xsession_exec_t:s0
> security:  invalidating context system_u:object_r:xdm_rw_etc_t:s0
> security:  invalidating context system_u:object_r:xdm_var_run_t:s0
> security:  invalidating context system_u:object_r:xdm_var_lib_t:s0
> security:  invalidating context user_u:sysadm_r:ypxfr_t:s0
> security:  invalidating context system_u:system_r:procmail_t:s0
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xdm_var_run_t:s0) returned 22 for dev=dm-0 ino=2494768
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xdm_var_run_t:s0) returned 22 for dev=dm-0 ino=2494119
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:sendmail_launch_lock_t:s0) returned 22 for dev=dm-0 ino=5626272
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:sendmail_launch_lock_t:s0) returned 22 for dev=dm-0 ino=5626270
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657925
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657949
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657950
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657928
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657952
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xserver_log_t:s0) returned 22 for dev=dm-0 ino=5657931
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:lvm_exec_t:s0) returned 22 for dev=dm-0 ino=7685553
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:lvm_exec_t:s0) returned 22 for dev=dm-0 ino=7685538
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:sendmail_launch_exec_t:s0) returned 22 for dev=dm-0 ino=5102806
> inode_doinit_with_dentry:  context_to_sid(system_u:object_r:xsession_exec_t) returned 22 for dev=dm-0 ino=5103774
> security:  3 users, 6 roles, 1044 types, 116 bools, 1 sens, 256 cats
> security:  55 classes, 31351 rules
>   
> ------------------------------------------------------------------------
>
> type=AVC msg=audit(1132062016.379:234): avc:  denied  { getattr } for  pid=25793 comm="find" name="gdm-binary" dev=dm-0 ino=2035791 scontext=root:system_r:rpm_script_t:s0-s0:c0.c255 tcontext=system_u:object_r:xdm_exec_t:s0 tclass=file
> type=AVC msg=audit(1132062016.831:235): avc:  denied  { getattr } for  pid=25789 comm="restorecon" name="gdm-binary" dev=dm-0 ino=2035791 scontext=root:system_r:restorecon_t:s0-s0:c0.c255 tcontext=system_u:object_r:xdm_exec_t:s0 tclass=file
> type=AVC msg=audit(1132062016.831:236): avc:  denied  { relabelfrom } for  pid=25789 comm="restorecon" name="gdm-binary" dev=dm-0 ino=2035791 scontext=root:system_r:restorecon_t:s0-s0:c0.c255 tcontext=system_u:object_r:xdm_exec_t:s0 tclass=file
>   


-- 



--
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: Policy mods in last nights refpolicy

[Christopher J. PeBenito]

On Tue, 2005-11-15 at 09:25 -0500, Daniel J Walsh wrote:
> diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/system/files.fc serefpolicy-2.0.1/policy/modules/system/files.fc
> --- nsaserefpolicy/policy/modules/system/files.fc	2005-11-14 18:24:06.000000000 -0500
> +++ serefpolicy-2.0.1/policy/modules/system/files.fc	2005-11-15 09:19:21.000000000 -0500
> @@ -214,3 +214,4 @@
>  /var/tmp/lost\+found	-d	gen_context(system_u:object_r:lost_found_t,s0)
>  /var/tmp/lost\+found/.*		<<none>>
>  /var/tmp/vi\.recover	-d	gen_context(system_u:object_r:tmp_t,s0)
> +/var/lib/abl(/.*)?		gen_context(system_u:object_r:var_auth_t,s0)
> diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/system/files.te serefpolicy-2.0.1/policy/modules/system/files.te
> --- nsaserefpolicy/policy/modules/system/files.te	2005-11-14 18:24:06.000000000 -0500
> +++ serefpolicy-2.0.1/policy/modules/system/files.te	2005-11-15 09:19:21.000000000 -0500
> @@ -167,3 +167,12 @@
>  #
>  type var_spool_t;
>  files_tmp_file(var_spool_t)
> +
> +#
> +# var_auth_t is the type of /var/lib/auth, usually
> +# used for auth data in pam_able
> +#
> +type var_auth_t, file_type;
> +fs_associate(var_auth_t)
> +fs_associate_noxattr(var_auth_t)

A couple notes.  It seems more logical for var_auth_t to be in authlogin
along with the rest of the pam types.  Also, if its not moved, then
encapsulation is broken since an interface in authlogin refers to types
not in that module.

I'll move var_auth_t to authlogin, but I'm not clear on the rules you
added to auth_use_nsswitch():

> --- nsaserefpolicy/policy/modules/system/authlogin.if	2005-11-14 18:24:06.000000000 -0500
> +++ serefpolicy-2.0.1/policy/modules/system/authlogin.if	2005-11-15 09:19:21.000000000 -0500
> @@ -931,6 +931,9 @@
>  	optional_policy(`samba.te',`
>  		samba_connect_winbind($1)
>  	')
> +	allow $1 var_auth_t:dir r_dir_perms;
> +	allow $1 var_auth_t:file create_file_perms;
> +
>  ')
>  
>  ########################################

Is this really supposed to be create_file_perms?  It seems like it
should just be r_file_perms since the dir access is r_dir_perms.  The
interface also needs a gen_require() since it not explicitly refers to
types.

Also, now that people are going to be using refpolicy, we're going to
have to start bumping the module versions in the policy_module()
statements when changes are made, so that modules can be upgraded
correctly.  Currently the modules are set to 1.0.  After a little
thought, it seems like it would be better if we go to x.y.z for
versioning: bump z for each changed module when committing to
sourceforge; bump y for each changed module when releasing; bump x for
major design changes to the module.  Does this seem like a reasonable
versioning scheme?

-- 
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: [ SEMANAGE ] Stub pserver backend

[Ivan Gyurdiev]

>
>> I'd prefer to wait until we have a basic working implementation and a
>> user ready for merging.  Posting stubs or function prototypes to the
>> list as examples is fine, but I don't see much value in merging them.
>> It was ok for early development of libsemanage in order to build up
>> infrastructure and allow early collaboration/feedback, but I'd prefer to
>> move to merging actual implementations now.  I'd especially like to see
>> sample users (even just dummy test programs) that allow the code to be
>> trivially exercised along with the submissions to help put it in
>> context.
>>     
Ok, in that case disregard the last two patches - I will resend those 
with implementation.
>
> Also, I think we need to think about priorities of tasks; policy server
> backend and runtime boolean manipulation via libsemanage seem fairly low
> to me right now.  Of greater importance would be:
>   
Sure, but stubs are easy to write - just wanted to point to where the 
functionality should go into.
The rest of the things you specified are important, but a bit harder to 
do... not disregarding the issues.
> - Finishing the ports functionality and exporting those interfaces,
>   
I think this is of particularly high importance to Dan - I'll have to 
work on that soon.

> - Creating utilities for managing the other policy components via
> libsemanage.
>   
What would all those utilities look like - shell? python with GUI? 
should I be working on those - Dan?


--
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: [ SEMANAGE ] Stub pserver backend

[Joshua Brindle]

Ivan Gyurdiev wrote:
>>
>>> I'd prefer to wait until we have a basic working implementation and a
>>> user ready for merging.  Posting stubs or function prototypes to the
>>> list as examples is fine, but I don't see much value in merging them.
>>> It was ok for early development of libsemanage in order to build up
>>> infrastructure and allow early collaboration/feedback, but I'd prefer to
>>> move to merging actual implementations now.  I'd especially like to see
>>> sample users (even just dummy test programs) that allow the code to be
>>> trivially exercised along with the submissions to help put it in
>>> context.
>>>     
> 
> Ok, in that case disregard the last two patches - I will resend those 
> with implementation.
> 
>>
>> Also, I think we need to think about priorities of tasks; policy server
>> backend and runtime boolean manipulation via libsemanage seem fairly low
>> to me right now.  Of greater importance would be:
>>   
> 
> Sure, but stubs are easy to write - just wanted to point to where the 
> functionality should go into.
> The rest of the things you specified are important, but a bit harder to 
> do... not disregarding the issues.
> 
>> - Finishing the ports functionality and exporting those interfaces,
>>   
> 
> I think this is of particularly high importance to Dan - I'll have to 
> work on that soon.

Are you going to do this in python? If so we'll need to wrap all the 
port types and also implement the write/transaction functionality, all 
that has been done so far is querying of seusers, users, modules.

Have you looked at the swig wrappers? Do you feel comfortable wrapping 
additional types?
> 
>> - Creating utilities for managing the other policy components via
>> libsemanage.
>>   
> 
> What would all those utilities look like - shell? python with GUI? 
> should I be working on those - Dan?
> 
> 

--
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: [ SEMANAGE ] Stub pserver backend

[Joshua Brindle]

Ivan Gyurdiev wrote:
> 
>> Giving me the tools in libsemanage to build the manipulation of ports, 
> 
> Okay, will work on that..
> 
>> seusers 
> 
> The seuser APIs are already available, and should work in libsemanage.
> Although MLS validation is not happening, the modification should work, 
> and should verify that the SElinux user exists.
> Not sure if python bindings are currently available.

the swig wrappers don't currently have any write (transaction) 
functionality, nor are the seuser keys and create functions wrapped, 
these will need to be done.
> 
>> and potentially
>> user modules (local.pp) from python.
> 
> Same for user APIs. Those things do not go into modules currently - 
> they're written back out into flat files. Why do we want those into a 
> module? I think Stephen also mentioned a while ago that modules cannot 
> yet support all of the objects that we are managing. Is this still the 
> case?
> 

We don't want users in modules, it isn't even supported with MLS. The 
flat file implementations are already working, we just need to wrap the 
interfaces to write the python utilities.


--
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: [ SEMANAGE ] Stub pserver backend

[Chad Sellers]

On Tuesday 15 November 2005 09:38, Daniel J Walsh wrote:
> Stephen Smalley wrote:
> > On Tue, 2005-11-15 at 08:38 -0500, Daniel J Walsh wrote:
> >> refpolicy went in last night.   Now we need to get strict/mls working.
> >> As well as clean up the bugs that
> >> refpolicy will cause.
> >
> > Ok, I'm presently updated a rawhide targeted system, and have attached
> > three files with relevant output from yum, dmesg, and avc audit.  The
> > yum output shows what booleans were lost in translation and what files
> > were relabeled by restorecon.  The dmesg output shows what security
> > contexts were no longer valid in the new policy, which then triggers
> > subsequent inode_doinit errors upon the relabeling.  The avc audit
> > output shows the denials that would have occurred during the restorecon
> > if I had done this in enforcing mode.  I also noticed that policy is
> > reloaded twice; second load occurs during cleanup phase for some reason.
>
> Ok I should not have turned off xdm, there is a bug in the spec for jvm.
>
> sendmail_launch was a last minute change to targeted from Russell that
> has not been ported into refpolicy yet.
>
> ypxfr is a partial policy to implement ypxfr, but is not used yet.
>
> We need to get procmail ported to reference policy
>
> I turned off lvm, because it brought a lot of other pieces in that I did
> not want to deal with.   We can revisit this decision.
>
> reference policy has added some confinement of some user space tools,
> which we will have to monitor for breakage.
>
> Dan
>
Note that most of these issues fall into one of the following 3 areas (sent 
off-list before, so I reposted them on-list)

1) Policy modules organization involving including policy from multiple old 
policy .te files
usermanage - passwd, crack, and useradd
authlogin - login, utempter, pam, pamconsole
locallogin - login, sulogin
cron - crond and crontab
netutils - traceroute and ping
spamassassin - spamd and spamassassin

2) additional policies for mount and bootloader.  These policies are currently 
required for refpolicy to function, and would require a significant rewrite 
to remove this dependency.  Since they are small and easily verifiable, they 
have been left in.

3) Policy differences due to very new (less than 2 weeks) policy in rawhide.  
We have not tracked all changes in rawhide up to today.  These include the 
addition of procmail policy to targeted, the rewrite of mta/sendmail, and 
numerous other changes.  The invalidated contexts are coming from here.

Also, I believe Dan added the secondary policy reload to solve the problem 
where rpm removed the policy binary after install.  This is a %triggerpostun 
in the rpm, which will only trigger when upgrading from a version less than 2 
(i.e. only when upgrading from traditional to refpolicy).

Thanks,
Chad

-- 
----------------------
Chad Sellers
Tresys Technology, LLC
csellers@tresys.com
(410)290-1411 x117
http://www.tresys.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: [ SEMANAGE ] Stub pserver backend

[Stephen Smalley]

On Tue, 2005-11-15 at 11:05 -0500, Ivan Gyurdiev wrote:
> > Giving me the tools in libsemanage to build the manipulation of ports, 
> Okay, will work on that..
> 
> > seusers 
> The seuser APIs are already available, and should work in libsemanage.
> Although MLS validation is not happening, the modification should work, 
> and should verify that the SElinux user exists.
> Not sure if python bindings are currently available.
> > and potentially
> > user modules (local.pp) from python.
> Same for user APIs. Those things do not go into modules currently - 
> they're written back out into flat files. Why do we want those into a 
> module? I think Stephen also mentioned a while ago that modules cannot 
> yet support all of the objects that we are managing. Is this still the case?

In this context, "user modules" == "local modules" == module equivalent
to a local.te file in the old policy source-based approach.  Not related
to Linux or SELinux users, just user-supplied.  We want users to still
be able to run audit2allow (with additional flags), dump the output to a
file, run it through checkmodule -m and then install it with semodule.

Yes, non-base modules don't support SELinux user definitions when MLS is
enabled presently, so you have to put all SELinux user definitions into
the base module, and only the base module supports the object context
definitions that are part of policy (versus file contexts).

-- 
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: [ SEMANAGE ] Stub pserver backend

[Ivan Gyurdiev]

> Giving me the tools in libsemanage to build the manipulation of ports, 
Okay, will work on that..

> seusers 
The seuser APIs are already available, and should work in libsemanage.
Although MLS validation is not happening, the modification should work, 
and should verify that the SElinux user exists.
Not sure if python bindings are currently available.
> and potentially
> user modules (local.pp) from python.
Same for user APIs. Those things do not go into modules currently - 
they're written back out into flat files. Why do we want those into a 
module? I think Stephen also mentioned a while ago that modules cannot 
yet support all of the objects that we are managing. Is this still the case?


--
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: [ SEMANAGE ] Stub pserver backend

[Joshua Brindle]

Ivan Gyurdiev wrote:
> 
>>
>> the swig wrappers don't currently have any write (transaction) 
>> functionality, nor are the seuser keys and create functions wrapped, 
>> these will need to be done.
> 
> Speaking of transactions, I see the "moving genhomedircon patch outside 
> the active-lock section" patch has been merged. That's fine, but I also 
> pointed out why genhomedircon should be using transactions in read-only 
> mode as well - please see the relevant thread. Using transactions there 
> eliminates an unnecessary policy rebuild, and a race condition (but on 
> the other hand then you have another deadlock to deal with, because 
> you're calling it with the transaction lock held).
> 
> 
There is no race condition on reads. Every query returns the transaction 
number and the client should check the transaction numbers for consistency.

The policy rebuild is an implementation issue, as little or as much of 
the cache can be filled at any time, and the transaction number can 
always be polled to ensure its up to date.

That said, genhomedircon may be placed inside the transaction at some 
point in the future when the whole policy directory is inside the 
sandbox, but until then there is no need for this, and it causes tons of 
extra copying of files, filling of unused databases, parsing of policydb 
and a possible policy rebuild/reload.

--
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: [ SEMANAGE ] Stub pserver backend

[Ivan Gyurdiev]

>
> the swig wrappers don't currently have any write (transaction) 
> functionality, nor are the seuser keys and create functions wrapped, 
> these will need to be done.
Speaking of transactions, I see the "moving genhomedircon patch outside 
the active-lock section" patch has been merged. That's fine, but I also 
pointed out why genhomedircon should be using transactions in read-only 
mode as well - please see the relevant thread. Using transactions there 
eliminates an unnecessary policy rebuild, and a race condition (but on 
the other hand then you have another deadlock to deal with, because 
you're calling it with the transaction lock held).


--
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: [ SEMANAGE ] Stub pserver backend

[Ivan Gyurdiev]

J
>>> - Finishing the ports functionality and exporting those interfaces,
>>>   
>>
>> I think this is of particularly high importance to Dan - I'll have to 
>> work on that soon.
>
> Are you going to do this in python? 
Well, the ports code will be written in C, but the interface will 
probably be exported via python.
> If so we'll need to wrap all the port types and also implement the 
> write/transaction functionality, all that has been done so far is 
> querying of seusers, users, modules.
Yes..
> Have you looked at the swig wrappers? Do you feel comfortable wrapping 
> additional types?
Not yet, but I can investigate..


--
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: [ SEMANAGE ] Stub pserver backend

[Ivan Gyurdiev]

J
> There is no race condition on reads. Every query returns the 
> transaction number and the client should check the transaction numbers 
> for consistency.
Ah... so that's what commit_num is for...

Well, I haven't been using that in the other interfaces, so unless 
you've added it with the swig patch, there are no transaction numbers 
for objects other than modules - those functions all return STATUS_ERR 
or STATUS_SUCCESS.

Relying on transaction numbers seems uglier than using a transaction - 
do you want the client to keep re-running the queries until they match?
> The policy rebuild is an implementation issue, as little or as much of 
> the cache can be filled at any time, and the transaction number can 
> always be polled to ensure its up to date.
That's a good point - I didn't realize there was a transaction number, 
so taking that into account should allow more optimizations.

> That said, genhomedircon may be placed inside the transaction at some 
> point in the future when the whole policy directory is inside the 
> sandbox, but until then there is no need for this, and it causes tons 
> of extra copying of files, filling of unused databases, parsing of 
> policydb and a possible policy rebuild/reload.
Yes, commit() needs more optimizations - the whole rebuild sequence 
should be skipped if there were no changes..


--
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: Policy mods in last nights refpolicy

[Daniel J Walsh]

Christopher J. PeBenito wrote:
> On Tue, 2005-11-15 at 09:25 -0500, Daniel J Walsh wrote:
>   
>> diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/system/files.fc serefpolicy-2.0.1/policy/modules/system/files.fc
>> --- nsaserefpolicy/policy/modules/system/files.fc	2005-11-14 18:24:06.000000000 -0500
>> +++ serefpolicy-2.0.1/policy/modules/system/files.fc	2005-11-15 09:19:21.000000000 -0500
>> @@ -214,3 +214,4 @@
>>  /var/tmp/lost\+found	-d	gen_context(system_u:object_r:lost_found_t,s0)
>>  /var/tmp/lost\+found/.*		<<none>>
>>  /var/tmp/vi\.recover	-d	gen_context(system_u:object_r:tmp_t,s0)
>> +/var/lib/abl(/.*)?		gen_context(system_u:object_r:var_auth_t,s0)
>> diff --exclude-from=exclude -N -u -r nsaserefpolicy/policy/modules/system/files.te serefpolicy-2.0.1/policy/modules/system/files.te
>> --- nsaserefpolicy/policy/modules/system/files.te	2005-11-14 18:24:06.000000000 -0500
>> +++ serefpolicy-2.0.1/policy/modules/system/files.te	2005-11-15 09:19:21.000000000 -0500
>> @@ -167,3 +167,12 @@
>>  #
>>  type var_spool_t;
>>  files_tmp_file(var_spool_t)
>> +
>> +#
>> +# var_auth_t is the type of /var/lib/auth, usually
>> +# used for auth data in pam_able
>> +#
>> +type var_auth_t, file_type;
>> +fs_associate(var_auth_t)
>> +fs_associate_noxattr(var_auth_t)
>>     
>
> A couple notes.  It seems more logical for var_auth_t to be in authlogin
> along with the rest of the pam types.  Also, if its not moved, then
> encapsulation is broken since an interface in authlogin refers to types
> not in that module.
>
>   
Ok fine
> I'll move var_auth_t to authlogin, but I'm not clear on the rules you
> added to auth_use_nsswitch():
>
>   
>> --- nsaserefpolicy/policy/modules/system/authlogin.if	2005-11-14 18:24:06.000000000 -0500
>> +++ serefpolicy-2.0.1/policy/modules/system/authlogin.if	2005-11-15 09:19:21.000000000 -0500
>> @@ -931,6 +931,9 @@
>>  	optional_policy(`samba.te',`
>>  		samba_connect_winbind($1)
>>  	')
>> +	allow $1 var_auth_t:dir r_dir_perms;
>> +	allow $1 var_auth_t:file create_file_perms;
>> +
>>  ')
>>  
>>  ########################################
>>     
>
> Is this really supposed to be create_file_perms?  It seems like it
> should just be r_file_perms since the dir access is r_dir_perms.  The
> interface also needs a gen_require() since it not explicitly refers to
> types.
>   
No apps need to be able to create and delete files in this directory.  
This pam applet keeps track
of failed logins or something like that.
> Also, now that people are going to be using refpolicy, we're going to
> have to start bumping the module versions in the policy_module()
> statements when changes are made, so that modules can be upgraded
> correctly.  Currently the modules are set to 1.0.  After a little
> thought, it seems like it would be better if we go to x.y.z for
> versioning: bump z for each changed module when committing to
> sourceforge; bump y for each changed module when releasing; bump x for
> major design changes to the module.  Does this seem like a reasonable
> versioning scheme?
>
>   
Yes.  Why not start out at 2.0.1 though since this is a major step 
forward in 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: [ SEMANAGE ] Stub pserver backend

[Daniel J Walsh]

Ivan Gyurdiev wrote:
>>
>>> I'd prefer to wait until we have a basic working implementation and a
>>> user ready for merging.  Posting stubs or function prototypes to the
>>> list as examples is fine, but I don't see much value in merging them.
>>> It was ok for early development of libsemanage in order to build up
>>> infrastructure and allow early collaboration/feedback, but I'd 
>>> prefer to
>>> move to merging actual implementations now.  I'd especially like to see
>>> sample users (even just dummy test programs) that allow the code to be
>>> trivially exercised along with the submissions to help put it in
>>> context.
>>>     
> Ok, in that case disregard the last two patches - I will resend those 
> with implementation.
>>
>> Also, I think we need to think about priorities of tasks; policy server
>> backend and runtime boolean manipulation via libsemanage seem fairly low
>> to me right now.  Of greater importance would be:
>>   
> Sure, but stubs are easy to write - just wanted to point to where the 
> functionality should go into.
> The rest of the things you specified are important, but a bit harder 
> to do... not disregarding the issues.
>> - Finishing the ports functionality and exporting those interfaces,
>>   
> I think this is of particularly high importance to Dan - I'll have to 
> work on that soon.
>
>> - Creating utilities for managing the other policy components via
>> libsemanage.
>>   
> What would all those utilities look like - shell? python with GUI? 
> should I be working on those - Dan?
>
No, I am now. 

-- 



--
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: [ SEMANAGE ] Stub pserver backend

[Daniel J Walsh]

Joshua Brindle wrote:
> Ivan Gyurdiev wrote:
>>>
>>>> I'd prefer to wait until we have a basic working implementation and a
>>>> user ready for merging.  Posting stubs or function prototypes to the
>>>> list as examples is fine, but I don't see much value in merging them.
>>>> It was ok for early development of libsemanage in order to build up
>>>> infrastructure and allow early collaboration/feedback, but I'd 
>>>> prefer to
>>>> move to merging actual implementations now.  I'd especially like to 
>>>> see
>>>> sample users (even just dummy test programs) that allow the code to be
>>>> trivially exercised along with the submissions to help put it in
>>>> context.
>>>>     
>>
>> Ok, in that case disregard the last two patches - I will resend those 
>> with implementation.
>>
>>>
>>> Also, I think we need to think about priorities of tasks; policy server
>>> backend and runtime boolean manipulation via libsemanage seem fairly 
>>> low
>>> to me right now.  Of greater importance would be:
>>>   
>>
>> Sure, but stubs are easy to write - just wanted to point to where the 
>> functionality should go into.
>> The rest of the things you specified are important, but a bit harder 
>> to do... not disregarding the issues.
>>
>>> - Finishing the ports functionality and exporting those interfaces,
>>>   
>>
>> I think this is of particularly high importance to Dan - I'll have to 
>> work on that soon.
>
> Are you going to do this in python? If so we'll need to wrap all the 
> port types and also implement the write/transaction functionality, all 
> that has been done so far is querying of seusers, users, modules.
Yes we need a full semange command set written in python.

Something like

semanage --seuser --add -s user_u -r SystemLow-SystemHigh dwalsh
semanage --port --add -p 1234 httpd_port_t
semanage --seuser --delete dwalsh

>
> Have you looked at the swig wrappers? Do you feel comfortable wrapping 
> additional types?
You asking me or Ivan?
>>
>>> - Creating utilities for managing the other policy components via
>>> libsemanage.
>>>   
>>
>> What would all those utilities look like - shell? python with GUI? 
>> should I be working on those - Dan?
>>
>>


-- 



--
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: Policy mods in last nights refpolicy

[Stephen Smalley]

On Tue, 2005-11-15 at 10:52 -0500, Christopher J. PeBenito wrote:
> Also, now that people are going to be using refpolicy, we're going to
> have to start bumping the module versions in the policy_module()
> statements when changes are made, so that modules can be upgraded
> correctly.  Currently the modules are set to 1.0.  After a little
> thought, it seems like it would be better if we go to x.y.z for
> versioning: bump z for each changed module when committing to
> sourceforge; bump y for each changed module when releasing; bump x for
> major design changes to the module.  Does this seem like a reasonable
> versioning scheme?

To what extent are the module-internal version numbers useful?
Versus the usual versioning of the policy packages (in which case you
have a single version for the base policy package plus independent
versions for any policy modules packaged separately).  Why can't the
versioning just be handled via rpm in the usual manner - why does
libsemanage need to deal with ensuring that we don't upgrade to an
"older" module version?

-- 
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: Policy mods in last nights refpolicy

[Stephen Smalley]

On Wed, 2005-11-16 at 08:48 -0500, Stephen Smalley wrote: 
> On Tue, 2005-11-15 at 10:52 -0500, Christopher J. PeBenito wrote:
> > Also, now that people are going to be using refpolicy, we're going to
> > have to start bumping the module versions in the policy_module()
> > statements when changes are made, so that modules can be upgraded
> > correctly.  Currently the modules are set to 1.0.  After a little
> > thought, it seems like it would be better if we go to x.y.z for
> > versioning: bump z for each changed module when committing to
> > sourceforge; bump y for each changed module when releasing; bump x for
> > major design changes to the module.  Does this seem like a reasonable
> > versioning scheme?
> 
> To what extent are the module-internal version numbers useful?
> Versus the usual versioning of the policy packages (in which case you
> have a single version for the base policy package plus independent
> versions for any policy modules packaged separately).  Why can't the
> versioning just be handled via rpm in the usual manner - why does
> libsemanage need to deal with ensuring that we don't upgrade to an
> "older" module version?

Just to note:  I understand the notion of having per-module version
numbers for modules that are built separately, but I'm not clear on
whether it is useful to have those version numbers as part of the module
state and checked by libsemanage versus just having them used as the
basis for the version number for the rpm package containing the module.
For example, if I build the httpd policy module as a separate package
and it has a module version of 1.1, I'd expect to use that version for
the package version (plus a release number, so httpd-policy-1.1-1), just
as we currently use the policy version number for the corresponding
policy package today.  But the policy version number (or likewise for
any other component, like the libsemanage version number) is not part of
the policy's state and is only used by the package management software.
It seems like there is potential for conflict here between libsemanage
and rpm, e.g. user runs rpm --oldpackage -Uvh httpd-policy-1.0-1, but
semodule fails due to the libsemanage checking (perhaps not if we always
do semodule -i, but you get the idea).

-- 
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: Policy mods in last nights refpolicy

[Christopher J. PeBenito]

On Tue, 2005-11-15 at 19:55 -0500, Daniel J Walsh wrote:
> Christopher J. PeBenito wrote:
> > On Tue, 2005-11-15 at 09:25 -0500, Daniel J Walsh wrote:
> > I'm not clear on the rules you added to auth_use_nsswitch():
> >   
> >> --- nsaserefpolicy/policy/modules/system/authlogin.if	2005-11-14 18:24:06.000000000 -0500
> >> +++ serefpolicy-2.0.1/policy/modules/system/authlogin.if	2005-11-15 09:19:21.000000000 -0500
> >> @@ -931,6 +931,9 @@
> >>  	optional_policy(`samba.te',`
> >>  		samba_connect_winbind($1)
> >>  	')
> >> +	allow $1 var_auth_t:dir r_dir_perms;
> >> +	allow $1 var_auth_t:file create_file_perms;
> >> +
> >>  ')
> >>  
> >>  ########################################
> >>     
> >
> > Is this really supposed to be create_file_perms?  It seems like it
> > should just be r_file_perms since the dir access is r_dir_perms.  The
> > interface also needs a gen_require() since it not explicitly refers to
> > types.
> >   
> No apps need to be able to create and delete files in this directory.  
> This pam applet keeps track
> of failed logins or something like that.

In that case, it sounds like these additions need to be an interface by
themselves since not all users of nsswitch users do authentication.
Also the dir perms should be rw_dir_perms.

-- 
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: Policy mods in last nights refpolicy

[Joshua Brindle]

On Wed, 2005-11-16 at 09:18 -0500, Stephen Smalley wrote:
> On Wed, 2005-11-16 at 08:48 -0500, Stephen Smalley wrote: 
> > On Tue, 2005-11-15 at 10:52 -0500, Christopher J. PeBenito wrote:
> > > Also, now that people are going to be using refpolicy, we're going to
> > > have to start bumping the module versions in the policy_module()
> > > statements when changes are made, so that modules can be upgraded
> > > correctly.  Currently the modules are set to 1.0.  After a little
> > > thought, it seems like it would be better if we go to x.y.z for
> > > versioning: bump z for each changed module when committing to
> > > sourceforge; bump y for each changed module when releasing; bump x for
> > > major design changes to the module.  Does this seem like a reasonable
> > > versioning scheme?
> > 
> > To what extent are the module-internal version numbers useful?
> > Versus the usual versioning of the policy packages (in which case you
> > have a single version for the base policy package plus independent
> > versions for any policy modules packaged separately).  Why can't the
> > versioning just be handled via rpm in the usual manner - why does
> > libsemanage need to deal with ensuring that we don't upgrade to an
> > "older" module version?
> 
> Just to note:  I understand the notion of having per-module version
> numbers for modules that are built separately, but I'm not clear on
> whether it is useful to have those version numbers as part of the module
> state and checked by libsemanage versus just having them used as the
> basis for the version number for the rpm package containing the module.
> For example, if I build the httpd policy module as a separate package
> and it has a module version of 1.1, I'd expect to use that version for
> the package version (plus a release number, so httpd-policy-1.1-1), just
> as we currently use the policy version number for the corresponding
> policy package today.  But the policy version number (or likewise for
> any other component, like the libsemanage version number) is not part of
> the policy's state and is only used by the package management software.
> It seems like there is potential for conflict here between libsemanage
> and rpm, e.g. user runs rpm --oldpackage -Uvh httpd-policy-1.0-1, but
> semodule fails due to the libsemanage checking (perhaps not if we always
> do semodule -i, but you get the idea).
> 

This is assuming that there will never be a module not managed by a
package manager. While this certainly isn't the primary target it would
at least be nice for people to be able to semodule -l and see the
version of the module. Third party modules that may/may not distribute
in rpm form also makes this useful. The spec file already uses -i so the
downgrade/upgrade isn't an issue with that, the only problem is managing
the version, which shouldn't be much of a hassle.



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