* [ SEMANAGE ] Stub pserver backend
@ 2005-11-14 21:55 Ivan Gyurdiev
2005-11-15 11:29 ` Stephen Smalley
0 siblings, 1 reply; 26+ messages in thread
From: Ivan Gyurdiev @ 2005-11-14 21:55 UTC (permalink / raw)
To: selinux; +Cc: Stephen Smalley
[-- 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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: [ SEMANAGE ] Stub pserver backend 2005-11-14 21:55 [ SEMANAGE ] Stub pserver backend Ivan Gyurdiev @ 2005-11-15 11:29 ` Stephen Smalley 2005-11-15 11:58 ` Stephen Smalley 0 siblings, 1 reply; 26+ messages in thread From: Stephen Smalley @ 2005-11-15 11:29 UTC (permalink / raw) To: Ivan Gyurdiev; +Cc: SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 11:29 ` Stephen Smalley @ 2005-11-15 11:58 ` Stephen Smalley 2005-11-15 13:38 ` Daniel J Walsh ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Stephen Smalley @ 2005-11-15 11:58 UTC (permalink / raw) To: Ivan Gyurdiev; +Cc: Daniel J Walsh, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 11:58 ` Stephen Smalley @ 2005-11-15 13:38 ` Daniel J Walsh 2005-11-15 14:12 ` Stephen Smalley 2005-11-15 16:05 ` Ivan Gyurdiev 2005-11-15 13:47 ` Stephen Smalley 2005-11-15 15:54 ` Ivan Gyurdiev 2 siblings, 2 replies; 26+ messages in thread From: Daniel J Walsh @ 2005-11-15 13:38 UTC (permalink / raw) To: Stephen Smalley; +Cc: Ivan Gyurdiev, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 13:38 ` Daniel J Walsh @ 2005-11-15 14:12 ` Stephen Smalley 2005-11-15 14:25 ` Policy mods in last nights refpolicy Daniel J Walsh 2005-11-15 14:38 ` [ SEMANAGE ] Stub pserver backend Daniel J Walsh 2005-11-15 16:05 ` Ivan Gyurdiev 1 sibling, 2 replies; 26+ messages in thread From: Stephen Smalley @ 2005-11-15 14:12 UTC (permalink / raw) To: Daniel J Walsh; +Cc: Ivan Gyurdiev, SELinux-dev, selinux [-- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Policy mods in last nights refpolicy 2005-11-15 14:12 ` Stephen Smalley @ 2005-11-15 14:25 ` Daniel J Walsh 2005-11-15 15:52 ` Christopher J. PeBenito 2005-11-15 14:38 ` [ SEMANAGE ] Stub pserver backend Daniel J Walsh 1 sibling, 1 reply; 26+ messages in thread From: Daniel J Walsh @ 2005-11-15 14:25 UTC (permalink / raw) To: Stephen Smalley; +Cc: Ivan Gyurdiev, SELinux-dev, selinux [-- 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Policy mods in last nights refpolicy 2005-11-15 14:25 ` Policy mods in last nights refpolicy Daniel J Walsh @ 2005-11-15 15:52 ` Christopher J. PeBenito 2005-11-16 0:55 ` Daniel J Walsh 2005-11-16 13:48 ` Stephen Smalley 0 siblings, 2 replies; 26+ messages in thread From: Christopher J. PeBenito @ 2005-11-15 15:52 UTC (permalink / raw) To: Daniel J Walsh; +Cc: Stephen Smalley, Ivan Gyurdiev, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Policy mods in last nights refpolicy 2005-11-15 15:52 ` Christopher J. PeBenito @ 2005-11-16 0:55 ` Daniel J Walsh 2005-11-16 14:38 ` Christopher J. PeBenito 2005-11-16 13:48 ` Stephen Smalley 1 sibling, 1 reply; 26+ messages in thread From: Daniel J Walsh @ 2005-11-16 0:55 UTC (permalink / raw) To: Christopher J. PeBenito Cc: Stephen Smalley, Ivan Gyurdiev, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Policy mods in last nights refpolicy 2005-11-16 0:55 ` Daniel J Walsh @ 2005-11-16 14:38 ` Christopher J. PeBenito 0 siblings, 0 replies; 26+ messages in thread From: Christopher J. PeBenito @ 2005-11-16 14:38 UTC (permalink / raw) To: Daniel J Walsh; +Cc: Stephen Smalley, Ivan Gyurdiev, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Policy mods in last nights refpolicy 2005-11-15 15:52 ` Christopher J. PeBenito 2005-11-16 0:55 ` Daniel J Walsh @ 2005-11-16 13:48 ` Stephen Smalley 2005-11-16 14:18 ` Stephen Smalley 1 sibling, 1 reply; 26+ messages in thread From: Stephen Smalley @ 2005-11-16 13:48 UTC (permalink / raw) To: Christopher J. PeBenito Cc: Daniel J Walsh, Ivan Gyurdiev, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Policy mods in last nights refpolicy 2005-11-16 13:48 ` Stephen Smalley @ 2005-11-16 14:18 ` Stephen Smalley 2005-11-16 14:46 ` Joshua Brindle 0 siblings, 1 reply; 26+ messages in thread From: Stephen Smalley @ 2005-11-16 14:18 UTC (permalink / raw) To: Christopher J. PeBenito Cc: selinux, SELinux-dev, Ivan Gyurdiev, Daniel J Walsh 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Policy mods in last nights refpolicy 2005-11-16 14:18 ` Stephen Smalley @ 2005-11-16 14:46 ` Joshua Brindle 0 siblings, 0 replies; 26+ messages in thread From: Joshua Brindle @ 2005-11-16 14:46 UTC (permalink / raw) To: Stephen Smalley Cc: Christopher J. PeBenito, selinux, SELinux-dev, Ivan Gyurdiev, Daniel J Walsh 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 14:12 ` Stephen Smalley 2005-11-15 14:25 ` Policy mods in last nights refpolicy Daniel J Walsh @ 2005-11-15 14:38 ` Daniel J Walsh 2005-11-15 16:02 ` Chad Sellers 1 sibling, 1 reply; 26+ messages in thread From: Daniel J Walsh @ 2005-11-15 14:38 UTC (permalink / raw) To: Stephen Smalley; +Cc: Ivan Gyurdiev, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 14:38 ` [ SEMANAGE ] Stub pserver backend Daniel J Walsh @ 2005-11-15 16:02 ` Chad Sellers 0 siblings, 0 replies; 26+ messages in thread From: Chad Sellers @ 2005-11-15 16:02 UTC (permalink / raw) To: Daniel J Walsh; +Cc: Stephen Smalley, Ivan Gyurdiev, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 13:38 ` Daniel J Walsh 2005-11-15 14:12 ` Stephen Smalley @ 2005-11-15 16:05 ` Ivan Gyurdiev 2005-11-15 15:59 ` Joshua Brindle 2005-11-15 16:05 ` Stephen Smalley 1 sibling, 2 replies; 26+ messages in thread From: Ivan Gyurdiev @ 2005-11-15 16:05 UTC (permalink / raw) To: Daniel J Walsh; +Cc: Stephen Smalley, SELinux-dev, selinux > 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 16:05 ` Ivan Gyurdiev @ 2005-11-15 15:59 ` Joshua Brindle 2005-11-15 16:25 ` Ivan Gyurdiev 2005-11-15 16:05 ` Stephen Smalley 1 sibling, 1 reply; 26+ messages in thread From: Joshua Brindle @ 2005-11-15 15:59 UTC (permalink / raw) To: Ivan Gyurdiev; +Cc: Daniel J Walsh, Stephen Smalley, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 15:59 ` Joshua Brindle @ 2005-11-15 16:25 ` Ivan Gyurdiev 2005-11-15 16:15 ` Joshua Brindle 0 siblings, 1 reply; 26+ messages in thread From: Ivan Gyurdiev @ 2005-11-15 16:25 UTC (permalink / raw) To: Joshua Brindle; +Cc: Daniel J Walsh, Stephen Smalley, SELinux-dev, selinux > > 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 16:25 ` Ivan Gyurdiev @ 2005-11-15 16:15 ` Joshua Brindle 2005-11-15 16:42 ` Ivan Gyurdiev 0 siblings, 1 reply; 26+ messages in thread From: Joshua Brindle @ 2005-11-15 16:15 UTC (permalink / raw) To: Ivan Gyurdiev; +Cc: Daniel J Walsh, Stephen Smalley, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 16:15 ` Joshua Brindle @ 2005-11-15 16:42 ` Ivan Gyurdiev 0 siblings, 0 replies; 26+ messages in thread From: Ivan Gyurdiev @ 2005-11-15 16:42 UTC (permalink / raw) To: Joshua Brindle; +Cc: Daniel J Walsh, Stephen Smalley, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 16:05 ` Ivan Gyurdiev 2005-11-15 15:59 ` Joshua Brindle @ 2005-11-15 16:05 ` Stephen Smalley 1 sibling, 0 replies; 26+ messages in thread From: Stephen Smalley @ 2005-11-15 16:05 UTC (permalink / raw) To: Ivan Gyurdiev; +Cc: Daniel J Walsh, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 11:58 ` Stephen Smalley 2005-11-15 13:38 ` Daniel J Walsh @ 2005-11-15 13:47 ` Stephen Smalley 2005-11-15 15:54 ` Ivan Gyurdiev 2 siblings, 0 replies; 26+ messages in thread From: Stephen Smalley @ 2005-11-15 13:47 UTC (permalink / raw) To: Ivan Gyurdiev; +Cc: Daniel J Walsh, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 11:58 ` Stephen Smalley 2005-11-15 13:38 ` Daniel J Walsh 2005-11-15 13:47 ` Stephen Smalley @ 2005-11-15 15:54 ` Ivan Gyurdiev 2005-11-15 15:55 ` Joshua Brindle 2005-11-16 0:58 ` Daniel J Walsh 2 siblings, 2 replies; 26+ messages in thread From: Ivan Gyurdiev @ 2005-11-15 15:54 UTC (permalink / raw) To: Stephen Smalley; +Cc: Daniel J Walsh, SELinux-dev, selinux > >> 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 15:54 ` Ivan Gyurdiev @ 2005-11-15 15:55 ` Joshua Brindle 2005-11-15 16:30 ` Ivan Gyurdiev 2005-11-16 1:01 ` Daniel J Walsh 2005-11-16 0:58 ` Daniel J Walsh 1 sibling, 2 replies; 26+ messages in thread From: Joshua Brindle @ 2005-11-15 15:55 UTC (permalink / raw) To: Ivan Gyurdiev; +Cc: Stephen Smalley, Daniel J Walsh, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 15:55 ` Joshua Brindle @ 2005-11-15 16:30 ` Ivan Gyurdiev 2005-11-16 1:01 ` Daniel J Walsh 1 sibling, 0 replies; 26+ messages in thread From: Ivan Gyurdiev @ 2005-11-15 16:30 UTC (permalink / raw) To: Joshua Brindle; +Cc: Stephen Smalley, Daniel J Walsh, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 15:55 ` Joshua Brindle 2005-11-15 16:30 ` Ivan Gyurdiev @ 2005-11-16 1:01 ` Daniel J Walsh 1 sibling, 0 replies; 26+ messages in thread From: Daniel J Walsh @ 2005-11-16 1:01 UTC (permalink / raw) To: Joshua Brindle; +Cc: Ivan Gyurdiev, Stephen Smalley, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [ SEMANAGE ] Stub pserver backend 2005-11-15 15:54 ` Ivan Gyurdiev 2005-11-15 15:55 ` Joshua Brindle @ 2005-11-16 0:58 ` Daniel J Walsh 1 sibling, 0 replies; 26+ messages in thread From: Daniel J Walsh @ 2005-11-16 0:58 UTC (permalink / raw) To: Ivan Gyurdiev; +Cc: Stephen Smalley, SELinux-dev, selinux 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2005-11-16 14:46 UTC | newest] Thread overview: 26+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-11-14 21:55 [ SEMANAGE ] Stub pserver backend Ivan Gyurdiev 2005-11-15 11:29 ` Stephen Smalley 2005-11-15 11:58 ` Stephen Smalley 2005-11-15 13:38 ` Daniel J Walsh 2005-11-15 14:12 ` Stephen Smalley 2005-11-15 14:25 ` Policy mods in last nights refpolicy Daniel J Walsh 2005-11-15 15:52 ` Christopher J. PeBenito 2005-11-16 0:55 ` Daniel J Walsh 2005-11-16 14:38 ` Christopher J. PeBenito 2005-11-16 13:48 ` Stephen Smalley 2005-11-16 14:18 ` Stephen Smalley 2005-11-16 14:46 ` Joshua Brindle 2005-11-15 14:38 ` [ SEMANAGE ] Stub pserver backend Daniel J Walsh 2005-11-15 16:02 ` Chad Sellers 2005-11-15 16:05 ` Ivan Gyurdiev 2005-11-15 15:59 ` Joshua Brindle 2005-11-15 16:25 ` Ivan Gyurdiev 2005-11-15 16:15 ` Joshua Brindle 2005-11-15 16:42 ` Ivan Gyurdiev 2005-11-15 16:05 ` Stephen Smalley 2005-11-15 13:47 ` Stephen Smalley 2005-11-15 15:54 ` Ivan Gyurdiev 2005-11-15 15:55 ` Joshua Brindle 2005-11-15 16:30 ` Ivan Gyurdiev 2005-11-16 1:01 ` Daniel J Walsh 2005-11-16 0:58 ` Daniel J Walsh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.