From rhally at mindspring.com Thu Jul 1 06:00:21 2004 From: rhally at mindspring.com (Richard Hally) Date: Thu, 01 Jul 2004 02:00:21 -0400 Subject: avc denied from postgresql In-Reply-To: <20040630114334.4ca86d5e.ynakam@hitachisoft.jp> References: <40CEBF5F.9020609@mindspring.com> <200406152253.00552.russell@coker.com.au> <40CFCD3E.8090400@mindspring.com> <20040630114334.4ca86d5e.ynakam@hitachisoft.jp> Message-ID: <40E3A875.6010403@mindspring.com> Yuichi Nakamura wrote: > On Wed, 16 Jun 2004 00:31:58 -0400 > Richard Hally wrote: > >>With the above change to the postgresql.fc I get the following avc >>denied messages when booting: > > You must add > /usr/bin/postgres -- system_u:object_r:postgresql_exec_t > to postgresql.fc > and , comment out > session optional /lib/security/$ISA/pam_selinux.so multiple > from /etc/pam.d/su. > Thanks for the reply, it looks to me that the problem is more like the policy and file_contexts were written for the way Debian(or some other distro) installs PostgresSQL and Fedora installs things differently. The most notable is that in the .fc it has the only postgresql_exec_t with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the executables are in /usr/bin. The question I have is: how do we handle these case where different distros put the same files in different places? Do we continue to add to the policy for each different distro? Richard Hally From dwalsh at redhat.com Thu Jul 1 11:39:05 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 01 Jul 2004 07:39:05 -0400 Subject: avc denied from postgresql In-Reply-To: <40E3A875.6010403@mindspring.com> References: <40CEBF5F.9020609@mindspring.com> <200406152253.00552.russell@coker.com.au> <40CFCD3E.8090400@mindspring.com> <20040630114334.4ca86d5e.ynakam@hitachisoft.jp> <40E3A875.6010403@mindspring.com> Message-ID: <40E3F7D9.4000403@redhat.com> Richard Hally wrote: > Yuichi Nakamura wrote: > >> On Wed, 16 Jun 2004 00:31:58 -0400 >> Richard Hally wrote: >> >>> With the above change to the postgresql.fc I get the following avc >>> denied messages when booting: >> >> >> You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t >> to postgresql.fc >> and , comment out session optional >> /lib/security/$ISA/pam_selinux.so multiple >> from /etc/pam.d/su. > > Thanks for the reply, it looks to me that the problem is more like the > policy and file_contexts were written for the way Debian(or some other > distro) installs PostgresSQL and Fedora installs things differently. > The most notable is that in the .fc it has the only postgresql_exec_t > with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the > executables are in /usr/bin. > The question I have is: how do we handle these case where different > distros put the same files in different places? Do we continue to add > to the policy for each different distro? Yes we put the stuff in both places. > > Richard Hally > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Thu Jul 1 11:52:09 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 01 Jul 2004 07:52:09 -0400 Subject: avc denied from postgresql In-Reply-To: <40E3A875.6010403@mindspring.com> References: <40CEBF5F.9020609@mindspring.com> <200406152253.00552.russell@coker.com.au> <40CFCD3E.8090400@mindspring.com> <20040630114334.4ca86d5e.ynakam@hitachisoft.jp> <40E3A875.6010403@mindspring.com> Message-ID: <40E3FAE9.1060202@redhat.com> Richard Hally wrote: > Yuichi Nakamura wrote: > >> On Wed, 16 Jun 2004 00:31:58 -0400 >> Richard Hally wrote: >> >>> With the above change to the postgresql.fc I get the following avc >>> denied messages when booting: >> >> >> You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t >> to postgresql.fc >> and , comment out session optional >> /lib/security/$ISA/pam_selinux.so multiple >> from /etc/pam.d/su. > > Thanks for the reply, it looks to me that the problem is more like the > policy and file_contexts were written for the way Debian(or some other > distro) installs PostgresSQL and Fedora installs things differently. > The most notable is that in the .fc it has the only postgresql_exec_t > with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the > executables are in /usr/bin. > The question I have is: how do we handle these case where different > distros put the same files in different places? Do we continue to add > to the policy for each different distro? > > Richard Hally > Added the following. Please check since I know nothing about postgresql. # # Files from postgresql # /usr/bin/clusterdb -- system_u:object_r:postgresql_exec_t /usr/bin/createdb -- system_u:object_r:postgresql_exec_t /usr/bin/createlang -- system_u:object_r:postgresql_exec_t /usr/bin/createuser -- system_u:object_r:postgresql_exec_t /usr/bin/dropdb -- system_u:object_r:postgresql_exec_t /usr/bin/droplang -- system_u:object_r:postgresql_exec_t /usr/bin/dropuser -- system_u:object_r:postgresql_exec_t /usr/bin/pg_dump -- system_u:object_r:postgresql_exec_t /usr/bin/pg_dumpall -- system_u:object_r:postgresql_exec_t /usr/bin/pg_encoding -- system_u:object_r:postgresql_exec_t /usr/bin/pg_id -- system_u:object_r:postgresql_exec_t /usr/bin/pg_restore -- system_u:object_r:postgresql_exec_t /usr/bin/psql -- system_u:object_r:postgresql_exec_t /usr/bin/vacuumdb -- system_u:object_r:postgresql_exec_t # # Files from postgresql-server # /usr/bin/initdb -- system_u:object_r:postgresql_exec_t /usr/bin/initlocation -- system_u:object_r:postgresql_exec_t /usr/bin/ipcclean -- system_u:object_r:postgresql_exec_t /usr/bin/pg_controldata -- system_u:object_r:postgresql_exec_t /usr/bin/pg_ctl -- system_u:object_r:postgresql_exec_t /usr/bin/pg_resetxlog -- system_u:object_r:postgresql_exec_t /usr/bin/postgres -- system_u:object_r:postgresql_exec_t /usr/bin/postmaster -- system_u:object_r:postgresql_exec_t > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From rhally at mindspring.com Thu Jul 1 12:15:01 2004 From: rhally at mindspring.com (Richard Hally) Date: Thu, 01 Jul 2004 08:15:01 -0400 Subject: avc denied from postgresql In-Reply-To: <40E3F7D9.4000403@redhat.com> References: <40CEBF5F.9020609@mindspring.com> <200406152253.00552.russell@coker.com.au> <40CFCD3E.8090400@mindspring.com> <20040630114334.4ca86d5e.ynakam@hitachisoft.jp> <40E3A875.6010403@mindspring.com> <40E3F7D9.4000403@redhat.com> Message-ID: <40E40045.7030209@mindspring.com> Daniel J Walsh wrote: > Richard Hally wrote: > >> Yuichi Nakamura wrote: >> >>> On Wed, 16 Jun 2004 00:31:58 -0400 >>> Richard Hally wrote: >>> >>>> With the above change to the postgresql.fc I get the following avc >>>> denied messages when booting: >>> >>> >>> >>> You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t >>> to postgresql.fc >>> and , comment out session optional >>> /lib/security/$ISA/pam_selinux.so multiple >>> from /etc/pam.d/su. >> >> >> Thanks for the reply, it looks to me that the problem is more like the >> policy and file_contexts were written for the way Debian(or some other >> distro) installs PostgresSQL and Fedora installs things differently. >> The most notable is that in the .fc it has the only postgresql_exec_t >> with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the >> executables are in /usr/bin. >> The question I have is: how do we handle these case where different >> distros put the same files in different places? Do we continue to add >> to the policy for each different distro? > > > Yes we put the stuff in both places. > I added the /usr/bin/postgres postgresql_exec_t file context (and relabeled) and it still would not start when booting. Below are the allow rules(generated by audit2allow) that were necessary to get the server to start. I did not comment out any pam_selinux.so line in /etc/pam.d/su. That doesn't seem like the right thing to do. Thanks, Richard Hally allow initrc_su_t postgresql_db_t:dir { search }; allow user_t postgresql_db_t:dir { add_name getattr read remove_name search write }; allow user_t postgresql_db_t:file { create getattr read rename unlink write }; From dwalsh at redhat.com Thu Jul 1 12:14:09 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 01 Jul 2004 08:14:09 -0400 Subject: fixfile.cron added. Message-ID: <40E40011.4080408@redhat.com> Todays policycoreutils has a new cron job, fixfiles.cron, that will run in /etc/cron.daily. This script will run a check on the file system on a daily basis looking for file contexts in the wrong state. It will them mail a list of files with the incorrect context to the root account. The following environment variables are set and can be overridden in the /etc/selinux/config directory. CRONTYPE="check" # You could change this to "restore" to have the script automatically clean up INVALIDFILE=/var/tmp/badcontext # Name of the file to store the badcontext file list CRONMAILTO="root" # Account to send mail to Suggestions on improvements? Comments? Dan From dwalsh at redhat.com Thu Jul 1 12:21:15 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 01 Jul 2004 08:21:15 -0400 Subject: avc denied from postgresql In-Reply-To: <40E40045.7030209@mindspring.com> References: <40CEBF5F.9020609@mindspring.com> <200406152253.00552.russell@coker.com.au> <40CFCD3E.8090400@mindspring.com> <20040630114334.4ca86d5e.ynakam@hitachisoft.jp> <40E3A875.6010403@mindspring.com> <40E3F7D9.4000403@redhat.com> <40E40045.7030209@mindspring.com> Message-ID: <40E401BB.7010100@redhat.com> Richard Hally wrote: > Daniel J Walsh wrote: > >> Richard Hally wrote: >> >>> Yuichi Nakamura wrote: >>> >>>> On Wed, 16 Jun 2004 00:31:58 -0400 >>>> Richard Hally wrote: >>>> >>>>> With the above change to the postgresql.fc I get the following avc >>>>> denied messages when booting: >>>> >>>> >>>> >>>> >>>> You must add /usr/bin/postgres -- >>>> system_u:object_r:postgresql_exec_t >>>> to postgresql.fc >>>> and , comment out session optional >>>> /lib/security/$ISA/pam_selinux.so multiple >>>> from /etc/pam.d/su. >>> >>> >>> >>> Thanks for the reply, it looks to me that the problem is more like >>> the policy and file_contexts were written for the way Debian(or some >>> other distro) installs PostgresSQL and Fedora installs things >>> differently. The most notable is that in the .fc it has the only >>> postgresql_exec_t with a regex for /usr/lib(64)?/postgresql/bin/.* >>> and on Fedora the executables are in /usr/bin. >>> The question I have is: how do we handle these case where different >>> distros put the same files in different places? Do we continue to >>> add to the policy for each different distro? >> >> >> >> Yes we put the stuff in both places. >> > I added the /usr/bin/postgres postgresql_exec_t file context (and > relabeled) and it still would not start when booting. Below are the > allow rules(generated by audit2allow) that were necessary to get the > server to start. I did not comment out any pam_selinux.so line in > /etc/pam.d/su. That doesn't seem like the right thing to do. > Thanks, > Richard Hally > > allow initrc_su_t postgresql_db_t:dir { search }; > allow user_t postgresql_db_t:dir { add_name getattr read remove_name > search write }; > allow user_t postgresql_db_t:file { create getattr read rename unlink > write }; You need to setup a server user that can transition to postgresql. A transition never happened. Dan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From himainu-ynakam at miomio.jp Thu Jul 1 12:37:47 2004 From: himainu-ynakam at miomio.jp (Yuichi Nakamura) Date: Thu, 01 Jul 2004 21:37:47 +0900 Subject: avc denied from postgresql In-Reply-To: <40E40045.7030209@mindspring.com> References: <40E40045.7030209@mindspring.com> Message-ID: <200407011237.i61Cbmle024358@mms-r00.iijmio.jp> The following is procedure to run postgresql on my Fedora Core2. (1) Add following to postgresql.te and postgresql.fc. I created new type "postgresql_dir_t" for default type of /var/lib/postgresql. # postgresql.te type postgresql_dir_t,file_type,sysadmfile; file_type_auto_trans(postgresql_t,postgresql_dir_t,postgresql_var_run_t) r_dir_file(postgresql_t,postgresql_dir_t) # postgresql.fc /usr/bin/postgres -- system_u:object_r:postgresql_exec_t /var/lib/pgsql(/.*)? system_u:object_r:postgresql_dir_t /var/lib/pgsql/data(/.*)+ system_u:object_r:postgresql_etc_t /var/lib/pgsql/data/postmaster.pid system_u:object_r:postgresql_var_run_t /var/lib/pgsql/data/base(/.*)? system_u:object_r:postgresql_db_t /var/lib/pgsql/data/global(/.*)? system_u:object_r:postgresql_db_t /var/lib/pgsql/data/pg_xlog(/.*)? system_u:object_r:postgresql_db_t /var/lib/pgsql/data/pg_clog(/.*)? system_u:object_r:postgresql_db_t /var/lib/pgsql/data/postmaster.opts system_u:object_r:postgresql_db_t /etc/sysconfig/pgsql(/.*)? system_u:object_r:postgresql_etc_t /usr/share/pgsql(/.*)? system_u:object_r:postgresql_etc_t /var/log/pgsql.* -- system_u:object_r:postgresql_log_t (2) reload and relabel # make reload relabel (3) comment out "session optional /lib/security/$ISA/pam_selinux.so multiple" from /etc/pam.d/su. Commenting out /etc/pam.d/su is necessary. Without it, postgreSQL(postmaster) will run as "user_t" domain, this domain is for user shell. user_t is not desireble for postgresql. (4) start postgreSQL #/etc/rc.d/init.d/postgresql start At first time to start postgresql, several new files will be created under /var/lib/pgsql/. (5) New files under /var/lib/pgsql do not have proper context, so stop postgreSQL and relabel /var/lib/pgsql. # /etc/rc.d/init.d/postgres stop # setfiles /etc/security/selinux/file_contexts /var/lib Next time you run postgresql, postgresql will run as "postgresql_t" correctly. Richard Hally wrote: > Daniel J Walsh wrote: > > > Richard Hally wrote: > > > >> Yuichi Nakamura wrote: > >> > >>> On Wed, 16 Jun 2004 00:31:58 -0400 > >>> Richard Hally wrote: > >>> > >>>> With the above change to the postgresql.fc I get the following avc > >>>> denied messages when booting: > >>> > >>> > >>> > >>> You must add /usr/bin/postgres -- system_u:object_r:postgresql_exec_t > >>> to postgresql.fc > >>> and , comment out session optional > >>> /lib/security/$ISA/pam_selinux.so multiple > >>> from /etc/pam.d/su. > >> > >> > >> Thanks for the reply, it looks to me that the problem is more like the > >> policy and file_contexts were written for the way Debian(or some other > >> distro) installs PostgresSQL and Fedora installs things differently. > >> The most notable is that in the .fc it has the only postgresql_exec_t > >> with a regex for /usr/lib(64)?/postgresql/bin/.* and on Fedora the > >> executables are in /usr/bin. > >> The question I have is: how do we handle these case where different > >> distros put the same files in different places? Do we continue to add > >> to the policy for each different distro? > > > > > > Yes we put the stuff in both places. > > > I added the /usr/bin/postgres postgresql_exec_t file context (and > relabeled) and it still would not start when booting. Below are the > allow rules(generated by audit2allow) that were necessary to get the > server to start. I did not comment out any pam_selinux.so line in > /etc/pam.d/su. That doesn't seem like the right thing to do. > Thanks, > Richard Hally > > allow initrc_su_t postgresql_db_t:dir { search }; > allow user_t postgresql_db_t:dir { add_name getattr read remove_name > search write }; > allow user_t postgresql_db_t:file { create getattr read rename unlink > write }; > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list --- Yuichi Nakamura Japan SELinux Users Group(JPSEG) http://www.selinux.gr.jp/ From aross at plusthree.com Thu Jul 1 13:51:13 2004 From: aross at plusthree.com (Aaron Ross) Date: Thu, 01 Jul 2004 09:51:13 -0400 Subject: logrotate errors Message-ID: <40E416D1.7030107@plusthree.com> Hi all, I am having some problems with logrotate on a box with selinux enabled. Here's my current sestatus: [root at customer bin]# /usr/sbin/sestatus -v SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Policy version: 17 Policy booleans: user_ping inactive Process contexts: Current context: root:sysadm_r:sysadm_t Init context: system_u:system_r:kernel_t /sbin/mingetty system_u:system_r:kernel_t /usr/sbin/sshd system_u:system_r:kernel_t File contexts: Controlling term: root:object_r:devpts_t /etc/passwd root:object_r:file_t /etc/shadow root:object_r:file_t And here is an example of the errors I'm seeing: error: error getting file context /usr/local/apache/logs/access_log: No data available I've read the FAQ and I'll keep going through the introductions to SELinux, but if I could get a quick explanation of what's going wrong, I would be very grateful. Thanks, Aaron From selinux at comcast.net Thu Jul 1 19:06:13 2004 From: selinux at comcast.net (Tom London) Date: Thu, 01 Jul 2004 12:06:13 -0700 Subject: graphical login problems with latest from development tree Message-ID: <40E460A5.1050804@comcast.net> The latest packages from the development tree leave me with the following situation: the system boots fine with no unusual messages/AVCs (in fact, the latest policy files seem to have some 'dontaudit' rules that quiet things down a bit). gdm starts, but after providing username/password, the effort fails with a message about session lasting 10 seconds or less. etc. and I'm back to the login screen. It works with 'enforcing=0', and interestingly, it also works with 'enforcing=1' if I ctrl-alt-F2, login text mode, su to root, and then 'gdm-restart'. The only difference I could detect is the contexts for /tmp/.ICE-unix (initrc_tmp_t vs. xdm_xserver_tmp_t) and .X11-unix (xdm_tmp_t vs. xdm_xserver_tmp_t). Known issue? tom From selinux at comcast.net Thu Jul 1 21:37:43 2004 From: selinux at comcast.net (Tom London) Date: Thu, 01 Jul 2004 14:37:43 -0700 Subject: graphical login problems with latest from development tree (solved) Message-ID: <40E48427.90407@comcast.net> OK. I think I figured this out. /etc/rc.sysinit now recreates /tmp/.ICE-unix on each boot. It appears that in doing so, it does not assign it the expected context, so it is 'defaulting' to system_u:object_r:initrc_tmp_t. If I boot up single user, do a 'restorecon -v /tmp/.ICE-unix' to assign it context system_u:object_r:xdm_xserver_tmp_t, and then an 'exit', the resulting graphical login works just fine. Looks like /etc/rc.sysinit needs to do a 'restorecon': [ -n "$SELINUX" ] && restorecon /tmp/.ICE-unix after creating it.... Bugzilla'ed here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127099 tom [If you decide to try manually edit /etc/rc.d/rc.sysinit to add the 'restorecon', make sure you do a 'restorecon /etc/rc.d/rc.sysinit' before rebooting. Otherwise, your system will not be happy. (In case that happens, reboot with 'enforcing=0' and do the 'restorecon /etc/rc.d/rc.sysinit')]. From russell at coker.com.au Fri Jul 2 07:48:57 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 2 Jul 2004 17:48:57 +1000 Subject: avc denied from postgresql In-Reply-To: <40E3FAE9.1060202@redhat.com> References: <40CEBF5F.9020609@mindspring.com> <40E3A875.6010403@mindspring.com> <40E3FAE9.1060202@redhat.com> Message-ID: <200407021748.57213.russell@coker.com.au> On Thu, 1 Jul 2004 21:52, Daniel J Walsh wrote: > Added the following. Please check since I know nothing about postgresql. I am not a postgresql expert either. However i think that some of these aren't needed. > # > # Files from postgresql > # > /usr/bin/clusterdb -- system_u:object_r:postgresql_exec_t > /usr/bin/createdb -- system_u:object_r:postgresql_exec_t > /usr/bin/createuser -- system_u:object_r:postgresql_exec_t > /usr/bin/dropdb -- system_u:object_r:postgresql_exec_t > /usr/bin/dropuser -- system_u:object_r:postgresql_exec_t > /usr/bin/psql -- system_u:object_r:postgresql_exec_t > /usr/bin/vacuumdb -- system_u:object_r:postgresql_exec_t The above are just wrappers for SQL commands. I don't think that there's any benefit in labelling them, and there may be some disadvantages for some of them (think of SQL scripts that need read/write access to files that the calling domain accesses). > /usr/bin/createlang -- system_u:object_r:postgresql_exec_t > /usr/bin/droplang -- system_u:object_r:postgresql_exec_t > /usr/bin/pg_encoding -- system_u:object_r:postgresql_exec_t > /usr/bin/pg_id -- system_u:object_r:postgresql_exec_t > /usr/bin/pg_restore -- system_u:object_r:postgresql_exec_t I am unsure about the above. Either the documentation or my understanding is lacking. > /usr/bin/pg_dump -- system_u:object_r:postgresql_exec_t > /usr/bin/pg_dumpall -- system_u:object_r:postgresql_exec_t The above definitely need labelling. > /usr/bin/initdb -- system_u:object_r:postgresql_exec_t initdb is just a shell script. Maybe it should be left unlabeled and just have transitions when it runs /usr/bin/postgres? > /usr/bin/ipcclean -- system_u:object_r:postgresql_exec_t This shell script refuses to run as root, probably doesn't need a special label. > /usr/bin/pg_controldata -- system_u:object_r:postgresql_exec_t Displays stuff from initdb. If initdb doesn't need it then it probably doesn't either. > /usr/bin/pg_ctl -- system_u:object_r:postgresql_exec_t Runs "postmaster" which is a symlink to "postgres", so it shouldn't need a label. > /usr/bin/pg_resetxlog -- system_u:object_r:postgresql_exec_t This one is not clear to me, but I think for the moment it should be labelled. > /usr/bin/postgres -- system_u:object_r:postgresql_exec_t Definately needs labelling. > /usr/bin/postmaster -- system_u:object_r:postgresql_exec_t No such file. Please try out the attached postgresql.fc file, I'm sure it will work at least as well as anything that anyone else has posted, and probably better than most. I'll review Yuichi's labelling ideas for the data directory later. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- # postgresql - ldap server /usr/lib(64)?/postgresql/bin/.* -- system_u:object_r:postgresql_exec_t /usr/bin/postgres -- system_u:object_r:postgresql_exec_t /usr/bin/pg_dump -- system_u:object_r:postgresql_exec_t /usr/bin/pg_dumpall -- system_u:object_r:postgresql_exec_t /usr/bin/pg_resetxlog -- system_u:object_r:postgresql_exec_t # not sure whether the following binaries need labelling /usr/bin/createlang -- system_u:object_r:postgresql_exec_t /usr/bin/droplang -- system_u:object_r:postgresql_exec_t /usr/bin/pg_encoding -- system_u:object_r:postgresql_exec_t /usr/bin/pg_id -- system_u:object_r:postgresql_exec_t /usr/bin/pg_restore -- system_u:object_r:postgresql_exec_t /var/lib/postgres(/.*)? system_u:object_r:postgresql_db_t /var/lib/pgsql(/.*)? system_u:object_r:postgresql_db_t /var/run/postgresql(/.*)? system_u:object_r:postgresql_var_run_t /etc/postgresql(/.*)? system_u:object_r:postgresql_etc_t /var/log/postgres\.log.* -- system_u:object_r:postgresql_log_t /var/log/postgresql(/.*)? system_u:object_r:postgresql_log_t From russell at coker.com.au Fri Jul 2 14:33:45 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 3 Jul 2004 00:33:45 +1000 Subject: avc denied from postgresql In-Reply-To: <200407011237.i61Cbmle024358@mms-r00.iijmio.jp> References: <40E40045.7030209@mindspring.com> <200407011237.i61Cbmle024358@mms-r00.iijmio.jp> Message-ID: <200407030033.45648.russell@coker.com.au> Let's get back to basics and look at the concepts rather than AVC messages. /etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, this is a problem as it's not compatible with the usual su operation. Changing su is not the right solution as we don't even need 1% of the functionality of su, all we need is a way to call setregid() and setreuid() before executing the script. I'm not sure if we already have a program we can use for this purpose (sudo is not suitable). For a test I spent 30 minutes writing a program that provides all of the su functionality we need for such things, we'll have to include that program if we don't have something better (we should have something better). /etc/rc.d/init.d/postgresql does lots of things other than just starting a daemon, for example the code after: echo -n $"Initializing database: " I tried labelling /etc/rc.d/init.d/postgresql as postgresql_exec_t, however the postgresql_t domain does not have access to write to the administrator console (and such access is not desired), it does not have access to rhgb_t, and there's some other things it needs access to. I think that perhaps the correct thing to do is to re-write /etc/rc.d/init.d/postgresql to call a separate script with type postgresql_exec_t to do the "Initializing database" thing. I'll look into that tomorrow. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From rhally at mindspring.com Fri Jul 2 23:39:02 2004 From: rhally at mindspring.com (Richard Hally) Date: Fri, 02 Jul 2004 19:39:02 -0400 Subject: avc denied from postgresql In-Reply-To: <200407030033.45648.russell@coker.com.au> References: <40E40045.7030209@mindspring.com> <200407011237.i61Cbmle024358@mms-r00.iijmio.jp> <200407030033.45648.russell@coker.com.au> Message-ID: <40E5F216.8080005@mindspring.com> Russell Coker wrote: > Let's get back to basics and look at the concepts rather than AVC messages. > > /etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, this is > a problem as it's not compatible with the usual su operation. Huh? su (Substitute User) has been to "Change the effective userid and group id" since I first learned about it in 1978. And is being used for that purpose in the init.d/postgresql stript. > Changing su is > not the right solution Agree. Perhaps we need to look at pam_selinux again rather than trying to change the init.d/postgresql script? as we don't even need 1% of the functionality of su, > all we need is a way to call setregid() and setreuid() before executing the > script. I'm not sure if we already have a program we can use for this > purpose (sudo is not suitable). For a test I spent 30 minutes writing a > program that provides all of the su functionality we need for such things, > we'll have to include that program if we don't have something better (we > should have something better). > > /etc/rc.d/init.d/postgresql does lots of things other than just starting a > daemon, for example the code after: > echo -n $"Initializing database: " Maybe we need a restorecon where it creates the data directory(if not already present (a rare occurance)). The real work part of initializing the data directory is done with "su -l postgres -c ..." just like the part that starts the server(i.e. su -l postgres -c ...) What is it about pam_selinux that is causing the problem? With your latest changes to postgresql.fc and a couple of allow rules, the server starts in the correct context when booting if the pam_selinux line is commented out of pam.d/su. That would indicate to me that there is something about pam_selinux that is the problem. The error message is: "Unable to get valid context for postgres, no valid tty" Perhaps the problem has to do with the 'no valid tty' part? Thanks for your help, Richard Hally From fritz.elfert at millenux.com Sat Jul 3 01:17:54 2004 From: fritz.elfert at millenux.com (Fritz Elfert) Date: Sat, 3 Jul 2004 03:17:54 +0200 Subject: building rpms with custom contexts Message-ID: <200407030317.54765.fritz.elfert@millenux.com> Hi, I want to build several rpms for Fedora Core 2 which should install/use some custom domains/file-contexts. Is there any doc or how-to for this. Do i have to load the custom policy on the build-machine at build-time or is there something similar like the %attr(...) macro for setting file-contexts in the %files section of a spec? How are new policies installed _without_ having policy-sources installed on the target machine? Thanks for any hint -Fritz From russell at coker.com.au Sat Jul 3 06:52:43 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 3 Jul 2004 16:52:43 +1000 Subject: avc denied from postgresql In-Reply-To: <40E5F216.8080005@mindspring.com> References: <40E40045.7030209@mindspring.com> <200407030033.45648.russell@coker.com.au> <40E5F216.8080005@mindspring.com> Message-ID: <200407031652.43609.russell@coker.com.au> On Sat, 3 Jul 2004 09:39, Richard Hally wrote: > Russell Coker wrote: > > Let's get back to basics and look at the concepts rather than AVC > > messages. > > > > /etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, > > this is a problem as it's not compatible with the usual su operation. > > Huh? su (Substitute User) has been to "Change the effective userid and > group id" since I first learned about it in 1978. And is being used for > that purpose in the init.d/postgresql stript. It's purpose is to change the effective UID/GID for interactive sessions. >From su(1) on Fedora: su - run a shell with substitute user and group IDs >From su(1) on Debian: su is used to become another user during a login session. There's no mention I could find in the documentation of using su for starting daemons. I think that there is no good reason for using su in this manner, and some good reasons for not doing so. The postgresql start scripts will have to be changed. > > /etc/rc.d/init.d/postgresql does lots of things other than just starting > > a daemon, for example the code after: > > echo -n $"Initializing database: " > > Maybe we need a restorecon where it creates the data directory(if not > already present (a rare occurance)). It might be rare in terms of the number of times the daemon is started, but from my understanding of the script it's expected to be done the first time the daemon is started. So it's inevitable that it happens at least once, and therefore we have to handle it. > The real work part of initializing the data directory is done with "su > -l postgres -c ..." just like the part that starts the server(i.e. su -l > postgres -c ...) > > What is it about pam_selinux that is causing the problem? The fact that there is no identity, role, and domain defined for Postgres. We can configure the SE Linux policy to allow this, but it's the wrong approach. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From rhally at mindspring.com Sat Jul 3 06:53:59 2004 From: rhally at mindspring.com (Richard Hally) Date: Sat, 03 Jul 2004 02:53:59 -0400 Subject: avc denied from postgresql In-Reply-To: <200407030033.45648.russell@coker.com.au> References: <40E40045.7030209@mindspring.com> <200407011237.i61Cbmle024358@mms-r00.iijmio.jp> <200407030033.45648.russell@coker.com.au> Message-ID: <40E65807.5040909@mindspring.com> Russell Coker wrote: > Let's get back to basics and look at the concepts rather than AVC messages. > Another way of looking at the problem is that with the three allow rules below the server *will* start but it has a context of user_u:user_r:user_t. When it is started without the pam_selinux line in pam.d/su, the context is system_u:system_r:postgresql_t. >Dan Walsh said: >You need to setup a server user that can transition to postgresql. A >transition never happened. >Dan Here are the three allow rules: allow initrc_su_t postgresql_db_t:dir { search }; allow user_t postgresql_db_t:dir { add_name getattr read remove_name search write }; allow user_t postgresql_db_t:file { create getattr read rename unlink write }; Thanks for the help, Richard Hally From rhally at mindspring.com Sat Jul 3 07:25:05 2004 From: rhally at mindspring.com (Richard Hally) Date: Sat, 03 Jul 2004 03:25:05 -0400 Subject: avc denied from postgresql In-Reply-To: <200407031652.43609.russell@coker.com.au> References: <40E40045.7030209@mindspring.com> <200407030033.45648.russell@coker.com.au> <40E5F216.8080005@mindspring.com> <200407031652.43609.russell@coker.com.au> Message-ID: <40E65F51.6000000@mindspring.com> Russell Coker wrote: > On Sat, 3 Jul 2004 09:39, Richard Hally wrote: > >>Russell Coker wrote: >> >>>Let's get back to basics and look at the concepts rather than AVC >>>messages. >>> >>>/etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, >>>this is a problem as it's not compatible with the usual su operation. >> >>Huh? su (Substitute User) has been to "Change the effective userid and >>group id" since I first learned about it in 1978. And is being used for >>that purpose in the init.d/postgresql stript. > > > It's purpose is to change the effective UID/GID for interactive sessions. > >>From su(1) on Fedora: > su - run a shell with substitute user and group IDs > >>From su(1) on Debian: > su is used to become another user during a login session. > > There's no mention I could find in the documentation of using su for starting > daemons. > > I think that there is no good reason for using su in this manner, and some > good reasons for not doing so. The postgresql start scripts will have to be > changed. > > >>>/etc/rc.d/init.d/postgresql does lots of things other than just starting >>>a daemon, for example the code after: >>>echo -n $"Initializing database: " >> >>Maybe we need a restorecon where it creates the data directory(if not >>already present (a rare occurance)). > > > It might be rare in terms of the number of times the daemon is started, but > from my understanding of the script it's expected to be done the first time > the daemon is started. So it's inevitable that it happens at least once, and > therefore we have to handle it. > > >>The real work part of initializing the data directory is done with "su >>-l postgres -c ..." just like the part that starts the server(i.e. su -l >>postgres -c ...) >> >>What is it about pam_selinux that is causing the problem? > > > The fact that there is no identity, role, and domain defined for Postgres. We > can configure the SE Linux policy to allow this, but it's the wrong approach. > Ok, now I understand making a distinction about using su for starting a deamon. What is the problem with defining a user role for postgres? And how would one go about doing that? TFTH Richard Hally From katzj at redhat.com Sat Jul 3 16:18:39 2004 From: katzj at redhat.com (Jeremy Katz) Date: Sat, 03 Jul 2004 12:18:39 -0400 Subject: fixfile.cron added. In-Reply-To: <40E40011.4080408@redhat.com> References: <40E40011.4080408@redhat.com> Message-ID: <1088871519.22067.33.camel@bree.local.net> On Thu, 2004-07-01 at 08:14 -0400, Daniel J Walsh wrote: > INVALIDFILE=/var/tmp/badcontext # Name of the file to store the > badcontext file list [snip] > Suggestions on improvements? Comments? This need to be mkstemp'd. Otherwise, you have a nice little race that I can use for causing all sorts of havoc :) Jeremy From gabor.t at invitel.hu Mon Jul 5 19:22:14 2004 From: gabor.t at invitel.hu (T) Date: Mon, 05 Jul 2004 21:22:14 +0200 Subject: X server error Message-ID: <1089055334.3385.1.camel@localhost.localdomain> XKB config activate error. ... Internal X server problem. X szerver verzi? adatok: The X.Org Foundation 60700000 [root at MainLinux root]# gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [hu,us] model = pc105 overrideSettings = false options = [] [root at MainLinux root]# [root at MainLinux root]# From h.mayer at inode.at Mon Jul 5 20:04:10 2004 From: h.mayer at inode.at (Hannes Mayer) Date: Mon, 05 Jul 2004 22:04:10 +0200 Subject: X server error In-Reply-To: <1089055334.3385.1.camel@localhost.localdomain> References: <1089055334.3385.1.camel@localhost.localdomain> Message-ID: <40E9B43A.5040404@inode.at> T wrote: > XKB config activate error. > ... Internal X server problem. > > > > X szerver verzi? adatok: > The X.Org Foundation > 60700000 > > [root at MainLinux root]# gconftool-2 -R > /desktop/gnome/peripherals/keyboard/xkb > layouts = [hu,us] > model = pc105 > overrideSettings = false > options = [] > [root at MainLinux root]# > [root at MainLinux root]# AFAIK that's not selinux related. Check your xorg.conf for the line Option "XkbRules" "xfree86" and change it to Option "XkbRules" "xorg" that should do the trick Cheers, Hannes. From ivg2 at cornell.edu Tue Jul 6 01:44:40 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 05 Jul 2004 19:44:40 -0600 Subject: fixfile.cron added. In-Reply-To: <40E40011.4080408@redhat.com> References: <40E40011.4080408@redhat.com> Message-ID: <1089078280.30565.2.camel@localhost.bluenet> > Suggestions on improvements? Comments? Just wondering why I have hundreds of denials from sysadm_crond_t in my system log with /usr/bin/setfiles in them. Latest policy, permissive mode. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivg2 at cornell.edu Tue Jul 6 01:50:02 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Mon, 05 Jul 2004 19:50:02 -0600 Subject: Tmpfs Message-ID: <1089078602.30620.3.camel@localhost.bluenet> What's the situation with tmpfs? I have /tmp on tmpfs and I get lots of denials. Tmpfs doesn't seem to support xattrs, however.. SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Is /tmp on tmpfs something that should work, or is this not supported? What about /dev on tmpfs (or /udev)? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From russell at coker.com.au Tue Jul 6 01:53:16 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 6 Jul 2004 11:53:16 +1000 Subject: Tmpfs In-Reply-To: <1089078602.30620.3.camel@localhost.bluenet> References: <1089078602.30620.3.camel@localhost.bluenet> Message-ID: <200407061153.16786.russell@coker.com.au> On Tue, 6 Jul 2004 11:50, Ivan Gyurdiev wrote: > What's the situation with tmpfs? I have /tmp on tmpfs and I get lots of > denials. Tmpfs doesn't seem to support xattrs, however.. > > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs > > Is /tmp on tmpfs something that should work, or is this not supported? > What about /dev on tmpfs (or /udev)? Making /dev on tmpfs should work. /tmp on tmpfs will not work properly because it's labelled as tmpfs_t (which is also used for SysV shared memory). See the following URL for more discussion of this issue: http://marc.theaimsgroup.com/?l=selinux&m=104438419029394&w=2 -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From Valdis.Kletnieks at vt.edu Mon Jul 5 19:51:49 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 05 Jul 2004 15:51:49 -0400 Subject: And another fixfiles comment... (was Re: fixfile.cron added. In-Reply-To: Your message of "Thu, 01 Jul 2004 08:14:09 EDT." <40E40011.4080408@redhat.com> References: <40E40011.4080408@redhat.com> Message-ID: <200407051951.i65Jpn6u020754@turing-police.cc.vt.edu> On Thu, 01 Jul 2004 08:14:09 EDT, Daniel J Walsh said: > Todays policycoreutils has a new cron job, fixfiles.cron, that will run > in /etc/cron.daily. This script will run a check on the file system on Currently, fixfiles does some interesting grepping through the mounts to only work on R/W mounts. This has 2 problems when run on a system that has many filesystems mounted with some combo of ro/nosuid/nodev/noexec: 1) It's possible for the sysadmin to not realize that fixfiles isn't relabelling a filesystem because it's R/O (note that this problem is shared by the 'make relabel' target in /etc/selinux/*/src/policy/Makefile). 2) If we're only checking, we should do R/O filesystems as well - the fact that they're R/O when the cronjob runs doesn't mean that they weren't R/W and picked up some bad labels at some previous time. Lightly tested patch: --- /sbin/fixfiles.dist 2004-06-30 13:40:47.000000000 -0400 +++ /sbin/fixfiles 2004-07-05 04:53:24.000000000 -0400 @@ -30,9 +30,12 @@ rpmFlag=0 rpmFiles="" outfileFlag=0 OUTFILES="" +logfileFlag=0 LOGFILE=`mktemp /var/tmp/fixfiles.XXXXXXXXXX` || exit 1 SETFILES=/usr/sbin/setfiles -FILESYSTEMS=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[23]| xfs | reiserfs ).*rw/{print $3}';` +FILESYSTEMSRW=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[23]| xfs | reiserfs ).*\(rw/{print $3}';` +FILESYSTEMSRO=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[23]| xfs | reiserfs ).*\(ro/{print $3}';` +FILESYSTEMS="$FILESYSTEMSRW $FILESYSTEMSRO" SELINUXTYPE="targeted" if [ -e /etc/selinux/config ]; then @@ -60,7 +63,11 @@ if [ ! -z "$1" ]; then rpm -q -l $i | restorecon ${OUTFILES} -v -f - 2>&1 | tee $LOGFILE done else - ${SETFILES} ${OUTFILES} ${OUTFILES} -v ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE + if [ "x$FILESYSTEMSRO" != "x" ]; then + echo "Warning: Skipping the following R/O filesystems:" + echo "$FILESYSTEMSRO" + fi + ${SETFILES} ${OUTFILES} ${OUTFILES} -v ${FC} ${FILESYSTEMSRW} 2>&1 | tee $LOGFILE fi } @@ -73,7 +80,11 @@ if [ ! -z "$1" ]; then rpm -q -l $i | restorecon ${OUTFILES} -v -f - 2>&1 | tee $LOGFILE done else - ${SETFILES} ${OUTFILES} -v ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE + if [ "x$FILESYSTEMSRO" != "x" ]; then + echo "Warning: Skipping the following R/O filesystems:" + echo "$FILESYSTEMSRO" + fi + ${SETFILES} ${OUTFILES} -v ${FC} ${FILESYSTEMSRW} 2>&1 | tee $LOGFILE fi } relabelCheck() { -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Sat Jul 3 18:12:16 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 03 Jul 2004 14:12:16 -0400 Subject: More /sbin/fixfiles oddities (was Re: fixfile.cron added. In-Reply-To: Your message of "Thu, 01 Jul 2004 08:14:09 EDT." <40E40011.4080408@redhat.com> References: <40E40011.4080408@redhat.com> Message-ID: <200407031812.i63ICIQn030959@turing-police.cc.vt.edu> On Thu, 01 Jul 2004 08:14:09 EDT, Daniel J Walsh said: > Todays policycoreutils has a new cron job, fixfiles.cron, that will run > in /etc/cron.daily. This script will run a check on the file system on > Suggestions on improvements? Comments? 1) /sbin/fixfiles ends up spewing to a logfile whether we want it or not: logging to /var/tmp/fixfiles.byapo27529 and then it does a '| tee $LOGFILE'. And after a few days, we have: ls -l /var/tmp/fix* -rw------- 1 root root 0 Jun 15 21:47 /var/tmp/fixfiles.FjBnJn1029 -rw------- 1 root root 3079 Jul 2 10:27 /var/tmp/fixfiles.SlZmt16952 -rw------- 1 root root 17899 Jul 3 04:20 /var/tmp/fixfiles.WBgGN24978 -rw------- 1 root root 0 Jul 3 13:48 /var/tmp/fixfiles.byapo27529 -rw------- 1 root root 0 Jun 15 21:49 /var/tmp/fixfiles.ffmJNN1054 -rw------- 1 root root 0 Jun 15 21:47 /var/tmp/fixfiles.xpFMrd1036 This wouldn't be so bad, if it was possible to get fixfiles.cron to pass a '-l /dev/null' to /sbin/fixfiles or some other way to tell /sbin/fixfiles that no, you didn't want a copy saved in a file (because cron will save a copy, or you did a tee yourself, or....) 2) I can't convince myself that the following lines in /sbin/fixfiles are right: restoreLabels () { echo "logging to $LOGFILE" if [ ! -z "$1" ]; then for i in `echo $1 | sed 's/,/ /g'`; do rpm -q -l $i | restorecon ${OUTFILES} -v -f - 2>&1 | tee $LOGFILE done else ${SETFILES} ${OUTFILES} ${OUTFILES} -v ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE fi } $OUTFILES *twice*? 3) fixfiles didn't exhibit the 86K badcontexts issue when running from a shell that had context=root:sysadm_r:sysadm_t. I'm wondering if it got an odd context from cron which confused it. Film at 11 (or 4AM, really)..I added a call to /usr/bin/id to /sbin/fixfiles so I find out... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Sat Jul 3 17:47:03 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 03 Jul 2004 13:47:03 -0400 Subject: /sbin/fixfiles bug (was Re: fixfile.cron added. In-Reply-To: Your message of "Thu, 01 Jul 2004 08:14:09 EDT." <40E40011.4080408@redhat.com> References: <40E40011.4080408@redhat.com> Message-ID: <200407031747.i63Hl5hZ014360@turing-police.cc.vt.edu> On Thu, 01 Jul 2004 08:14:09 EDT, Daniel J Walsh said: > Todays policycoreutils has a new cron job, fixfiles.cron, that will run > in /etc/cron.daily. This script will run a check on the file system on > Suggestions on improvements? Comments? (I'd bugzilla this but I'm offline as I write this) FC2 devel tree, with policycoreutils-1.14.1-1 The cronjob tosses a few error messages due to a fixfiles bug: /etc/cron.daily/fixfiles.cron: /sbin/fixfiles: line 111: [: =: unary operator expected /sbin/fixfiles: line 111: [: =: unary operator expected logging to /var/tmp/fixfiles.WBgGN24978 Patch follows: % diff -up /sbin/fixfiles.dist /sbin/fixfiles --- /sbin/fixfiles.dist 2004-06-30 13:40:47.000000000 -0400 +++ /sbin/fixfiles 2004-07-03 13:22:59.403549435 -0400 @@ -30,6 +30,7 @@ rpmFlag=0 rpmFiles="" outfileFlag=0 OUTFILES="" +logfileFlag=0 LOGFILE=`mktemp /var/tmp/fixfiles.XXXXXXXXXX` || exit 1 SETFILES=/usr/sbin/setfiles FILESYSTEMS=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[23]| xfs | reiserfs ).*rw/{print $3}';` I also need to figure out why /var/tmp/badcontexts seems to be totally broken. In the run-parts output, setfiles says for /var: /usr/sbin/setfiles: labeling files under /var /usr/sbin/setfiles: relabeling /var/lib/scrollkeeper/TOC/464 from root:object_r:rpm_var_lib_t to system_u:object_r:var_lib_t /usr/sbin/setfiles: relabeling /var/lib/scrollkeeper/index/464 from root:object_r:rpm_var_lib_t to system_u:object_r:var_lib_t /usr/sbin/setfiles: relabeling /var/run/lpd.515 from system_u:object_r:lpd_var_run_t to system_u:object_r:var_run_t /usr/sbin/setfiles: relabeling /var/run/lprng from system_u:object_r:var_run_t to system_u:object_r:lpd_var_run_t /usr/sbin/setfiles: hash table stats: 1264 elements, 1264/65536 buckets used, longest chain len OK... So I have 4 files with context issues on /var (which is an issue in and of itself, but not the point here. badfilecontexts however contains: /var/lib/rpm/__db.001 /var/lib/rpm/__db.002 /var/lib/rpm/__db.003 /var/lib/alternatives/print /var/lib/scrollkeeper/TOC/495 /var/lib/scrollkeeper/TOC/496 /var/lib/scrollkeeper/TOC/497 /var/lib/scrollkeeper/TOC/498 /var/lib/scrollkeeper/TOC/499 <> /var/lib/scrollkeeper/TOC/528 /var/lib/scrollkeeper/TOC/529 /var/lib/scrollkeeper/TOC/464 /var/lib/scrollkeeper/index/495 /var/lib/scrollkeeper/index/496 /var/lib/scrollkeeper/index/497 > /var/lib/scrollkeeper/index/529 /var/lib/scrollkeeper/index/464 /var/lib/scrollkeeper/scrollkeeper_docs /var/lib/texmf/ls-R /var/cache/man/cat8/grub-install.8.bz2 /var/cache/man/cat8/acpid.8.bz2 /var/lock/subsys/psacct /var/lock/rpm/transaction /var/run/lpd.515 /var/run/lprng Total output of the relabelling is about 150 lines, but /var/tmp/badcontexts is 86,978 lines, many of which make no sense at all (for instance, it flagged apparently every single file in my Linux kernel source trees for no apparent reason - consider the following spot check: # egrep 'linux[^/]*/Makefile$' /var/tmp/badcontext /usr/src/linux-2.6.7-mm4/Makefile /usr/src/linux-2.6.7-mm5/security/selinux/Makefile /usr/src/linux-2.6.7-mm5/Makefile /usr/src/linux-2.6.7-mm3/Makefile # ls -l --context /usr/src/linux-2.6.7-mm[345]/Makefile /usr/src/linux-2.6.7-mm5/security/selinux/Makefile -rw-r--r-- valdis valdis system_u:object_r:src_t /usr/src/linux-2.6.7-mm3/Makefile -rw-r--r-- valdis valdis system_u:object_r:src_t /usr/src/linux-2.6.7-mm4/Makefile -rw-r--r-- valdis valdis system_u:object_r:src_t /usr/src/linux-2.6.7-mm5/Makefile -rw-r--r-- valdis valdis system_u:object_r:src_t /usr/src/linux-2.6.7-mm5/security/selinux/Makefile When actually relabelling, fixfiles doesn't see anything wrong with these 4 Makefiles... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From miremadi at ce.sharif.edu Wed Jul 7 04:49:44 2004 From: miremadi at ce.sharif.edu (miremadi at ce.sharif.edu) Date: Wed, 7 Jul 2004 09:19:44 +0430 (IRDT) Subject: LSM program! Message-ID: <2256.81.31.164.46.1089175784.squirrel@ce.sharif.edu> Hi, Does anybody have an LSM program(with the source code)? And has anybody written a policy for the LSM? I mean codes that are not available in the kernel(those that are not default). thanx, From sds at epoch.ncsc.mil Wed Jul 7 15:59:48 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 07 Jul 2004 11:59:48 -0400 Subject: RFE: show change of enforcing state in log ? In-Reply-To: <40E1EECD.3040904@comcast.net> References: <40E1EECD.3040904@comcast.net> Message-ID: <1089215988.1774.77.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2004-06-29 at 18:35, Tom London wrote: > How difficult would it be to add 'old state->new state' to the log on a > change in > the enforcing state? Currently, 'setenforce' appears to be logged as a > toggle.... The kernel just audits the permission check, i.e. that setenforce permission was checked due to a change to the enforcing status. One could add an additional auxiliary audit data type to avc_audit_data and change the caller to supply the old and new states, but that would require a patch to the SELinux kernel module, and I'm not sure it is worthwhile. You can already have userspace receive notifications of enforcing status changes, including the new value via netlink socket messages; the userspace AVC in libselinux does this to detect changes in permissive/enforcing status. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Wed Jul 7 16:16:25 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 07 Jul 2004 12:16:25 -0400 Subject: logrotate errors In-Reply-To: <40E416D1.7030107@plusthree.com> References: <40E416D1.7030107@plusthree.com> Message-ID: <1089216985.1774.95.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-01 at 09:51, Aaron Ross wrote: > Process contexts: > Current context: root:sysadm_r:sysadm_t > Init context: system_u:system_r:kernel_t > /sbin/mingetty system_u:system_r:kernel_t > /usr/sbin/sshd system_u:system_r:kernel_t > > File contexts: > Controlling term: root:object_r:devpts_t > /etc/passwd root:object_r:file_t > /etc/shadow root:object_r:file_t This means that you haven't labeled your filesystems. Run 'fixfiles relabel' and reboot. > And here is an example of the errors I'm seeing: > > error: error getting file context /usr/local/apache/logs/access_log: No > data available The file has no security context assigned, so logrotate is unable to get the context of the log prior to rotation in order to preserve it. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Wed Jul 7 16:29:27 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 07 Jul 2004 12:29:27 -0400 Subject: fixfile.cron added. In-Reply-To: <40E40011.4080408@redhat.com> References: <40E40011.4080408@redhat.com> Message-ID: <1089217767.1774.109.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-01 at 08:14, Daniel J Walsh wrote: > Todays policycoreutils has a new cron job, fixfiles.cron, that will run > in /etc/cron.daily. This script will run a check on the file system on > a daily basis looking for file contexts in the wrong state. It will > them mail a list of files with the incorrect context to the root account. > > The following environment variables are set and can be overridden in the > /etc/selinux/config directory. > > CRONTYPE="check" # You could change this to "restore" to have the > script automatically clean up > INVALIDFILE=/var/tmp/badcontext # Name of the file to store the > badcontext file list > CRONMAILTO="root" # Account to send mail to > > Suggestions on improvements? Comments? Has the policy been adjusted to allow this to run? Is it being run in system_crond_t (I would assume, given that it is under /etc/cron.daily) or sysadm_crond_t (should only be applied to /var/spool/cron/root)? -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Wed Jul 7 17:01:56 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 07 Jul 2004 13:01:56 -0400 Subject: avc denied from postgresql In-Reply-To: <200407030033.45648.russell@coker.com.au> References: <40E40045.7030209@mindspring.com> <200407011237.i61Cbmle024358@mms-r00.iijmio.jp> <200407030033.45648.russell@coker.com.au> Message-ID: <1089219716.1774.121.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-07-02 at 10:33, Russell Coker wrote: > Let's get back to basics and look at the concepts rather than AVC messages. > > /etc/rc.d/init.d/postgresql uses su to change uid to start the daemon, this is > a problem as it's not compatible with the usual su operation. Changing su is > not the right solution as we don't even need 1% of the functionality of su, > all we need is a way to call setregid() and setreuid() before executing the > script. I'm not sure if we already have a program we can use for this > purpose (sudo is not suitable). The daemon() macro in /etc/init.d/functions includes a --user option that causes it to run the command via su in the specified user identity (su -s /bin/bash - $user -c ...). So it appears that this is not an uncommon/unexpected practice for running daemons in a non-root uid without requiring a separate wrapper program. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Wed Jul 7 17:08:15 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 07 Jul 2004 13:08:15 -0400 Subject: avc denied from postgresql In-Reply-To: <40E5F216.8080005@mindspring.com> References: <40E40045.7030209@mindspring.com> <200407011237.i61Cbmle024358@mms-r00.iijmio.jp> <200407030033.45648.russell@coker.com.au> <40E5F216.8080005@mindspring.com> Message-ID: <1089220095.1774.126.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-07-02 at 19:39, Richard Hally wrote: > Perhaps we need to look at pam_selinux again rather than trying to > change the init.d/postgresql script? > What is it about pam_selinux that is causing the problem? > With your latest changes to postgresql.fc and a couple of allow rules, > the server starts in the correct context when booting if the pam_selinux > line is commented out of pam.d/su. That would indicate to me that there > is something about pam_selinux that is the problem. The error message is: > "Unable to get valid context for postgres, no valid tty" > Perhaps the problem has to do with the 'no valid tty' part? pam_selinux is merely asking for a reachable security context for the new user identity from the current security context. The problem is that the SELinux policy has no user identities for these pseudo users, and it isn't clear that we truly want to go down the path of adding them (as has been done for some users in the policy/serviceusers files). -- Stephen Smalley National Security Agency From selinux at comcast.net Wed Jul 7 18:23:02 2004 From: selinux at comcast.net (Tom London) Date: Wed, 07 Jul 2004 11:23:02 -0700 Subject: vi does not maintain contexts on symlinks Message-ID: <40EC3F86.5000208@comcast.net> After accidentally editing '/etc/rc.sysinit' (a symlink to '/etc/rc.d/rc.sysinit') and getting a system that didn't boot in enforcing mode, I poked around a bit. It appears that the selinix patch to vi (emacs, ... ?) to maintain contexts across edits doesn't work if you point at the symlink instead of the 'real' file. [More precisely there is a function 'mch_copy_sec()' that calls get-/set-filecon(), but it appears that in the 'backup file' case, from_file and to_file are 'reversed'.] In my case, editing '/etc/rc.sysinit' changed the context of '/etc/rc.d/rc.sysinit' from 'system_u:object_r:initrc_exec_t' to 'root:object_r:etc_t'. I've bugzilla'ed this against vim here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127361 but this may affect more than vim (e.g., emacs, ...) Is this patch Fedora based, or is there an upstream source? Am I breaking something else? tom From selinux at comcast.net Wed Jul 7 18:55:52 2004 From: selinux at comcast.net (Tom London) Date: Wed, 07 Jul 2004 11:55:52 -0700 Subject: RFE: show change of enforcing state in log ? Message-ID: <40EC4738.1080201@comcast.net> Interesting.... I was actually trying address a (slightly) different issue: how to recreate, after the fact, as much of the state as possible from the log. Can certainly add to the user space code to detect this change, and then emit a message to the log. Prior to your suggestion, I looked at the code for selinuxfs.c. I think a one line change could also do the trick: (I modeled this after the log prints on a policy load) *************** *** 135,140 **** --- 135,143 ---- length = task_has_security(current, SECURITY__SETENFORCE); if (length) goto out; + printk(KERN_INFO "setenforce: %s->%s\n", + (selinux_enforcing ? "enforcing" : "permissive"), + (new_value ? "enforcing" : "permissive")); selinux_enforcing = new_value; if (selinux_enforcing) avc_ss_reset(0); tom > ------------------------------------------------------------------------ > > * /From/: Stephen Smalley > > ------------------------------------------------------------------------ > >On Tue, 2004-06-29 at 18:35, Tom London wrote: >> How difficult would it be to add 'old state->new state' to the log on a >> change in >> the enforcing state? Currently, 'setenforce' appears to be logged as a >> toggle.... > >The kernel just audits the permission check, i.e. that setenforce >permission was checked due to a change to the enforcing status. One >could add an additional auxiliary audit data type to avc_audit_data and >change the caller to supply the old and new states, but that would >require a patch to the SELinux kernel module, and I'm not sure it is >worthwhile. You can already have userspace receive notifications of >enforcing status changes, including the new value via netlink socket >messages; the userspace AVC in libselinux does this to detect changes in >permissive/enforcing status. > >-- >Stephen Smalley >National Security Agency > > > From sds at epoch.ncsc.mil Wed Jul 7 19:01:10 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 07 Jul 2004 15:01:10 -0400 Subject: RFE: show change of enforcing state in log ? In-Reply-To: <40EC4738.1080201@comcast.net> References: <40EC4738.1080201@comcast.net> Message-ID: <1089226870.1774.198.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-07-07 at 14:55, Tom London wrote: > Interesting.... > > I was actually trying address a (slightly) different issue: how to > recreate, after the fact, as much of the state as possible > from the log. Can certainly add to the user space code > to detect this change, and then emit a message to the log. > > Prior to your suggestion, I looked at the code for selinuxfs.c. > I think a one line change could also do the trick: > (I modeled this after the log prints on a policy load) > > *************** > *** 135,140 **** > --- 135,143 ---- > length = task_has_security(current, SECURITY__SETENFORCE); > if (length) > goto out; > + printk(KERN_INFO "setenforce: %s->%s\n", > + (selinux_enforcing ? "enforcing" : "permissive"), > + (new_value ? "enforcing" : "permissive")); > selinux_enforcing = new_value; > if (selinux_enforcing) > avc_ss_reset(0); Yes, that works as well, although I'd advise using audit_log(current->audit_context, "setenforce: %s->%s", ...) rather than printk, so that you use the audit framework rather than the normal kernel logging framework. That allows for the messages to be routed to a separate audit daemon and processed differently. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Wed Jul 7 19:04:02 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 07 Jul 2004 15:04:02 -0400 Subject: fixfile.cron added. In-Reply-To: <1089078280.30565.2.camel@localhost.bluenet> References: <40E40011.4080408@redhat.com> <1089078280.30565.2.camel@localhost.bluenet> Message-ID: <1089227042.1774.200.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-07-05 at 21:44, Ivan Gyurdiev wrote: > > Suggestions on improvements? Comments? > > Just wondering why I have hundreds of denials > from sysadm_crond_t in my system log with /usr/bin/setfiles in them. > > Latest policy, permissive mode. sysadm_crond_t or system_crond_t? -- Stephen Smalley National Security Agency From kvogelsa at ccs.neu.edu Wed Jul 7 19:38:32 2004 From: kvogelsa at ccs.neu.edu (Kirk Vogelsang) Date: Wed, 7 Jul 2004 15:38:32 -0400 (EDT) Subject: Upgrading to policy-strict RPM's Message-ID: I've got slimmed down Fedora Core2 that doesn't seem to want to enable selinux after rpm -U'ing the following packages: policycoreutils-1.14.1-1 selinux-policy-strict-1.14.1-2 libselinux-1.14.1-1 After upgrading to those packages, booting to single user, running fixfiles relabel, and rebooting once more, the system comes up selinux disabled. I've verified /etc/selinux/config SELINUX=permissive and SELINUXTYPE=strict. /etc/sysconfig/selinux sym-links to /etc/selinux/config. Policy resides in /etc/selinux/strict/policy/. Stock FC2 kernel, 2.6.5-1.358smp. I've tried appending selinux in grub as well, to no avail. What minute detail am I missing? ----- Kirk M. Vogelsang Northeastern University College of Computer Science From sds at epoch.ncsc.mil Wed Jul 7 19:42:06 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 07 Jul 2004 15:42:06 -0400 Subject: Tmpfs In-Reply-To: <1089078602.30620.3.camel@localhost.bluenet> References: <1089078602.30620.3.camel@localhost.bluenet> Message-ID: <1089229326.1774.242.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-07-05 at 21:50, Ivan Gyurdiev wrote: > What's the situation with tmpfs? I have /tmp on tmpfs and I get lots of > denials. Tmpfs doesn't seem to support xattrs, however.. > > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs > SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs > > Is /tmp on tmpfs something that should work, or is this not supported? > What about /dev on tmpfs (or /udev)? tmpfs lacks a fake xattr handler at present, unlike devpts, so userspace cannot get or set contexts on tmpfs. However, transition SIDs should be fine for tmp file creation in most cases, but this requires policy changes, and introduces a problem if you want to be able to distinguish the tmpfs mount used for shared memory from your /tmp tmpfs mount. You can use the context= mount option to assign a single context for a given mount and override the default behavior, but that doesn't really help here. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Wed Jul 7 19:49:49 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 07 Jul 2004 15:49:49 -0400 Subject: Upgrading to policy-strict RPM's In-Reply-To: References: Message-ID: <1089229788.1774.250.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-07-07 at 15:38, Kirk Vogelsang wrote: > I've got slimmed down Fedora Core2 that doesn't seem to want to > enable selinux after rpm -U'ing the following packages: > > policycoreutils-1.14.1-1 > selinux-policy-strict-1.14.1-2 > libselinux-1.14.1-1 > > After upgrading to those packages, booting to single user, > running fixfiles relabel, and rebooting once more, the system > comes up selinux disabled. I've verified /etc/selinux/config > SELINUX=permissive and SELINUXTYPE=strict. /etc/sysconfig/selinux > sym-links to /etc/selinux/config. Policy resides in > /etc/selinux/strict/policy/. Stock FC2 kernel, 2.6.5-1.358smp. > I've tried appending selinux in grub as well, to no avail. > > What minute detail am I missing? Update to the latest SysVinit package from the development tree. There are also other relevant packages, e.g. usermode. -- Stephen Smalley National Security Agency From kmacmillan at tresys.com Wed Jul 7 21:16:10 2004 From: kmacmillan at tresys.com (Karl MacMillan) Date: Wed, 7 Jul 2004 17:16:10 -0400 Subject: [ANN] setools 1.4.1 release Message-ID: <200407072116.i67LGASf001842@gotham.columbia.tresys.com> Setools version 1.4.1 has been released. It is available from the Tresys webpage at http://www.tresys.com/selinux/ or the SELinux CVS repository on sourceforge. This is a minor bug fix release. The changes include: - Support for version 18 policies. - A fix for a time zone related bug in seaudit. - The addition of the makefile target 'install-dev' that installs the libraries and headers necessary for third party developers to use the setools libraries (libapol, libseuser, libseaudit). Karl MacMillan Tresys Technology http://www.tresys.com (410)290-1411 ext 134 From russell at coker.com.au Thu Jul 8 02:46:13 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 8 Jul 2004 12:46:13 +1000 Subject: /sbin/fixfiles bug (was Re: fixfile.cron added. In-Reply-To: <200407031747.i63Hl5hZ014360@turing-police.cc.vt.edu> References: <40E40011.4080408@redhat.com> <200407031747.i63Hl5hZ014360@turing-police.cc.vt.edu> Message-ID: <200407081246.13401.russell@coker.com.au> On Sun, 4 Jul 2004 03:47, Valdis.Kletnieks at vt.edu wrote: > /usr/sbin/setfiles: labeling files under /var > /usr/sbin/setfiles: relabeling /var/lib/scrollkeeper/TOC/464 from > root:object_r:rpm_var_lib_t to system_u:object_r:var_lib_t > /usr/sbin/setfiles: relabeling /var/lib/scrollkeeper/index/464 from > root:object_r:rpm_var_lib_t to system_u:object_r:var_lib_t It seems that rpm_var_lib_t doesn't differ much in access from var_lib_t. I think that it would be appropriate to remove the line var_lib_domain(rpm) and allow the rpm files in question to have type var_lib_t. Dan, what do you think? Of course we have another problem in that rpm_t should not be creating such files, the script which does so should run as rpm_script_t. > /usr/sbin/setfiles: relabeling /var/run/lpd.515 from > system_u:object_r:lpd_var_run_t to system_u:object_r:var_run_t What is this lpd.515 file? Is that always the name for it? We need to get a matching entry in lpd.fc. > /usr/sbin/setfiles: relabeling /var/run/lprng from > system_u:object_r:var_run_t to system_u:object_r:lpd_var_run_t > /usr/sbin/setfiles: hash table stats: 1264 elements, 1264/65536 buckets > used, longest chain len How is this created? Does an init.d script run mkdir? > OK... So I have 4 files with context issues on /var (which is an issue in > and of itself, but not the point here. badfilecontexts however contains: > > /var/lib/rpm/__db.001 > /var/lib/rpm/__db.002 > /var/lib/rpm/__db.003 What is the context of these? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- # bootloader /etc/lilo\.conf.* -- system_u:object_r:bootloader_etc_t /initrd\.img.* -l system_u:object_r:boot_t /sbin/lilo.* -- system_u:object_r:bootloader_exec_t /sbin/grub.* -- system_u:object_r:bootloader_exec_t /vmlinuz.* -l system_u:object_r:boot_t /usr/sbin/mkinitrd -- system_u:object_r:bootloader_exec_t /sbin/mkinitrd -- system_u:object_r:bootloader_exec_t /etc/mkinitrd/scripts/.* -- system_u:object_r:bootloader_exec_t /sbin/ybin.* -- system_u:object_r:bootloader_exec_t /etc/yaboot\.conf.* -- system_u:object_r:bootloader_etc_t /boot/grub/menu.lst -- system_u:object_r:boot_runtime_t -------------- next part -------------- #DESC Initrc - System initialization scripts # # Authors: Stephen Smalley and Timothy Fraser # X-Debian-Packages: sysvinit policycoreutils # ################################# # # Rules for the initrc_t domain. # # initrc_t is the domain of the init rc scripts. # initrc_exec_t is the type of the init program. # ifdef(`sendmail.te', ` # do not use privmail for sendmail as it creates a type transition conflict type initrc_t, ifdef(`unlimitedServices', `admin, etc_writer, fs_domain, privmem, auth_write, ') domain, privlog, privowner, privmodule, sysctl_kernel_writer; allow system_mail_t initrc_t:fd use; allow system_mail_t initrc_t:fifo_file write; ', ` type initrc_t, ifdef(`unlimitedServices', `admin, etc_writer, fs_domain, privmem,auth_write, ') domain, privlog, privowner, privmodule, sysctl_kernel_writer, privmail; ') role system_r types initrc_t; uses_shlib(initrc_t); can_ypbind(initrc_t) type initrc_exec_t, file_type, sysadmfile, exec_type; # for halt to down interfaces allow initrc_t self:udp_socket create_socket_perms; # read files in /etc/init.d allow initrc_t etc_t:lnk_file r_file_perms; read_locale(initrc_t) r_dir_file(initrc_t, usr_t) # Read system information files in /proc. allow initrc_t proc_t:dir r_dir_perms; allow initrc_t proc_t:{ file lnk_file } r_file_perms; # Allow IPC with self allow initrc_t self:unix_dgram_socket create_socket_perms; allow initrc_t self:unix_stream_socket { connectto create_stream_socket_perms }; allow initrc_t self:fifo_file rw_file_perms; # Read the root directory of a usbdevfs filesystem, and # the devices and drivers files. Permit stating of the # device nodes, but nothing else. allow initrc_t usbdevfs_t:dir r_dir_perms; allow initrc_t usbdevfs_t:lnk_file r_file_perms; allow initrc_t usbdevfs_t:file getattr; # allow initrc to fork and renice itself allow initrc_t self:process { fork sigchld setsched setpgid setrlimit }; # Can create ptys for open_init_pty can_create_pty(initrc) tmp_domain(initrc) var_run_domain(initrc) allow initrc_t var_run_t:{ file sock_file lnk_file } unlink; allow initrc_t var_run_t:dir { create rmdir }; allow initrc_t framebuf_device_t:chr_file r_file_perms; # Use capabilities. allow initrc_t self:capability ~{ sys_admin sys_module }; # Use system operations. allow initrc_t kernel_t:system *; # Set values in /proc/sys. can_sysctl(initrc_t) # Run helper programs in the initrc_t domain. allow initrc_t {bin_t sbin_t }:dir r_dir_perms; allow initrc_t {bin_t sbin_t }:lnk_file read; can_exec(initrc_t, etc_t) can_exec(initrc_t, lib_t) can_exec(initrc_t, bin_t) can_exec(initrc_t, sbin_t) can_exec(initrc_t, exec_type) # # These rules are here to allow init scripts to su # ifdef(`su.te', ` su_restricted_domain(initrc,system) role system_r types initrc_su_t; ') allow initrc_t self:passwd rootok; # read /lib/modules allow initrc_t modules_object_t:dir { search read }; # Read conf.modules. allow initrc_t modules_conf_t:file r_file_perms; # Run other rc scripts in the initrc_t domain. can_exec(initrc_t, initrc_exec_t) # Run init (telinit) in the initrc_t domain. can_exec(initrc_t, init_exec_t) # Communicate with the init process. allow initrc_t initctl_t:fifo_file rw_file_perms; # Send messages to portmap and ypbind. ifdef(`portmap.te', `can_udp_send(initrc_t, portmap_t)') ifdef(`ypbind.te', `can_udp_send(initrc_t, ypbind_t)') # Read /proc/PID directories for all domains. r_dir_file(initrc_t, domain) allow initrc_t domain:process { getattr getsession }; # Mount and unmount file systems. allow initrc_t fs_type:filesystem mount_fs_perms; allow initrc_t { file_t default_t }:dir { read search getattr mounton }; # Create runtime files in /etc, e.g. /etc/mtab, /etc/HOSTNAME. file_type_auto_trans(initrc_t, etc_t, etc_runtime_t, file) # Update /etc/ld.so.cache. allow initrc_t ld_so_cache_t:file rw_file_perms; ifdef(`sendmail.te', ` # Update /etc/mail. allow initrc_t etc_mail_t:file { setattr rw_file_perms }; ') ifdef(`xfs.te', ` # Unlink the xfs socket. allow initrc_t xfs_tmp_t:dir rw_dir_perms; allow initrc_t xfs_tmp_t:dir rmdir; allow initrc_t xfs_tmp_t:sock_file { read getattr unlink }; allow initrc_t fonts_t:dir create_dir_perms; allow initrc_t fonts_t:file create_file_perms; ') # Update /var/log/wtmp and /var/log/dmesg. allow initrc_t wtmp_t:file { setattr rw_file_perms }; allow initrc_t var_log_t:file { setattr rw_file_perms }; allow initrc_t lastlog_t:file { setattr rw_file_perms }; # remove old locks allow initrc_t lockfile:dir rw_dir_perms; allow initrc_t lockfile:file { getattr unlink }; # Access /var/lib/random-seed. allow initrc_t var_lib_t:file rw_file_perms; allow initrc_t var_lib_t:file unlink; # Create lock file. allow initrc_t var_lock_t:dir create_dir_perms; allow initrc_t var_lock_t:file create_file_perms; # Set the clock. allow initrc_t clock_device_t:devfile_class_set rw_file_perms; # Kill all processes. allow initrc_t domain:process signal_perms; # Read and unlink /var/run/*.pid files. allow initrc_t pidfile:file { getattr read unlink }; # Write to /dev/urandom. allow initrc_t urandom_device_t:chr_file rw_file_perms; # Set device ownerships/modes. allow initrc_t framebuf_device_t:lnk_file read; allow initrc_t framebuf_device_t:devfile_class_set setattr; allow initrc_t misc_device_t:devfile_class_set setattr; allow initrc_t device_t:devfile_class_set setattr; allow initrc_t fixed_disk_device_t:devfile_class_set setattr; allow initrc_t removable_device_t:devfile_class_set setattr; allow initrc_t device_t:lnk_file read; # Stat any file. allow initrc_t file_type:file_class_set getattr; allow initrc_t file_type:dir { search getattr }; # Read and write console and ttys. allow initrc_t devtty_t:chr_file rw_file_perms; allow initrc_t console_device_t:chr_file rw_file_perms; allow initrc_t tty_device_t:chr_file rw_file_perms; allow initrc_t ttyfile:chr_file rw_file_perms; allow initrc_t ptyfile:chr_file rw_file_perms; # Reset tty labels. allow initrc_t ttyfile:chr_file relabelfrom; allow initrc_t tty_device_t:chr_file relabelto; ifdef(`rpm.te', ` # Create and read /boot/kernel.h and /boot/System.map. # Redhat systems typically create this file at boot time. allow initrc_t boot_t:lnk_file rw_file_perms; file_type_auto_trans(initrc_t, boot_t, boot_runtime_t, file) ') allow initrc_t system_map_t:{ file lnk_file } r_file_perms; ifdef(`rhgb.te', ` allow initrc_t ramfs_t:dir search; allow initrc_t ramfs_t:sock_file write; allow initrc_t rhgb_t:unix_stream_socket { read write }; ') # Unlink /halt. # for /halt /.autofsck and other flag files file_type_auto_trans(initrc_t, root_t, etc_runtime_t, file) ifdef(`gpm.te', `allow initrc_t gpmctl_t:sock_file setattr;') allow initrc_t var_spool_t:file rw_file_perms; # Allow access to the sysadm TTYs. Note that this will give access to the # TTYs to any process in the initrc_t domain. Therefore, daemons and such # started from init should be placed in their own domain. allow initrc_t admin_tty_type:chr_file rw_file_perms; # Access sound device and files. allow initrc_t sound_device_t:chr_file { setattr ioctl read write }; ifdef(`sound.te', `allow initrc_t sound_file_t:file { setattr write };') ifdef(`rpm.te', ` # Access /var/lib/rpm. allow initrc_t var_lib_rpm_t:dir rw_dir_perms; allow initrc_t var_lib_rpm_t:file create_file_perms; ') ifdef(`apmd.te', `# Access /dev/apm_bios. allow initrc_t apm_bios_t:chr_file { setattr getattr };') ifdef(`lpd.te', `# Read printconf files. allow initrc_t printconf_t:dir r_dir_perms; allow initrc_t printconf_t:file r_file_perms;') # Read user home directories. allow initrc_t { home_root_t home_type }:dir r_dir_perms; allow initrc_t home_type:file r_file_perms; # for system start scripts allow initrc_t pidfile:dir rw_dir_perms; allow initrc_t pidfile:sock_file unlink; rw_dir_create_file(initrc_t, var_lib_t) # allow start scripts to clean /tmp allow initrc_t { unlabeled_t tmpfile }:dir { rw_dir_perms rmdir }; allow initrc_t { unlabeled_t tmpfile }:notdevfile_class_set { getattr unlink }; # for lsof which is used by alsa shutdown dontaudit initrc_t domain:{ udp_socket tcp_socket fifo_file unix_dgram_socket } getattr; dontaudit initrc_t proc_kmsg_t:file getattr; ################################# # # Rules for the run_init_t domain. # run_program(sysadm_t, sysadm_r, init, initrc_exec_t, initrc_t) allow initrc_t privfd:fd use; # Transition to system_r:initrc_t upon executing init scripts. ifdef(`direct_sysadm_daemon', ` role_transition sysadm_r initrc_exec_t system_r; domain_auto_trans(sysadm_t, initrc_exec_t, initrc_t) ') # # Shutting down xinet causes these # # Fam dontaudit initrc_t device_t:dir { read write }; # Rsync dontaudit initrc_t mail_spool_t:lnk_file read; allow initrc_t sysfs_t:dir { getattr read search }; allow initrc_t sysfs_t:file { getattr read }; allow initrc_t sysfs_t:lnk_file { getattr read }; allow initrc_t udev_runtime_t:file rw_file_perms; allow initrc_t device_type:chr_file { setattr }; allow initrc_t binfmt_misc_fs_t:dir { getattr search }; allow initrc_t binfmt_misc_fs_t:file { getattr ioctl write }; ifdef(`pam.te', ` allow initrc_t pam_var_run_t:dir rw_dir_perms; allow initrc_t pam_var_run_t:file { getattr read unlink }; ') # for lsof in shutdown scripts allow initrc_t security_t:dir getattr; allow initrc_t krb5_conf_t:file read; dontaudit initrc_t krb5_conf_t:file write; # # Wants to remove udev.tbl # allow initrc_t device_t:dir rw_dir_perms; allow initrc_t device_t:lnk_file { unlink }; allow initrc_t initrc_t:process { getsched }; ifdef(`unlimitedServices', ` unconfined_domain(initrc_t) ') -------------- next part -------------- # init rc scripts /etc/X11/prefdm -- system_u:object_r:initrc_exec_t /etc/rc\.d/rc -- system_u:object_r:initrc_exec_t /etc/rc\.d/rc\.sysinit -- system_u:object_r:initrc_exec_t /etc/rc\.d/rc\.local -- system_u:object_r:initrc_exec_t /etc/rc\.d/init\.d/.* -- system_u:object_r:initrc_exec_t /etc/rc\.d/init\.d/functions -- system_u:object_r:etc_t /etc/init\.d/.* -- system_u:object_r:initrc_exec_t /etc/init\.d/functions -- system_u:object_r:etc_t /var/run/utmp -- system_u:object_r:initrc_var_run_t /var/run/runlevel\.dir system_u:object_r:initrc_var_run_t /var/run/random-seed -- system_u:object_r:initrc_var_run_t /var/run/setmixer_flag -- system_u:object_r:initrc_var_run_t # run_init /usr/sbin/run_init -- system_u:object_r:run_init_exec_t /usr/sbin/open_init_pty -- system_u:object_r:initrc_exec_t /etc/nologin.* -- system_u:object_r:etc_runtime_t /etc/nohotplug -- system_u:object_r:etc_runtime_t /halt -- system_u:object_r:etc_runtime_t /\.autofsck -- system_u:object_r:etc_runtime_t From ivg2 at cornell.edu Thu Jul 8 03:22:03 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 07 Jul 2004 21:22:03 -0600 Subject: fixfile.cron added. In-Reply-To: <1089227042.1774.200.camel@moss-spartans.epoch.ncsc.mil> References: <40E40011.4080408@redhat.com> <1089078280.30565.2.camel@localhost.bluenet> <1089227042.1774.200.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1089256923.8812.1.camel@localhost.bluenet> On Wed, 2004-07-07 at 15:04 -0400, Stephen Smalley wrote: > On Mon, 2004-07-05 at 21:44, Ivan Gyurdiev wrote: > > > Suggestions on improvements? Comments? > > > > Just wondering why I have hundreds of denials > > from sysadm_crond_t in my system log with /usr/bin/setfiles in them. > > > > Latest policy, permissive mode. > > sysadm_crond_t or system_crond_t? sysadm is correct (audit2allow in verbose mode): allow sysadm_crond_t adjtime_t:file { getattr }; #EXE=/usr/sbin/setfiles PATH=/etc/adjtime : getattr #EXE=/usr/sbin/setfiles PATH=/etc/adjtime : getattr allow sysadm_crond_t admin_passwd_exec_t:file { getattr }; #EXE=/usr/sbin/setfiles PATH=/usr/sbin/vipw : getattr #EXE=/usr/sbin/setfiles PATH=/usr/sbin/vipw : getattr allow sysadm_crond_t agp_device_t:chr_file { getattr }; #EXE=/usr/sbin/setfiles PATH=/dev/agpgart : getattr #EXE=/usr/sbin/setfiles PATH=/dev/agpgart : getattr allow sysadm_crond_t amanda_amandates_t:file { getattr }; #EXE=/usr/sbin/setfiles PATH=/etc/amandates : getattr #EXE=/usr/sbin/setfiles PATH=/etc/amandates : getattr ...etc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sds at epoch.ncsc.mil Thu Jul 8 12:23:31 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 08 Jul 2004 08:23:31 -0400 Subject: fixfile.cron added. In-Reply-To: <1089256923.8812.1.camel@localhost.bluenet> References: <40E40011.4080408@redhat.com> <1089078280.30565.2.camel@localhost.bluenet> <1089227042.1774.200.camel@moss-spartans.epoch.ncsc.mil> <1089256923.8812.1.camel@localhost.bluenet> Message-ID: <1089289411.6414.0.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-07-07 at 23:22, Ivan Gyurdiev wrote: > sysadm is correct (audit2allow in verbose mode): > > allow sysadm_crond_t adjtime_t:file { getattr }; > #EXE=/usr/sbin/setfiles PATH=/etc/adjtime : getattr > #EXE=/usr/sbin/setfiles PATH=/etc/adjtime : getattr Interesting. Bug in crond? Should be running in system_crond_t. Any interesting output in /var/log/cron? What version of vixie-cron are you running? -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Jul 8 15:30:50 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 08 Jul 2004 11:30:50 -0400 Subject: /sbin/fixfiles bug (was Re: fixfile.cron added. In-Reply-To: <200407081246.13401.russell@coker.com.au> References: <40E40011.4080408@redhat.com> <200407031747.i63Hl5hZ014360@turing-police.cc.vt.edu> <200407081246.13401.russell@coker.com.au> Message-ID: <40ED68AA.9030208@redhat.com> Russell Coker wrote: >On Sun, 4 Jul 2004 03:47, Valdis.Kletnieks at vt.edu wrote: > > >>/usr/sbin/setfiles: labeling files under /var >>/usr/sbin/setfiles: relabeling /var/lib/scrollkeeper/TOC/464 from >>root:object_r:rpm_var_lib_t to system_u:object_r:var_lib_t >>/usr/sbin/setfiles: relabeling /var/lib/scrollkeeper/index/464 from >>root:object_r:rpm_var_lib_t to system_u:object_r:var_lib_t >> >> > >It seems that rpm_var_lib_t doesn't differ much in access from var_lib_t. I >think that it would be appropriate to remove the line var_lib_domain(rpm) and >allow the rpm files in question to have type var_lib_t. > >Dan, what do you think? > > I agree. >Of course we have another problem in that rpm_t should not be creating such >files, the script which does so should run as rpm_script_t. > > > Don't know why. >>/usr/sbin/setfiles: relabeling /var/run/lpd.515 from >>system_u:object_r:lpd_var_run_t to system_u:object_r:var_run_t >> >> > >What is this lpd.515 file? Is that always the name for it? We need to get a >matching entry in lpd.fc. > > Added /var/run/lpd.* system_u:object_r:lpd_var_run_t > > >>/usr/sbin/setfiles: relabeling /var/run/lprng from >>system_u:object_r:var_run_t to system_u:object_r:lpd_var_run_t >>/usr/sbin/setfiles: hash table stats: 1264 elements, 1264/65536 buckets >>used, longest chain len >> >> > >How is this created? Does an init.d script run mkdir? > > > >>OK... So I have 4 files with context issues on /var (which is an issue in >>and of itself, but not the point here. badfilecontexts however contains: >> >>/var/lib/rpm/__db.001 >>/var/lib/rpm/__db.002 >>/var/lib/rpm/__db.003 >> >> > >What is the context of these? > > > >------------------------------------------------------------------------ > ># bootloader >/etc/lilo\.conf.* -- system_u:object_r:bootloader_etc_t >/initrd\.img.* -l system_u:object_r:boot_t >/sbin/lilo.* -- system_u:object_r:bootloader_exec_t >/sbin/grub.* -- system_u:object_r:bootloader_exec_t >/vmlinuz.* -l system_u:object_r:boot_t >/usr/sbin/mkinitrd -- system_u:object_r:bootloader_exec_t >/sbin/mkinitrd -- system_u:object_r:bootloader_exec_t >/etc/mkinitrd/scripts/.* -- system_u:object_r:bootloader_exec_t >/sbin/ybin.* -- system_u:object_r:bootloader_exec_t >/etc/yaboot\.conf.* -- system_u:object_r:bootloader_etc_t >/boot/grub/menu.lst -- system_u:object_r:boot_runtime_t > > >------------------------------------------------------------------------ > >#DESC Initrc - System initialization scripts ># ># Authors: Stephen Smalley and Timothy Fraser ># X-Debian-Packages: sysvinit policycoreutils ># > >################################# ># ># Rules for the initrc_t domain. ># ># initrc_t is the domain of the init rc scripts. ># initrc_exec_t is the type of the init program. ># >ifdef(`sendmail.te', ` ># do not use privmail for sendmail as it creates a type transition conflict >type initrc_t, ifdef(`unlimitedServices', `admin, etc_writer, fs_domain, privmem, auth_write, ') domain, privlog, privowner, privmodule, sysctl_kernel_writer; >allow system_mail_t initrc_t:fd use; >allow system_mail_t initrc_t:fifo_file write; >', ` >type initrc_t, ifdef(`unlimitedServices', `admin, etc_writer, fs_domain, privmem,auth_write, ') domain, privlog, privowner, privmodule, sysctl_kernel_writer, privmail; >') >role system_r types initrc_t; >uses_shlib(initrc_t); >can_ypbind(initrc_t) >type initrc_exec_t, file_type, sysadmfile, exec_type; > ># for halt to down interfaces >allow initrc_t self:udp_socket create_socket_perms; > ># read files in /etc/init.d >allow initrc_t etc_t:lnk_file r_file_perms; > >read_locale(initrc_t) > >r_dir_file(initrc_t, usr_t) > ># Read system information files in /proc. >allow initrc_t proc_t:dir r_dir_perms; >allow initrc_t proc_t:{ file lnk_file } r_file_perms; > ># Allow IPC with self >allow initrc_t self:unix_dgram_socket create_socket_perms; >allow initrc_t self:unix_stream_socket { connectto create_stream_socket_perms }; >allow initrc_t self:fifo_file rw_file_perms; > ># Read the root directory of a usbdevfs filesystem, and ># the devices and drivers files. Permit stating of the ># device nodes, but nothing else. >allow initrc_t usbdevfs_t:dir r_dir_perms; >allow initrc_t usbdevfs_t:lnk_file r_file_perms; >allow initrc_t usbdevfs_t:file getattr; > ># allow initrc to fork and renice itself >allow initrc_t self:process { fork sigchld setsched setpgid setrlimit }; > ># Can create ptys for open_init_pty >can_create_pty(initrc) > >tmp_domain(initrc) > >var_run_domain(initrc) >allow initrc_t var_run_t:{ file sock_file lnk_file } unlink; >allow initrc_t var_run_t:dir { create rmdir }; > >allow initrc_t framebuf_device_t:chr_file r_file_perms; > ># Use capabilities. >allow initrc_t self:capability ~{ sys_admin sys_module }; > ># Use system operations. >allow initrc_t kernel_t:system *; > ># Set values in /proc/sys. >can_sysctl(initrc_t) > ># Run helper programs in the initrc_t domain. >allow initrc_t {bin_t sbin_t }:dir r_dir_perms; >allow initrc_t {bin_t sbin_t }:lnk_file read; >can_exec(initrc_t, etc_t) >can_exec(initrc_t, lib_t) >can_exec(initrc_t, bin_t) >can_exec(initrc_t, sbin_t) >can_exec(initrc_t, exec_type) ># ># These rules are here to allow init scripts to su ># >ifdef(`su.te', ` >su_restricted_domain(initrc,system) >role system_r types initrc_su_t; >') >allow initrc_t self:passwd rootok; > ># read /lib/modules >allow initrc_t modules_object_t:dir { search read }; > ># Read conf.modules. >allow initrc_t modules_conf_t:file r_file_perms; > ># Run other rc scripts in the initrc_t domain. >can_exec(initrc_t, initrc_exec_t) > ># Run init (telinit) in the initrc_t domain. >can_exec(initrc_t, init_exec_t) > ># Communicate with the init process. >allow initrc_t initctl_t:fifo_file rw_file_perms; > ># Send messages to portmap and ypbind. >ifdef(`portmap.te', `can_udp_send(initrc_t, portmap_t)') >ifdef(`ypbind.te', `can_udp_send(initrc_t, ypbind_t)') > ># Read /proc/PID directories for all domains. >r_dir_file(initrc_t, domain) >allow initrc_t domain:process { getattr getsession }; > ># Mount and unmount file systems. >allow initrc_t fs_type:filesystem mount_fs_perms; >allow initrc_t { file_t default_t }:dir { read search getattr mounton }; > ># Create runtime files in /etc, e.g. /etc/mtab, /etc/HOSTNAME. >file_type_auto_trans(initrc_t, etc_t, etc_runtime_t, file) > ># Update /etc/ld.so.cache. >allow initrc_t ld_so_cache_t:file rw_file_perms; > >ifdef(`sendmail.te', ` ># Update /etc/mail. >allow initrc_t etc_mail_t:file { setattr rw_file_perms }; >') > >ifdef(`xfs.te', ` ># Unlink the xfs socket. >allow initrc_t xfs_tmp_t:dir rw_dir_perms; >allow initrc_t xfs_tmp_t:dir rmdir; >allow initrc_t xfs_tmp_t:sock_file { read getattr unlink }; >allow initrc_t fonts_t:dir create_dir_perms; >allow initrc_t fonts_t:file create_file_perms; >') > ># Update /var/log/wtmp and /var/log/dmesg. >allow initrc_t wtmp_t:file { setattr rw_file_perms }; >allow initrc_t var_log_t:file { setattr rw_file_perms }; >allow initrc_t lastlog_t:file { setattr rw_file_perms }; > ># remove old locks >allow initrc_t lockfile:dir rw_dir_perms; >allow initrc_t lockfile:file { getattr unlink }; > ># Access /var/lib/random-seed. >allow initrc_t var_lib_t:file rw_file_perms; >allow initrc_t var_lib_t:file unlink; > ># Create lock file. >allow initrc_t var_lock_t:dir create_dir_perms; >allow initrc_t var_lock_t:file create_file_perms; > ># Set the clock. >allow initrc_t clock_device_t:devfile_class_set rw_file_perms; > ># Kill all processes. >allow initrc_t domain:process signal_perms; > ># Read and unlink /var/run/*.pid files. >allow initrc_t pidfile:file { getattr read unlink }; > ># Write to /dev/urandom. >allow initrc_t urandom_device_t:chr_file rw_file_perms; > ># Set device ownerships/modes. >allow initrc_t framebuf_device_t:lnk_file read; >allow initrc_t framebuf_device_t:devfile_class_set setattr; >allow initrc_t misc_device_t:devfile_class_set setattr; >allow initrc_t device_t:devfile_class_set setattr; >allow initrc_t fixed_disk_device_t:devfile_class_set setattr; >allow initrc_t removable_device_t:devfile_class_set setattr; >allow initrc_t device_t:lnk_file read; > ># Stat any file. >allow initrc_t file_type:file_class_set getattr; >allow initrc_t file_type:dir { search getattr }; > ># Read and write console and ttys. >allow initrc_t devtty_t:chr_file rw_file_perms; >allow initrc_t console_device_t:chr_file rw_file_perms; >allow initrc_t tty_device_t:chr_file rw_file_perms; >allow initrc_t ttyfile:chr_file rw_file_perms; >allow initrc_t ptyfile:chr_file rw_file_perms; > ># Reset tty labels. >allow initrc_t ttyfile:chr_file relabelfrom; >allow initrc_t tty_device_t:chr_file relabelto; > >ifdef(`rpm.te', ` ># Create and read /boot/kernel.h and /boot/System.map. ># Redhat systems typically create this file at boot time. >allow initrc_t boot_t:lnk_file rw_file_perms; >file_type_auto_trans(initrc_t, boot_t, boot_runtime_t, file) >') > >allow initrc_t system_map_t:{ file lnk_file } r_file_perms; > >ifdef(`rhgb.te', ` >allow initrc_t ramfs_t:dir search; >allow initrc_t ramfs_t:sock_file write; >allow initrc_t rhgb_t:unix_stream_socket { read write }; >') > ># Unlink /halt. ># for /halt /.autofsck and other flag files >file_type_auto_trans(initrc_t, root_t, etc_runtime_t, file) > >ifdef(`gpm.te', `allow initrc_t gpmctl_t:sock_file setattr;') > >allow initrc_t var_spool_t:file rw_file_perms; > ># Allow access to the sysadm TTYs. Note that this will give access to the ># TTYs to any process in the initrc_t domain. Therefore, daemons and such ># started from init should be placed in their own domain. >allow initrc_t admin_tty_type:chr_file rw_file_perms; > ># Access sound device and files. >allow initrc_t sound_device_t:chr_file { setattr ioctl read write }; >ifdef(`sound.te', `allow initrc_t sound_file_t:file { setattr write };') > >ifdef(`rpm.te', ` ># Access /var/lib/rpm. >allow initrc_t var_lib_rpm_t:dir rw_dir_perms; >allow initrc_t var_lib_rpm_t:file create_file_perms; >') > >ifdef(`apmd.te', >`# Access /dev/apm_bios. >allow initrc_t apm_bios_t:chr_file { setattr getattr };') > >ifdef(`lpd.te', >`# Read printconf files. >allow initrc_t printconf_t:dir r_dir_perms; >allow initrc_t printconf_t:file r_file_perms;') > ># Read user home directories. >allow initrc_t { home_root_t home_type }:dir r_dir_perms; >allow initrc_t home_type:file r_file_perms; > ># for system start scripts >allow initrc_t pidfile:dir rw_dir_perms; >allow initrc_t pidfile:sock_file unlink; >rw_dir_create_file(initrc_t, var_lib_t) > ># allow start scripts to clean /tmp >allow initrc_t { unlabeled_t tmpfile }:dir { rw_dir_perms rmdir }; >allow initrc_t { unlabeled_t tmpfile }:notdevfile_class_set { getattr unlink }; > ># for lsof which is used by alsa shutdown >dontaudit initrc_t domain:{ udp_socket tcp_socket fifo_file unix_dgram_socket } getattr; >dontaudit initrc_t proc_kmsg_t:file getattr; > >################################# ># ># Rules for the run_init_t domain. ># >run_program(sysadm_t, sysadm_r, init, initrc_exec_t, initrc_t) >allow initrc_t privfd:fd use; > ># Transition to system_r:initrc_t upon executing init scripts. >ifdef(`direct_sysadm_daemon', ` >role_transition sysadm_r initrc_exec_t system_r; >domain_auto_trans(sysadm_t, initrc_exec_t, initrc_t) >') > ># ># Shutting down xinet causes these ># ># Fam >dontaudit initrc_t device_t:dir { read write }; ># Rsync >dontaudit initrc_t mail_spool_t:lnk_file read; > >allow initrc_t sysfs_t:dir { getattr read search }; >allow initrc_t sysfs_t:file { getattr read }; >allow initrc_t sysfs_t:lnk_file { getattr read }; >allow initrc_t udev_runtime_t:file rw_file_perms; >allow initrc_t device_type:chr_file { setattr }; >allow initrc_t binfmt_misc_fs_t:dir { getattr search }; >allow initrc_t binfmt_misc_fs_t:file { getattr ioctl write }; >ifdef(`pam.te', ` >allow initrc_t pam_var_run_t:dir rw_dir_perms; >allow initrc_t pam_var_run_t:file { getattr read unlink }; >') > ># for lsof in shutdown scripts >allow initrc_t security_t:dir getattr; >allow initrc_t krb5_conf_t:file read; >dontaudit initrc_t krb5_conf_t:file write; ># ># Wants to remove udev.tbl ># >allow initrc_t device_t:dir rw_dir_perms; >allow initrc_t device_t:lnk_file { unlink }; >allow initrc_t initrc_t:process { getsched }; > >ifdef(`unlimitedServices', ` >unconfined_domain(initrc_t) >') > > >------------------------------------------------------------------------ > ># init rc scripts >/etc/X11/prefdm -- system_u:object_r:initrc_exec_t >/etc/rc\.d/rc -- system_u:object_r:initrc_exec_t >/etc/rc\.d/rc\.sysinit -- system_u:object_r:initrc_exec_t >/etc/rc\.d/rc\.local -- system_u:object_r:initrc_exec_t >/etc/rc\.d/init\.d/.* -- system_u:object_r:initrc_exec_t >/etc/rc\.d/init\.d/functions -- system_u:object_r:etc_t >/etc/init\.d/.* -- system_u:object_r:initrc_exec_t >/etc/init\.d/functions -- system_u:object_r:etc_t >/var/run/utmp -- system_u:object_r:initrc_var_run_t >/var/run/runlevel\.dir system_u:object_r:initrc_var_run_t >/var/run/random-seed -- system_u:object_r:initrc_var_run_t >/var/run/setmixer_flag -- system_u:object_r:initrc_var_run_t ># run_init >/usr/sbin/run_init -- system_u:object_r:run_init_exec_t >/usr/sbin/open_init_pty -- system_u:object_r:initrc_exec_t >/etc/nologin.* -- system_u:object_r:etc_runtime_t >/etc/nohotplug -- system_u:object_r:etc_runtime_t >/halt -- system_u:object_r:etc_runtime_t >/\.autofsck -- system_u:object_r:etc_runtime_t > > From dwalsh at redhat.com Thu Jul 8 15:45:47 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 08 Jul 2004 11:45:47 -0400 Subject: And another fixfiles comment... (was Re: fixfile.cron added. In-Reply-To: <200407051951.i65Jpn6u020754@turing-police.cc.vt.edu> References: <40E40011.4080408@redhat.com> <200407051951.i65Jpn6u020754@turing-police.cc.vt.edu> Message-ID: <40ED6C2B.7030001@redhat.com> Valdis.Kletnieks at vt.edu wrote: >On Thu, 01 Jul 2004 08:14:09 EDT, Daniel J Walsh said: > > >>Todays policycoreutils has a new cron job, fixfiles.cron, that will run >>in /etc/cron.daily. This script will run a check on the file system on >> >> > >Currently, fixfiles does some interesting grepping through the mounts >to only work on R/W mounts. This has 2 problems when run on a system >that has many filesystems mounted with some combo of ro/nosuid/nodev/noexec: > >1) It's possible for the sysadmin to not realize that fixfiles isn't >relabelling a filesystem because it's R/O (note that this problem is >shared by the 'make relabel' target in /etc/selinux/*/src/policy/Makefile). > >2) If we're only checking, we should do R/O filesystems as well - the fact >that they're R/O when the cronjob runs doesn't mean that they weren't R/W >and picked up some bad labels at some previous time. > >Lightly tested patch: > >--- /sbin/fixfiles.dist 2004-06-30 13:40:47.000000000 -0400 >+++ /sbin/fixfiles 2004-07-05 04:53:24.000000000 -0400 >@@ -30,9 +30,12 @@ rpmFlag=0 > rpmFiles="" > outfileFlag=0 > OUTFILES="" >+logfileFlag=0 > LOGFILE=`mktemp /var/tmp/fixfiles.XXXXXXXXXX` || exit 1 > SETFILES=/usr/sbin/setfiles >-FILESYSTEMS=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[23]| xfs | reiserfs ).*rw/{print $3}';` >+FILESYSTEMSRW=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[23]| xfs | reiserfs ).*\(rw/{print $3}';` >+FILESYSTEMSRO=`mount | grep -v "context=" | egrep -v '\((|.*,)bind(,.*|)\)' | awk '/(ext[23]| xfs | reiserfs ).*\(ro/{print $3}';` >+FILESYSTEMS="$FILESYSTEMSRW $FILESYSTEMSRO" > SELINUXTYPE="targeted" > > if [ -e /etc/selinux/config ]; then >@@ -60,7 +63,11 @@ if [ ! -z "$1" ]; then > rpm -q -l $i | restorecon ${OUTFILES} -v -f - 2>&1 | tee $LOGFILE > done > else >- ${SETFILES} ${OUTFILES} ${OUTFILES} -v ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE >+ if [ "x$FILESYSTEMSRO" != "x" ]; then >+ echo "Warning: Skipping the following R/O filesystems:" >+ echo "$FILESYSTEMSRO" >+ fi >+ ${SETFILES} ${OUTFILES} ${OUTFILES} -v ${FC} ${FILESYSTEMSRW} 2>&1 | tee $LOGFILE > fi > } > >@@ -73,7 +80,11 @@ if [ ! -z "$1" ]; then > rpm -q -l $i | restorecon ${OUTFILES} -v -f - 2>&1 | tee $LOGFILE > done > else >- ${SETFILES} ${OUTFILES} -v ${FC} ${FILESYSTEMS} 2>&1 | tee $LOGFILE >+ if [ "x$FILESYSTEMSRO" != "x" ]; then >+ echo "Warning: Skipping the following R/O filesystems:" >+ echo "$FILESYSTEMSRO" >+ fi >+ ${SETFILES} ${OUTFILES} -v ${FC} ${FILESYSTEMSRW} 2>&1 | tee $LOGFILE > fi > } > relabelCheck() { > > Added to fixfiles. > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From selinux at comcast.net Thu Jul 8 17:29:23 2004 From: selinux at comcast.net (Tom London) Date: Thu, 08 Jul 2004 10:29:23 -0700 Subject: FC3... install/update ? Message-ID: <40ED8473.4080203@comcast.net> With FC3 about to descend, anyone know if updates from FC2 will be supported? Only clean installs? Any thoughts on SELinux-related areas needing attention? tom From ivg2 at cornell.edu Thu Jul 8 17:40:33 2004 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 08 Jul 2004 11:40:33 -0600 Subject: fixfile.cron added. In-Reply-To: <1089289411.6414.0.camel@moss-spartans.epoch.ncsc.mil> References: <40E40011.4080408@redhat.com> <1089078280.30565.2.camel@localhost.bluenet> <1089227042.1774.200.camel@moss-spartans.epoch.ncsc.mil> <1089256923.8812.1.camel@localhost.bluenet> <1089289411.6414.0.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1089308433.11922.4.camel@localhost.bluenet> On Thu, 2004-07-08 at 08:23 -0400, Stephen Smalley wrote: > On Wed, 2004-07-07 at 23:22, Ivan Gyurdiev wrote: > > sysadm is correct (audit2allow in verbose mode): > > > > allow sysadm_crond_t adjtime_t:file { getattr }; > > #EXE=/usr/sbin/setfiles PATH=/etc/adjtime : getattr > > #EXE=/usr/sbin/setfiles PATH=/etc/adjtime : getattr > > Interesting. Bug in crond? Should be running in system_crond_t. > Any interesting output in /var/log/cron? Not really. > What version of vixie-cron are > you running? vixie-cron-3.0.1-86. I see now that this is old - there's a 94 on rawhide. It is not cool that yum does not upgrade packages when you expect it to. This one I built myself (along with a bunch of others), and it just won't upgrade despite the newer version on rawhide. On the other hand I get bitten every time when developers fall back to an older version and yum does not do the same. Yum needs improvement. I'll report any problems I see with this cron (94). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From laroche at redhat.com Thu Jul 8 17:42:56 2004 From: laroche at redhat.com (Florian La Roche) Date: Thu, 8 Jul 2004 19:42:56 +0200 Subject: FC3... install/update ? In-Reply-To: <40ED8473.4080203@comcast.net> References: <40ED8473.4080203@comcast.net> Message-ID: <20040708174256.GA4603@dudweiler.stuttgart.redhat.com> On Thu, Jul 08, 2004 at 10:29:23AM -0700, Tom London wrote: > With FC3 about to descend, anyone know if updates > from FC2 will be supported? Only clean installs? We certainly want to hear about breakages and check if those can get fixed. greetings, Florian La Roche > > Any thoughts on SELinux-related areas needing attention? > > tom > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From sds at epoch.ncsc.mil Thu Jul 8 17:54:05 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 08 Jul 2004 13:54:05 -0400 Subject: FC3... install/update ? In-Reply-To: <40ED8473.4080203@comcast.net> References: <40ED8473.4080203@comcast.net> Message-ID: <1089309245.6414.135.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-08 at 13:29, Tom London wrote: > With FC3 about to descend, anyone know if updates > from FC2 will be supported? Only clean installs? Are updates ever "supported"? In any event, I've been tracking rawhide regularly via yum update so far, and haven't had any significant problems. > Any thoughts on SELinux-related areas needing attention? usermode (userhelper) and sudo are still in flux, expect changes soon both to the code and the policy. Integrated user management is still a major area needing improvement, as most Fedora SELinux users are not maintaining policy/users at present for individual users (beyond system_u/user_u/root distinctions) due to the lack of such integration and thus cannot take full advantage of roles. setools and setools-gui includes some tools for managing SELinux users, but there is nothing today to deal with distributed user databases, e.g. NIS or LDAP. In general, policy management tools that are more oriented toward sysadmins rather than security analysts are needed. -- Stephen Smalley National Security Agency From rpjday at mindspring.com Thu Jul 8 17:54:16 2004 From: rpjday at mindspring.com (Robert P. J. Day) Date: Thu, 8 Jul 2004 13:54:16 -0400 (EDT) Subject: FC3... install/update ? In-Reply-To: <1089309245.6414.135.camel@moss-spartans.epoch.ncsc.mil> References: <40ED8473.4080203@comcast.net> <1089309245.6414.135.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Thu, 8 Jul 2004, Stephen Smalley wrote: > On Thu, 2004-07-08 at 13:29, Tom London wrote: >> With FC3 about to descend, anyone know if updates >> from FC2 will be supported? Only clean installs? > > Are updates ever "supported"? In any event, I've been tracking rawhide > regularly via yum update so far, and haven't had any significant > problems. *theoretically*, you should be able to update. the rules are really quite simple -- technically, you should be able to update from any *official* release to a subsequent release (within reason, of course), whether that subsequent release is real or test. think about it -- FC3t1 is supposed to represent the first pass at FC3. so i'm sure the FC folks would really like some people to at least take a shot at the update, to help work the bugs out. just back up first. :-) rday From mfedyk at matchmail.com Thu Jul 8 18:15:38 2004 From: mfedyk at matchmail.com (Mike Fedyk) Date: Thu, 08 Jul 2004 11:15:38 -0700 Subject: FC3... install/update ? In-Reply-To: <1089309245.6414.135.camel@moss-spartans.epoch.ncsc.mil> References: <40ED8473.4080203@comcast.net> <1089309245.6414.135.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <40ED8F4A.40600@matchmail.com> Stephen Smalley wrote: >includes some tools for managing SELinux users, but there is nothing >today to deal with distributed user databases, e.g. NIS or LDAP. In > > There is Directory Administrator that currently works with LDAP user databases. It is gnome based, so it should fit well with the rest of FC, and I'm sure support for NIS could be added also. From sds at epoch.ncsc.mil Thu Jul 8 18:17:59 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 08 Jul 2004 14:17:59 -0400 Subject: FC3... install/update ? In-Reply-To: <40ED8F4A.40600@matchmail.com> References: <40ED8473.4080203@comcast.net> <1089309245.6414.135.camel@moss-spartans.epoch.ncsc.mil> <40ED8F4A.40600@matchmail.com> Message-ID: <1089310678.6414.142.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-08 at 14:15, Mike Fedyk wrote: > There is Directory Administrator that currently works with LDAP user > databases. > > It is gnome based, so it should fit well with the rest of FC, and I'm > sure support for NIS could be added also. Sorry, I meant that there is nothing today to integrate distributed user databases such as NIS or LDAP with the SELinux policy user database. Not that Fedora itself lacks support for such things; we just lack the infrastructure to link them with SELinux at present, and doing so safely isn't trivial. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Thu Jul 8 18:23:18 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 08 Jul 2004 14:23:18 -0400 Subject: fixfile.cron added. In-Reply-To: <1089308433.11922.4.camel@localhost.bluenet> References: <40E40011.4080408@redhat.com> <1089078280.30565.2.camel@localhost.bluenet> <1089227042.1774.200.camel@moss-spartans.epoch.ncsc.mil> <1089256923.8812.1.camel@localhost.bluenet> <1089289411.6414.0.camel@moss-spartans.epoch.ncsc.mil> <1089308433.11922.4.camel@localhost.bluenet> Message-ID: <1089310998.6414.148.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-08 at 13:40, Ivan Gyurdiev wrote: > I'll report any problems I see with this cron (94). Likely need the following rules added to crond.te: r_dir_file(system_crond_t, file_context_t) can_getsecurity(system_crond_t) -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Jul 8 18:40:31 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 08 Jul 2004 14:40:31 -0400 Subject: fixfile.cron added. In-Reply-To: <1089310998.6414.148.camel@moss-spartans.epoch.ncsc.mil> References: <40E40011.4080408@redhat.com> <1089078280.30565.2.camel@localhost.bluenet> <1089227042.1774.200.camel@moss-spartans.epoch.ncsc.mil> <1089256923.8812.1.camel@localhost.bluenet> <1089289411.6414.0.camel@moss-spartans.epoch.ncsc.mil> <1089308433.11922.4.camel@localhost.bluenet> <1089310998.6414.148.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <40ED951F.7090209@redhat.com> Stephen Smalley wrote: >On Thu, 2004-07-08 at 13:40, Ivan Gyurdiev wrote: > > >>I'll report any problems I see with this cron (94). >> >> > >Likely need the following rules added to crond.te: > >r_dir_file(system_crond_t, file_context_t) >can_getsecurity(system_crond_t) > > > We might want to add a tunable to allow system_crond_t to exec setfiles_t. You can modify the /etc/selinux/config file and add CRONTYPE="restore" CRONMAILTO="dwalsh at redhat.com" Which would cause setfiles to restore the security contexts when fixfiles.cron runs. and send mail to the specified user. Dan From sds at epoch.ncsc.mil Thu Jul 8 19:00:58 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 08 Jul 2004 15:00:58 -0400 Subject: fixfile.cron added. In-Reply-To: <40ED951F.7090209@redhat.com> References: <40E40011.4080408@redhat.com> <1089078280.30565.2.camel@localhost.bluenet> <1089227042.1774.200.camel@moss-spartans.epoch.ncsc.mil> <1089256923.8812.1.camel@localhost.bluenet> <1089289411.6414.0.camel@moss-spartans.epoch.ncsc.mil> <1089308433.11922.4.camel@localhost.bluenet> <1089310998.6414.148.camel@moss-spartans.epoch.ncsc.mil> <40ED951F.7090209@redhat.com> Message-ID: <1089313258.6414.154.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-08 at 14:40, Daniel J Walsh wrote: > We might want to add a tunable to allow system_crond_t to exec > setfiles_t. You can modify the > /etc/selinux/config file and add > CRONTYPE="restore" > CRONMAILTO="dwalsh at redhat.com" > > Which would cause setfiles to restore the security contexts when > fixfiles.cron runs. and send mail to the specified user. Patch below (replaces patch sent earlier for running setfiles without changing domains just to check contexts). Index: policy/domains/program/crond.te =================================================================== RCS file: /nfshome/pal/CVS/selinux-usr/policy/domains/program/crond.te,v retrieving revision 1.23 diff -u -r1.23 crond.te --- policy/domains/program/crond.te 16 Jun 2004 17:07:45 -0000 1.23 +++ policy/domains/program/crond.te 8 Jul 2004 18:56:41 -0000 @@ -194,3 +194,10 @@ dontaudit userdomain system_crond_t:fd { use }; r_dir_file(crond_t, selinux_config_t) + +ifdef(`cron_can_relabel', ` +domain_auto_trans(system_crond_t, setfiles_exec_t, setfiles_t) +', ` +r_dir_file(system_crond_t, file_context_t) +can_getsecurity(system_crond_t) +') Index: policy/tunables/tunable.te =================================================================== RCS file: /nfshome/pal/CVS/selinux-usr/policy/tunables/tunable.te,v retrieving revision 1.4 diff -u -r1.4 tunable.te --- policy/tunables/tunable.te 17 Jun 2004 16:59:30 -0000 1.4 +++ policy/tunables/tunable.te 8 Jul 2004 18:56:09 -0000 @@ -100,3 +100,5 @@ # Allow user to rw usb devices dnl define(`user_rw_usb') +# Allow system cron job to relabel filesystem for restoring file contexts. +dnl define(`cron_can_relabel') -- Stephen Smalley National Security Agency From wolfy at zig-zag.net Thu Jul 8 20:23:22 2004 From: wolfy at zig-zag.net (lonely wolf) Date: Thu, 08 Jul 2004 23:23:22 +0300 Subject: fixfile.cron added. In-Reply-To: <1089308433.11922.4.camel@localhost.bluenet> References: <40E40011.4080408@redhat.com> <1089078280.30565.2.camel@localhost.bluenet> <1089227042.1774.200.camel@moss-spartans.epoch.ncsc.mil> <1089256923.8812.1.camel@localhost.bluenet> <1089289411.6414.0.camel@moss-spartans.epoch.ncsc.mil> <1089308433.11922.4.camel@localhost.bluenet> Message-ID: <40EDAD3A.2060905@zig-zag.net> Ivan Gyurdiev wrote: > This one I built myself (along with a bunch of others), and it just > won't upgrade despite the newer version on rawhide. make sure that %epoch=0 in your rpm From rhallyx at mindspring.com Fri Jul 9 05:13:38 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Fri, 09 Jul 2004 01:13:38 -0400 Subject: policy addition for mozilla Message-ID: <40EE2982.1030903@mindspring.com> Attached (and below) is a diff of a one line addition for mozilla_macros.te from the the selinux-policy-strict-sources-1.14.1-5. audit2allow generated the following from the avc denied messages I received when trying to run Mozilla: allow staff_mozilla_t xdm_tmp_t:dir { search }; Please add Thanks Richard Hally --- mozilla_macros.te.prev 2004-07-09 00:32:53.397132227 -0400 +++ mozilla_macros.te 2004-07-09 00:34:15.845137952 -0400 @@ -116,6 +116,7 @@ ifdef(`xdm.te', ` allow $1_mozilla_t xdm_t:fifo_file { write read }; +allow $1_mozilla_t xdm_tmp_t:dir { search }; allow $1_mozilla_t xdm_tmp_t:file { getattr read }; allow $1_mozilla_t xdm_tmp_t:sock_file { write }; ')dnl end if xdm.te -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: moz_diff URL: From kvogelsa at ccs.neu.edu Fri Jul 9 14:18:28 2004 From: kvogelsa at ccs.neu.edu (Kirk Vogelsang) Date: Fri, 9 Jul 2004 10:18:28 -0400 (EDT) Subject: sudo avc denies: was Re: Upgrading to policy-strict RPM's In-Reply-To: <1089229788.1774.250.camel@moss-spartans.epoch.ncsc.mil> References: <1089229788.1774.250.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Wed, 7 Jul 2004, Stephen Smalley wrote: > On Wed, 2004-07-07 at 15:38, Kirk Vogelsang wrote: > > I've got slimmed down Fedora Core2 that doesn't seem to want to > > enable selinux after rpm -U'ing the following packages: > > > > policycoreutils-1.14.1-1 > > selinux-policy-strict-1.14.1-2 > > libselinux-1.14.1-1 > > > > After upgrading to those packages, booting to single user, > > running fixfiles relabel, and rebooting once more, the system > > comes up selinux disabled. I've verified /etc/selinux/config > > SELINUX=permissive and SELINUXTYPE=strict. /etc/sysconfig/selinux > > sym-links to /etc/selinux/config. Policy resides in > > /etc/selinux/strict/policy/. Stock FC2 kernel, 2.6.5-1.358smp. > > I've tried appending selinux in grub as well, to no avail. > > > > What minute detail am I missing? > > Update to the latest SysVinit package from the development tree. There > are also other relevant packages, e.g. usermode. That did it, thanx. Having a problem w/ sudo now however: $ rpm -q selinux-policy-strict sudo selinux-policy-strict-1.14.1-2 sudo-1.6.7p5-27 $ id uid=600(admin) gid=600(admin) groups=10(wheel),600(admin) context=user_u:user_r:user_t $ sudo sh sudo: unable to exec /usr/sbin/sesh: Permission denied $ dmesg audit(1089381994.953:0): avc: denied { execute_no_trans } for pid=845 exe=/usr/bin/sudo path=/usr/sbin/sesh dev=sda3 ino=32091 scontext=user_u:user_r:user_sudo_t tcontext=system_u:object_r:shell_exec_t tclass=file I receive the same results if running in staff_r or sysadm_r as well. ----- Kirk M. Vogelsang Northeastern University College of Computer Science From sds at epoch.ncsc.mil Fri Jul 9 16:15:58 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 09 Jul 2004 12:15:58 -0400 Subject: sudo avc denies: was Re: Upgrading to policy-strict RPM's In-Reply-To: References: <1089229788.1774.250.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1089389758.11726.54.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-07-09 at 10:18, Kirk Vogelsang wrote: > Having a problem w/ sudo now however: > > $ rpm -q selinux-policy-strict sudo > selinux-policy-strict-1.14.1-2 > sudo-1.6.7p5-27 > $ id > uid=600(admin) gid=600(admin) groups=10(wheel),600(admin) context=user_u:user_r:user_t > $ sudo sh > sudo: unable to exec /usr/sbin/sesh: Permission denied > $ dmesg > audit(1089381994.953:0): avc: denied { execute_no_trans } for pid=845 exe=/usr/bin/sudo path=/usr/sbin/sesh dev=sda3 ino=32091 scontext=user_u:user_r:user_sudo_t tcontext=system_u:object_r:shell_exec_t tclass=file > > I receive the same results if running in staff_r or sysadm_r as well. sudo is presently broken; the SELinux patch and policy for it are being reworked. Hopefully there will be something newer in rawhide soon. -- Stephen Smalley National Security Agency From kvogelsa at ccs.neu.edu Fri Jul 9 17:06:54 2004 From: kvogelsa at ccs.neu.edu (Kirk Vogelsang) Date: Fri, 9 Jul 2004 13:06:54 -0400 (EDT) Subject: sudo avc denies: was Re: Upgrading to policy-strict RPM's In-Reply-To: <1089389758.11726.54.camel@moss-spartans.epoch.ncsc.mil> References: <1089229788.1774.250.camel@moss-spartans.epoch.ncsc.mil> <1089389758.11726.54.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On Fri, 9 Jul 2004, Stephen Smalley wrote: > On Fri, 2004-07-09 at 10:18, Kirk Vogelsang wrote: > > Having a problem w/ sudo now however: > > > > $ rpm -q selinux-policy-strict sudo > > selinux-policy-strict-1.14.1-2 > > sudo-1.6.7p5-27 > > $ id > > uid=600(admin) gid=600(admin) groups=10(wheel),600(admin) context=user_u:user_r:user_t > > $ sudo sh > > sudo: unable to exec /usr/sbin/sesh: Permission denied > > $ dmesg > > audit(1089381994.953:0): avc: denied { execute_no_trans } for pid=845 exe=/usr/bin/sudo path=/usr/sbin/sesh dev=sda3 ino=32091 scontext=user_u:user_r:user_sudo_t tcontext=system_u:object_r:shell_exec_t tclass=file > > > > I receive the same results if running in staff_r or sysadm_r as well. > > sudo is presently broken; the SELinux patch and policy for it are being > reworked. Hopefully there will be something newer in rawhide soon. Thanx once again Stephen... ----- Kirk M. Vogelsang Northeastern University College of Computer Science From emf at obfuscation.org Fri Jul 9 17:28:47 2004 From: emf at obfuscation.org (Erik Fichtner) Date: Fri, 9 Jul 2004 10:28:47 -0700 Subject: sudo avc denies: was Re: Upgrading to policy-strict RPM's In-Reply-To: <1089389758.11726.54.camel@moss-spartans.epoch.ncsc.mil> References: <1089229788.1774.250.camel@moss-spartans.epoch.ncsc.mil> <1089389758.11726.54.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040709172847.GA3350@obfuscation.org> On Fri, Jul 09, 2004 at 12:15:58PM -0400, Stephen Smalley wrote: > > audit(1089381994.953:0): avc: denied { execute_no_trans } for pid=845 exe=/usr/bin/sudo path=/usr/sbin/sesh dev=sda3 ino=32091 scontext=user_u:user_r:user_sudo_t tcontext=system_u:object_r:shell_exec_t tclass=file > > > > I receive the same results if running in staff_r or sysadm_r as well. > > sudo is presently broken; the SELinux patch and policy for it are being > reworked. Hopefully there will be something newer in rawhide soon. That reminds me.... I had this same problem, and I just worked around it by allowing the avc denies for sudo, and now sudo works as I expected it to. What IS unexpected is that su changes the users' context from "user_u" (or "emf" or whatever username, naturally..) to "root"... Thus, we lose the context audit trail of who was puttering around as root. Back in the old 2.4 (pre-xattr) SELinux, su never did this (it only changed uid to 0 and left the context alone), and from my casual reading of the flask papers; this was on purpose. (ie: it was my understanding that the USER would never ever change, but the ROLE and TYPE could) So what gives? Thanks... -- Erik Fichtner; Unix Ronin From walters at redhat.com Fri Jul 9 20:33:39 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 09 Jul 2004 16:33:39 -0400 Subject: Mozilla accessing java engine yield denials In-Reply-To: <1087472582.2260.8.camel@sol800.cawthra.com> References: <1087472582.2260.8.camel@sol800.cawthra.com> Message-ID: <1089405219.30863.19.camel@nexus.verbum.private> On Thu, 2004-06-17 at 07:43 -0400, Francis K Shim wrote: > Edited to show relevant details more clearly: > > denied { execute } > exe=/bin/bash > name=java > scontext=user:staff_r:staff_mozilla_t tcontext=system_u:object_r:usr_t > tclass=file A quick fix may be to label the JVM with bin_t: chcon -t bin_t /usr/java/blah/bin/java > denied { search } > exe=/usr/java/j2re1.4.2_01/bin/java > name=vm > scontext=user:staff_r:staff_mozilla_t > tcontext=system_u:object_r:sysctl_vm_t > tclass=dir You can like likely just ignore this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From walters at redhat.com Fri Jul 9 20:38:08 2004 From: walters at redhat.com (Colin Walters) Date: Fri, 09 Jul 2004 16:38:08 -0400 Subject: policy addition for mozilla In-Reply-To: <40EE2982.1030903@mindspring.com> References: <40EE2982.1030903@mindspring.com> Message-ID: <1089405488.30863.24.camel@nexus.verbum.private> On Fri, 2004-07-09 at 01:13 -0400, Richard Hally wrote: > Attached (and below) is a diff of a one line addition for > mozilla_macros.te from the the selinux-policy-strict-sources-1.14.1-5. > > audit2allow generated the following from the avc denied messages I > received when trying to run Mozilla: allow staff_mozilla_t xdm_tmp_t:dir > { search }; Just running denials through audit2allow is generally the wrong thing. Often the denials are symptomatic of deeper problems like mislabeled files, or deep design issues (e.g. GConf), or simply bugs in the software (like mdadm opening files in /proc read/write), or configuration problems (running Postfix chrooted). In this particular case, having Mozilla able to access the XDM temporarily files is almost certainly the wrong solution. In order to diagnose it we need to know what file it was accessing (information contained in the raw dmesg output, but not in audit2allow) and what you were doing at the time. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rhally at mindspring.com Fri Jul 9 23:56:50 2004 From: rhally at mindspring.com (Richard Hally) Date: Fri, 09 Jul 2004 19:56:50 -0400 Subject: policy addition for mozilla In-Reply-To: <1089405488.30863.24.camel@nexus.verbum.private> References: <40EE2982.1030903@mindspring.com> <1089405488.30863.24.camel@nexus.verbum.private> Message-ID: <40EF30C2.1050303@mindspring.com> Colin Walters wrote: > On Fri, 2004-07-09 at 01:13 -0400, Richard Hally wrote: > >>Attached (and below) is a diff of a one line addition for >>mozilla_macros.te from the the selinux-policy-strict-sources-1.14.1-5. >> >>audit2allow generated the following from the avc denied messages I >>received when trying to run Mozilla: allow staff_mozilla_t xdm_tmp_t:dir >>{ search }; > > > Just running denials through audit2allow is generally the wrong thing. > Often the denials are symptomatic of deeper problems like mislabeled > files, or deep design issues (e.g. GConf), or simply bugs in the > software (like mdadm opening files in /proc read/write), or > configuration problems (running Postfix chrooted). > > In this particular case, having Mozilla able to access the XDM > temporarily files is almost certainly the wrong solution. In order to > diagnose it we need to know what file it was accessing (information > contained in the raw dmesg output, but not in audit2allow) and what you > were doing at the time. Here are the avc denied messages from trying to start mozilla web browser. When I say trying to start I mean clicking on the mozilla icon on the panel and watching the hour-glass cursor spin for a while and then it goes away. "nothing happens". BTW, the load_policy messages are because I had to "enableaudit" when building the policy to get the avc messages. This behavior started a couple of weeks ago. Previously mozilla had worked in enforcing mode. Also further below are a couple of avc denied messages from booting that may be related to the problem as they have to do with xdm. They refer to a different file (.ICE-unix vice .X11-unix) but may be related. There was a bug having to do with this xdm probelm (bug 127099.) Jul 8 23:51:35 new2 kernel: audit(1089345095.411:0): avc: granted { load_policy } for pid=4238 exe=/usr/sbin/load_policy scontext=root:sysadm_r:load_policy_t tcontext=system_u:object_r:security_t tclass=security Jul 8 23:51:36 new2 kernel: security: 6 users, 7 roles, 1273 types, 1 bools Jul 8 23:51:36 new2 kernel: security: 51 classes, 345889 rules Jul 8 23:52:07 new2 kernel: audit(1089345127.662:0): avc: granted { load_policy } for pid=4296 exe=/usr/sbin/load_policy scontext=root:sysadm_r:load_policy_t tcontext=system_u:object_r:security_t tclass=security Jul 8 23:52:07 new2 kernel: security: 6 users, 7 roles, 1273 types, 1 bools Jul 8 23:52:07 new2 kernel: security: 51 classes, 304966 rules Jul 8 23:52:15 new2 kernel: audit(1089345135.764:0): avc: denied { search } for pid=4315 exe=/usr/lib/mozilla-1.7/mozilla-xremote-client name=.X11-unix dev=hda2 ino=1840558 scontext=richard:staff_r:staff_mozilla_t tcontext=system_u:object_r:xdm_tmp_t tclass=dir Jul 8 23:52:15 new2 kernel: audit(1089345135.772:0): avc: denied { search } for pid=4301 exe=/usr/lib/mozilla-1.7/mozilla-xremote-client name=.X11-unix dev=hda2 ino=1840558 scontext=richard:staff_r:staff_mozilla_t tcontext=system_u:object_r:xdm_tmp_t tclass=dir from booting: Jul 8 14:45:44 new2 kernel: audit(1089312344.553:0): avc: denied { setattr } for pid=2513 exe=/usr/bin/gdm-binary name=.ICE-unix dev=hda2 ino=1840546 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:xdm_xserver_tmp_t tclass=dir Jul 8 14:45:44 new2 kernel: audit(1089312344.554:0): avc: denied { setattr } for pid=2513 exe=/usr/bin/gdm-binary name=.ICE-unix dev=hda2 ino=1840546 scontext=system_u:system_r:xdm_t tcontext=system_u:object_r:xdm_xserver_tmp_t tclass=dir HTH Richard Hally From rhallyx at mindspring.com Sat Jul 10 06:57:57 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Sat, 10 Jul 2004 02:57:57 -0400 Subject: avc denied from logrotate Message-ID: <40EF9375.9030803@mindspring.com> Attached and below is a short /var/log/messages file showing the avc denied messages that are generated using the current strict policy(selinux-policy-strict-sources-1.14.1-5). Note the messages inserted with "logger" that indicate where I switched from enforcing to permissive to actually get logrotate to work. HTH and please let me know if you need additional information. Richard Hally [root at new2 root]# cat /home/richard/messages.1 Jul 10 02:39:16 new2 syslogd 1.4.1: restart. Jul 10 02:39:23 new2 kernel: audit(1089441563.715:0): avc: granted { setenforce } for pid=4032 exe=/usr/bin/setenforce scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security Jul 10 02:40:09 new2 kernel: audit(1089441609.750:0): avc: denied { search } for pid=4045 exe=/usr/bin/postgres name=pgsql dev=hda2 ino=722952 scontext=user_u:user_r:user_t tcontext=system_u:object_r:postgresql_db_t tclass=dir Jul 10 02:43:15 new2 richard: that was logrotate in enforcing Jul 10 02:43:34 new2 richard: now setting permissive Jul 10 02:43:46 new2 kernel: audit(1089441826.619:0): avc: granted { setenforce } for pid=4101 exe=/usr/bin/setenforce scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security Jul 10 02:44:08 new2 richard: now doing logrotate Jul 10 02:44:16 new2 kernel: audit(1089441856.765:0): avc: denied { transition } for pid=4105 exe=/bin/bash path=/etc/rc.d/init.d/cups dev=hda2 ino=864571 scontext=root:sysadm_r:logrotate_t tcontext=root:system_r:initrc_t tclass=process Jul 10 02:44:16 new2 kernel: audit(1089441856.773:0): avc: denied { use } for pid=4107 exe=/sbin/consoletype path=/dev/null dev=hda2 ino=1064669 scontext=root:system_r:consoletype_t tcontext=root:sysadm_r:logrotate_t tclass=fd Jul 10 02:44:16 new2 cups: cupsd shutdown succeeded Jul 10 02:44:16 new2 kernel: audit(1089441856.913:0): avc: denied { ioctl } for pid=4114 exe=/usr/bin/python path=/dev/pts/0 dev=devpts ino=2 scontext=root:system_r:cupsd_t tcontext=root:object_r:sysadm_devpts_t tclass=chr_file Jul 10 02:44:16 new2 kernel: audit(1089441856.914:0): avc: denied { getattr } for pid=4114 exe=/usr/bin/python path=/dev/pts/0 dev=devpts ino=2 scontext=root:system_r:cupsd_t tcontext=root:object_r:sysadm_devpts_t tclass=chr_file Jul 10 02:44:17 new2 kernel: audit(1089441857.053:0): avc: denied { read } for pid=4121 exe=/bin/bash name=.bashrc dev=hda2 ino=130311 scontext=root:system_r:cupsd_t tcontext=root:object_r:staff_home_t tclass=file Jul 10 02:44:17 new2 kernel: audit(1089441857.053:0): avc: denied { getattr } for pid=4121 exe=/bin/bash path=/root/.bashrc dev=hda2 ino=130311 scontext=root:system_r:cupsd_t tcontext=root:object_r:staff_home_t tclass=file Jul 10 02:44:17 new2 kernel: audit(1089441857.056:0): avc: denied { search } for pid=4123 exe=/usr/bin/id name=selinux dev=hda2 ino=913073 scontext=root:system_r:cupsd_t tcontext=system_u:object_r:selinux_config_t tclass=dir Jul 10 02:44:17 new2 kernel: audit(1089441857.056:0): avc: denied { read } for pid=4123 exe=/usr/bin/id name=config dev=hda2 ino=914871 scontext=root:system_r:cupsd_t tcontext=system_u:object_r:selinux_config_t tclass=file Jul 10 02:44:17 new2 kernel: audit(1089441857.056:0): avc: denied { getattr } for pid=4123 exe=/usr/bin/id path=/etc/selinux/config dev=hda2 ino=914871 scontext=root:system_r:cupsd_t tcontext=system_u:object_r:selinux_config_t tclass=file Jul 10 02:44:17 new2 cups: cupsd startup succeeded -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: messages.1 URL: From rhallyx at mindspring.com Sat Jul 10 07:23:50 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Sat, 10 Jul 2004 03:23:50 -0400 Subject: avc denied from mDNSResponder Message-ID: <40EF9986.1000005@mindspring.com> When booting in enforcing mode with the latest strict policy(selinux-policy-strict-sources-1.14.1-5) the following avc denied message is produced. Jul 10 03:12:02 new2 network: Bringing up interface eth0: succeeded Jul 10 03:12:04 new2 kernel: audit(1089443524.677:0): avc: denied { name_bind } for pid=2016 exe=/usr/bin/mDNSResponder scontext=user_u:user_r:user_t tcontext=system_u:object_r:dns_port_t tclass=udp_socket HTH Richard Hally From rhallyx at mindspring.com Sat Jul 10 07:47:37 2004 From: rhallyx at mindspring.com (Richard Hally) Date: Sat, 10 Jul 2004 03:47:37 -0400 Subject: acv denied from screensaver Message-ID: <40EF9F19.80001@mindspring.com> The messages below occured while booting with the latest strict policy in enforcing mode. One of the things that is not working is the screensaver. The first message indicates that the problem with the screensaver may be related to context of files in /tmp created by xdm. Jul 10 03:13:22 new2 kernel: audit(1089443602.916:0): avc: denied { search } for pid=3288 exe=/usr/X11R6/bin/xscreensaver name=.X11-unix dev=hda2 ino=1840550 scontext=richard:staff_r:staff_screensaver_t tcontext=system_u:object_r:xdm_tmp_t tclass=dir The additional messages below may or may not be related. Jul 10 03:13:24 new2 kernel: audit(1089443604.337:0): avc: denied { create } for pid=3161 exe=/usr/bin/gnome-session scontext=richard:staff_r:staff_t tcontext=richard:staff_r:staff_t tclass=netlink_route_socket the message above repeates 5 times then: Jul 10 03:13:30 new2 kernel: audit(1089443610.307:0): avc: denied { getattr } for pid=3390 exe=/usr/libexec/gnome-vfs-daemon path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t tclass=dir Jul 10 03:13:31 new2 kernel: audit(1089443611.639:0): avc: denied { getattr } for pid=3401 exe=/usr/bin/nautilus path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t tclass=dir Jul 10 03:13:31 new2 kernel: audit(1089443611.788:0): avc: denied { getattr } for pid=3402 exe=/usr/bin/nautilus path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t tclass=dir Jul 10 03:13:36 new2 kernel: audit(1089443616.055:0): avc: denied { create } for pid=3161 exe=/usr/bin/gnome-session scontext=richard:staff_r:staff_t tcontext=richard:staff_r:staff_t tclass=netlink_route_socket Jul 10 03:15:09 new2 kernel: audit(1089443709.073:0): avc: denied { create } for pid=3161 exe=/usr/bin/gnome-session scontext=richard:staff_r:staff_t tcontext=richard:staff_r:staff_t tclass=netlink_route_socket From walters at redhat.com Sat Jul 10 16:55:26 2004 From: walters at redhat.com (Colin Walters) Date: Sat, 10 Jul 2004 12:55:26 -0400 Subject: acv denied from screensaver In-Reply-To: <40EF9F19.80001@mindspring.com> References: <40EF9F19.80001@mindspring.com> Message-ID: <1089478526.4863.22.camel@nexus.verbum.private> On Sat, 2004-07-10 at 03:47 -0400, Richard Hally wrote: > Jul 10 03:13:30 new2 kernel: audit(1089443610.307:0): avc: denied { > getattr } > for pid=3390 exe=/usr/libexec/gnome-vfs-daemon path=/initrd dev=ram0 > ino=2 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t > tclass=dir > Jul 10 03:13:31 new2 kernel: audit(1089443611.639:0): avc: denied { > getattr } > for pid=3401 exe=/usr/bin/nautilus path=/initrd dev=ram0 ino=2 > scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t > tclass=dir > Jul 10 03:13:31 new2 kernel: audit(1089443611.788:0): avc: denied { > getattr } > for pid=3402 exe=/usr/bin/nautilus path=/initrd dev=ram0 ino=2 > scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t > tclass=dir You can ignore these for now. They're a symptom of /initrd not being unmounted. I spent an hour or two trying to figure that out a while back and gave up :/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From russell at coker.com.au Sun Jul 11 06:37:36 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 11 Jul 2004 16:37:36 +1000 Subject: avc denied from logrotate In-Reply-To: <40EF9375.9030803@mindspring.com> References: <40EF9375.9030803@mindspring.com> Message-ID: <200407111637.36245.russell@coker.com.au> On Sat, 10 Jul 2004 16:57, Richard Hally wrote: > Jul 10 02:44:08 new2 richard: now doing logrotate > Jul 10 02:44:16 new2 kernel: audit(1089441856.765:0): avc: denied { > transition } for pid=4105 exe=/bin/bash path=/etc/rc.d/init.d/cups > dev=hda2 ino=864571 scontext=root:sysadm_r:logrotate_t > tcontext=root:system_r:initrc_t tclass=process The role sysadm_r is not permitted to have domain initrc_t. The options for solving this are 1: role sysadm_r types initrc_t; 2: role_transition sysadm_r initrc_exec_t system_r; domain_auto_trans(sysadm_t, initrc_exec_t, initrc_t) 3: role_transition sysadm_r logrotate_exec_t system_r; In option 2 the domain_auto_trans() is needed to prevent the command /etc/init.d/whatever from ending up in the context root:system_r:sysadm_t which is not a valid context. The problem with option 1 is that initrc_t then launches other domains so it doesn't work. Steve, what do you think about option 2 vs option 3? > Jul 10 02:44:16 new2 kernel: audit(1089441856.773:0): avc: denied { > use } for pid=4107 exe=/sbin/consoletype path=/dev/null dev=hda2 > ino=1064669 scontext=root:system_r:consoletype_t > tcontext=root:sysadm_r:logrotate_t tclass=fd I guess we need a dontaudit rule for that as there is: can_exec(logrotate_t, consoletype_exec_t) So I put the following in logrotate.te: dontaudit consoletype_t logrotate_t:fd use; > Jul 10 02:44:16 new2 cups: cupsd shutdown succeeded > Jul 10 02:44:16 new2 kernel: audit(1089441856.913:0): avc: denied { > ioctl } for pid=4114 exe=/usr/bin/python path=/dev/pts/0 dev=devpts > ino=2 scontext=root:system_r:cupsd_t > tcontext=root:object_r:sysadm_devpts_t tclass=chr_file > Jul 10 02:44:16 new2 kernel: audit(1089441856.914:0): avc: denied { > getattr } for pid=4114 exe=/usr/bin/python path=/dev/pts/0 dev=devpts > ino=2 scontext=root:system_r:cupsd_t > tcontext=root:object_r:sysadm_devpts_t tclass=chr_file The attached patch takes care of that. > Jul 10 02:44:17 new2 kernel: audit(1089441857.053:0): avc: denied { > read } for pid=4121 exe=/bin/bash name=.bashrc dev=hda2 ino=130311 > scontext=root:system_r:cupsd_t tcontext=root:object_r:staff_home_t > tclass=file In enforcing mode access to the parent directory is denied and that file will never be accessed. > Jul 10 02:44:17 new2 kernel: audit(1089441857.056:0): avc: denied { > read } for pid=4123 exe=/usr/bin/id name=config dev=hda2 ino=914871 > scontext=root:system_r:cupsd_t > tcontext=system_u:object_r:selinux_config_t tclass=file Maybe we should change id to read /proc/self/attr/current directly? We don't want to have to put in allow or dontaudit rules for every shell script that runs "id". -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-diff Size: 326 bytes Desc: not available URL: From russell at coker.com.au Sun Jul 11 06:40:29 2004 From: russell at coker.com.au (Russell Coker) Date: Sun, 11 Jul 2004 16:40:29 +1000 Subject: avc denied from mDNSResponder In-Reply-To: <40EF9986.1000005@mindspring.com> References: <40EF9986.1000005@mindspring.com> Message-ID: <200407111640.29243.russell@coker.com.au> On Sat, 10 Jul 2004 17:23, Richard Hally wrote: > When booting in enforcing mode with the latest strict > policy(selinux-policy-strict-sources-1.14.1-5) > the following avc denied message is produced. > > Jul 10 03:12:02 new2 network: Bringing up interface eth0: succeeded > Jul 10 03:12:04 new2 kernel: audit(1089443524.677:0): avc: denied { > name_bind > } for pid=2016 exe=/usr/bin/mDNSResponder scontext=user_u:user_r:user_t > tcontext=system_u:object_r:dns_port_t tclass=udp_socket What is this /usr/bin/mDNSResponder and where do I find an RPM for it? Binding to port 53 is an operation for a daemon, why is it happening in user_r:user_t? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From dennis at ausil.us Sun Jul 11 06:54:56 2004 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 11 Jul 2004 01:54:56 -0500 Subject: avc denied from mDNSResponder In-Reply-To: <200407111640.29243.russell@coker.com.au> References: <40EF9986.1000005@mindspring.com> <200407111640.29243.russell@coker.com.au> Message-ID: <200407110154.56220.dennis@ausil.us> Once upon a time Sunday 11 July 2004 1:40 am, Russell Coker wrote: > On Sat, 10 Jul 2004 17:23, Richard Hally wrote: > > When booting in enforcing mode with the latest strict > > policy(selinux-policy-strict-sources-1.14.1-5) > > the following avc denied message is produced. > > > > Jul 10 03:12:02 new2 network: Bringing up interface eth0: succeeded > > Jul 10 03:12:04 new2 kernel: audit(1089443524.677:0): avc: denied { > > name_bind > > } for pid=2016 exe=/usr/bin/mDNSResponder scontext=user_u:user_r:user_t > > tcontext=system_u:object_r:dns_port_t tclass=udp_socket > > What is this /usr/bin/mDNSResponder and where do I find an RPM for it? > > Binding to port 53 is an operation for a daemon, why is it happening in > user_r:user_t? mDNS is a bind replacement and it was probably built and installed from source is my guess. Fedora does not ship it Dennis From rhally at mindspring.com Sun Jul 11 07:38:56 2004 From: rhally at mindspring.com (Richard Hally) Date: Sun, 11 Jul 2004 03:38:56 -0400 Subject: avc denied from mDNSResponder In-Reply-To: <200407111640.29243.russell@coker.com.au> References: <40EF9986.1000005@mindspring.com> <200407111640.29243.russell@coker.com.au> Message-ID: <40F0EE90.2080602@mindspring.com> Russell Coker wrote: > On Sat, 10 Jul 2004 17:23, Richard Hally wrote: > >>When booting in enforcing mode with the latest strict >>policy(selinux-policy-strict-sources-1.14.1-5) >>the following avc denied message is produced. >> >>Jul 10 03:12:02 new2 network: Bringing up interface eth0: succeeded >>Jul 10 03:12:04 new2 kernel: audit(1089443524.677:0): avc: denied { >>name_bind >>} for pid=2016 exe=/usr/bin/mDNSResponder scontext=user_u:user_r:user_t >>tcontext=system_u:object_r:dns_port_t tclass=udp_socket > > > What is this /usr/bin/mDNSResponder and where do I find an RPM for it? > howl-0.9.5-4 was added to /development within the last two weeks. > Binding to port 53 is an operation for a daemon, why is it happening in > user_r:user_t? > It probably does not have any policy written for it yet! Richard Hally From pnasrat at redhat.com Sun Jul 11 09:00:26 2004 From: pnasrat at redhat.com (Paul Nasrat) Date: Sun, 11 Jul 2004 05:00:26 -0400 Subject: avc denied from mDNSResponder In-Reply-To: <200407110154.56220.dennis@ausil.us> References: <40EF9986.1000005@mindspring.com> <200407111640.29243.russell@coker.com.au> <200407110154.56220.dennis@ausil.us> Message-ID: <20040711090025.GA16248@devserv.devel.redhat.com> On Sun, Jul 11, 2004 at 01:54:56AM -0500, Dennis Gilmore wrote: > Once upon a time Sunday 11 July 2004 1:40 am, Russell Coker wrote: > > What is this /usr/bin/mDNSResponder and where do I find an RPM for it? > > > > Binding to port 53 is an operation for a daemon, why is it happening in > > user_r:user_t? > > mDNS is a bind replacement and it was probably built and installed from > source is my guess. Fedora does not ship it It's not a bind replacement it's a multicast dns implementation, related to zeroconf: http://www.multicastdns.org/ Basically that plus link level configuration, plus service discovery == Rendezvous. Paul From sds at epoch.ncsc.mil Mon Jul 12 12:12:54 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 08:12:54 -0400 Subject: sudo avc denies: was Re: Upgrading to policy-strict RPM's In-Reply-To: <20040709172847.GA3350@obfuscation.org> References: <1089229788.1774.250.camel@moss-spartans.epoch.ncsc.mil> <1089389758.11726.54.camel@moss-spartans.epoch.ncsc.mil> <20040709172847.GA3350@obfuscation.org> Message-ID: <1089634374.22449.23.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-07-09 at 13:28, Erik Fichtner wrote: > That reminds me.... I had this same problem, and I just worked around > it by allowing the avc denies for sudo, and now sudo works as I > expected it to. The original poster showed a denial of executing sesh from user_sudo_t without performing a domain transition. That is definitely not what you want. sudo should transition to a user domain upon executing sesh, most typically to sysadm_r:sysadm_t since it is typically used to assume admin privileges for a particular command. Further, as the caller is typically not directly authorized for an administrative shell, you need sudo to transition to a user identity (e.g. root) that is authorized for the administrative role. > What IS unexpected is that su changes the users' context from "user_u" > (or "emf" or whatever username, naturally..) to "root"... Thus, we lose > the context audit trail of who was puttering around as root. > > Back in the old 2.4 (pre-xattr) SELinux, su never did this (it only > changed uid to 0 and left the context alone), and from my casual reading > of the flask papers; this was on purpose. (ie: it was my understanding > that the USER would never ever change, but the ROLE and TYPE could) > > So what gives? As part of the Fedora SELinux integration, RedHat created a pam_selinux module and changed /etc/pam.d/su to invoke it, so that su performs context transitions, including changing the user identity. Note that the user_canbe_sysadm tunable allows you to disable the ability of user_r:user_t to reach sysadm_r:sysadm_t via su, so that only users authorized for staff_r can do so. That reduces your exposure. See the following for further discussion: http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/index.html#id3004527 http://marc.theaimsgroup.com/?l=selinux&m=107757717110966&w=2 And an argument against have su perform context transitions: http://marc.theaimsgroup.com/?l=selinux&m=107765457418746&w=2 Note that the use of pam_selinux by su has also led to issues with running daemons in pseudo user identities via su, as discussed previously on this list. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jul 12 12:20:32 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 08:20:32 -0400 Subject: avc denied from logrotate In-Reply-To: <200407111637.36245.russell@coker.com.au> References: <40EF9375.9030803@mindspring.com> <200407111637.36245.russell@coker.com.au> Message-ID: <1089634832.22449.32.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2004-07-11 at 02:37, Russell Coker wrote: > On Sat, 10 Jul 2004 16:57, Richard Hally wrote: > > Jul 10 02:44:08 new2 richard: now doing logrotate > > Jul 10 02:44:16 new2 kernel: audit(1089441856.765:0): avc: denied { > > transition } for pid=4105 exe=/bin/bash path=/etc/rc.d/init.d/cups > > dev=hda2 ino=864571 scontext=root:sysadm_r:logrotate_t > > tcontext=root:system_r:initrc_t tclass=process > > The role sysadm_r is not permitted to have domain initrc_t. The options for > solving this are 1: > role sysadm_r types initrc_t; > 2: > role_transition sysadm_r initrc_exec_t system_r; > domain_auto_trans(sysadm_t, initrc_exec_t, initrc_t) > 3: > role_transition sysadm_r logrotate_exec_t system_r; > > In option 2 the domain_auto_trans() is needed to prevent the > command /etc/init.d/whatever from ending up in the context > root:system_r:sysadm_t which is not a valid context. > > The problem with option 1 is that initrc_t then launches other domains so it > doesn't work. > > Steve, what do you think about option 2 vs option 3? The policy is already set up for sysadm_r:logrotate_t to transition to system_r:initrc_t upon executing init scripts; logrotate.te includes domain_auto_trans(logrotate_t, initrc_exec_t, initrc_t), and initrc.te includes role_transition sysadm_r initrc_exec_t system_r;. The only item missing is that logrotate_t needs the priv_system_role attribute for the corresponding constraint. That is all that needs to be changed. > > Jul 10 02:44:17 new2 kernel: audit(1089441857.056:0): avc: denied { > > read } for pid=4123 exe=/usr/bin/id name=config dev=hda2 ino=914871 > > scontext=root:system_r:cupsd_t > > tcontext=system_u:object_r:selinux_config_t tclass=file > > Maybe we should change id to read /proc/self/attr/current directly? We don't > want to have to put in allow or dontaudit rules for every shell script that > runs "id". libselinux attempts to read /etc/selinux/config upon initialization, but only truly needs access if the program will ultimately need a path to a policy file (either directly or due to a call to a libselinux function that reads a policy file). I don't think id falls into this category, so you can just dontaudit the permission. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jul 12 12:53:13 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 08:53:13 -0400 Subject: avc denied from mDNSResponder In-Reply-To: <40EF9986.1000005@mindspring.com> References: <40EF9986.1000005@mindspring.com> Message-ID: <1089636792.22449.44.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2004-07-10 at 03:23, Richard Hally wrote: > When booting in enforcing mode with the latest strict > policy(selinux-policy-strict-sources-1.14.1-5) > the following avc denied message is produced. > > Jul 10 03:12:02 new2 network: Bringing up interface eth0: succeeded > Jul 10 03:12:04 new2 kernel: audit(1089443524.677:0): avc: denied { > name_bind > } for pid=2016 exe=/usr/bin/mDNSResponder scontext=user_u:user_r:user_t > tcontext=system_u:object_r:dns_port_t tclass=udp_socket The fact that it is running in user_u likely means that it is being started via su (to run in some pseudo user identity), and since that pseudo user identity does not exist in the policy, it is being remapped to user_u. -- Stephen Smalley National Security Agency From emf at obfuscation.org Mon Jul 12 13:14:20 2004 From: emf at obfuscation.org (Erik Fichtner) Date: Mon, 12 Jul 2004 06:14:20 -0700 Subject: sudo avc denies: was Re: Upgrading to policy-strict RPM's In-Reply-To: <1089634374.22449.23.camel@moss-spartans.epoch.ncsc.mil> References: <1089229788.1774.250.camel@moss-spartans.epoch.ncsc.mil> <1089389758.11726.54.camel@moss-spartans.epoch.ncsc.mil> <20040709172847.GA3350@obfuscation.org> <1089634374.22449.23.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20040712131420.GB3350@obfuscation.org> On Mon, Jul 12, 2004 at 08:12:54AM -0400, Stephen Smalley wrote: > The original poster showed a denial of executing sesh from user_sudo_t > without performing a domain transition. That is definitely not what you > want. sudo should transition to a user domain upon executing sesh, most > typically to sysadm_r:sysadm_t since it is typically used to assume > admin privileges for a particular command. Actually, the user should newrole to sysadm_r before they're allowed to execute sudo/su. Or, if you want to make life easier for the user, sudo/su could be allowed to perform a role transition on its own, but it should *never* change the identity. > Further, as the caller is > typically not directly authorized for an administrative shell, you need > sudo to transition to a user identity (e.g. root) that is authorized for > the administrative role. Nonsense. you can allow your IDENTITIES (context users) to have the ability to attain an administrative role which then lets them have the completely orthogonal USER (unix user id). It seems that Fedora/SELinux is attempting to entirely replace the uid/gid concept instead of augmenting it; and in the process appears to have misplaced the difference between uid and euid. (which is not to say that uid/euid ever really worked right in unix) [ For example, the system really SHOULD know the difference between user "emf" su'ing to user "joe" and running joe's .bashrc. When I do that, I am not joe, I am merely impersonating him for some reason. ] uid/gid isn't what's wrong with unix authentication; "root" is. [ "root" meaning shared identities; privleged or otherwise. ] > As part of the Fedora SELinux integration, RedHat created a pam_selinux > module and changed /etc/pam.d/su to invoke it, so that su performs > context transitions, including changing the user identity. Note that > the user_canbe_sysadm tunable allows you to disable the ability of > user_r:user_t to reach sysadm_r:sysadm_t via su, so that only users > authorized for staff_r can do so. That reduces your exposure. See the > following for further discussion: > > http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/index.html#id3004527 > http://marc.theaimsgroup.com/?l=selinux&m=107757717110966&w=2 > > And an argument against have su perform context transitions: > http://marc.theaimsgroup.com/?l=selinux&m=107765457418746&w=2 > > Note that the use of pam_selinux by su has also led to issues with > running daemons in pseudo user identities via su, as discussed > previously on this list. I find that I must agree with the dissenting viewpoint. Changing the identity is a terrible idea. Having daemons running in pseudouser identities could just as well be handled by having unix_uid along with an unprivleged user_u identity and a ${daemon}_r:${daemon}_t context. We don't need ${daemon}_u as well, and user_u can do far too much by default in FC2. It would be really nice if this were a tunable as well, since some folks appear to want the identity transition, but I personally think that the "Strict" configuration should disable ID transition. That's all. -- Erik Fichtner; Unix Ronin From sds at epoch.ncsc.mil Mon Jul 12 13:26:18 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 09:26:18 -0400 Subject: sudo avc denies: was Re: Upgrading to policy-strict RPM's In-Reply-To: <20040712131420.GB3350@obfuscation.org> References: <1089229788.1774.250.camel@moss-spartans.epoch.ncsc.mil> <1089389758.11726.54.camel@moss-spartans.epoch.ncsc.mil> <20040709172847.GA3350@obfuscation.org> <1089634374.22449.23.camel@moss-spartans.epoch.ncsc.mil> <20040712131420.GB3350@obfuscation.org> Message-ID: <1089638778.22449.64.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-07-12 at 09:14, Erik Fichtner wrote: > Actually, the user should newrole to sysadm_r before they're allowed to > execute sudo/su. Or, if you want to make life easier for the user, > sudo/su could be allowed to perform a role transition on its own, but > it should *never* change the identity. That requires that the original SELinux user identity be authorized for sysadm_r in the first place, in which case he can directly login or newrole to sysadm_r. That is contrary to the model for sudo, where you want to authorize the user to perform specific tasks with admin privileges without giving him access to a full admin shell. > Nonsense. you can allow your IDENTITIES (context users) to have the > ability to attain an administrative role which then lets them have the > completely orthogonal USER (unix user id). Not sure we are communicating here. If the SELinux user identity is authorized for sysadm_r, then he can directly login or newrole to sysadm_r and run anything in sysadm_r (that is executable by sysadm_t). sudo is supposed to let you authorize a given user to perform a specific command with admin privileges without giving them full administrative access. > [ For example, the system really SHOULD know the difference between > user "emf" su'ing to user "joe" and running joe's .bashrc. When I do > that, I am not joe, I am merely impersonating him for some reason. ] Yes, but as joe's .bashrc is under his control, you don't want to run it with your own set of privileges. > It would be really nice if this were a tunable as well, since some > folks appear to want the identity transition, but I personally think > that the "Strict" configuration should disable ID transition. Easy enough to support in the policy, but you would also need a different /etc/pam.d/su depending on your policy. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jul 12 14:13:42 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 10:13:42 -0400 Subject: FC3... install/update ? In-Reply-To: <40ED8473.4080203@comcast.net> References: <40ED8473.4080203@comcast.net> Message-ID: <1089641622.22449.117.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-08 at 13:29, Tom London wrote: > With FC3 about to descend, anyone know if updates > from FC2 will be supported? Only clean installs? Caveat: I think you need to do a 'yum upgrade' rather than a 'yum update' from FC2 to pick up the policy -> selinux-policy-strict update. A 'yum update' seems to leave the old policy package unchanged, while pulling in the newer SysVinit, libselinux, and policycoreutils (which do still work with the older policy package, but that isn't likely what you want). -- Stephen Smalley National Security Agency From selinux at comcast.net Mon Jul 12 14:46:51 2004 From: selinux at comcast.net (Tom London) Date: Mon, 12 Jul 2004 07:46:51 -0700 Subject: FC3... install/update ? Message-ID: <40F2A45B.30507@comcast.net> Thanks. I have 3 systems: one running 'stock' FC2, the other 2 running off the development and Arjan's tree. I'll try the 'yum update' on the stock system. I'm assuming (hoping?) that the 'bleeding edge' systems will just update (i.e., 'yum update') smoothly..... (they've already lost the '2' from the login splash screen, and yum.conf has been updated to point only at the development tree). FC2T1 clean install had issues with SELinux installs (home directories not properly labeled, ...). The bugzilla entry for this (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123856) is not closed.... Has this been fixed? Need testing? tom > ------------------------------------------------------------------------ > > * /From/: Stephen Smalley > * /To/: "Fedora SELinux support list for users & developers." > > * /Subject/: Re: FC3... install/update ? > * /Date/: Mon, 12 Jul 2004 10:13:42 -0400 > > ------------------------------------------------------------------------ > >On Thu, 2004-07-08 at 13:29, Tom London wrote: >> With FC3 about to descend, anyone know if updates >> from FC2 will be supported? Only clean installs? > >Caveat: I think you need to do a 'yum upgrade' rather than a 'yum >update' from FC2 to pick up the policy -> selinux-policy-strict update. >A 'yum update' seems to leave the old policy package unchanged, while >pulling in the newer SysVinit, libselinux, and policycoreutils (which do >still work with the older policy package, but that isn't likely what you >want). > >-- >Stephen Smalley >National Security Agency > > > From sds at epoch.ncsc.mil Mon Jul 12 14:55:09 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 10:55:09 -0400 Subject: sudo avc denies: was Re: Upgrading to policy-strict RPM's In-Reply-To: <20040712131420.GB3350@obfuscation.org> References: <1089229788.1774.250.camel@moss-spartans.epoch.ncsc.mil> <1089389758.11726.54.camel@moss-spartans.epoch.ncsc.mil> <20040709172847.GA3350@obfuscation.org> <1089634374.22449.23.camel@moss-spartans.epoch.ncsc.mil> <20040712131420.GB3350@obfuscation.org> Message-ID: <1089644108.22449.190.camel@moss-spartans.epoch.ncsc.mil> One other note on this topic: Most Fedora SELinux users are not maintaining policy/users at present for individual users (beyond system_u/user_u/root distinctions) due to the lack of integrated user management, so they cannot take full advantage of the SELinux user identity and user-role authorizations. setools and setools-gui provide some help in this area, but not if you are using a distributed user database like NIS or LDAP. As a consequence, the typical approach among older SELinux users of individually authorizing staff users for staff_r and sysadm_r is problematic for the typical Fedora SELinux user. -- Stephen Smalley National Security Agency From tweeksjunk2 at theweeks.org Sun Jul 11 07:33:09 2004 From: tweeksjunk2 at theweeks.org (Tom Weeks) Date: Sun, 11 Jul 2004 02:33:09 -0500 Subject: Best Source to learn more about seLinux? Message-ID: <200407110233.09623.tweeksjunk2@theweeks.org> Hey guys... I need to come up to speed fast on seLinux... What's the best source to dive into for this? Tweeks From FMarsolais at gpinet.com Mon Jul 12 11:30:34 2004 From: FMarsolais at gpinet.com (Frank Marsolais) Date: Mon, 12 Jul 2004 07:30:34 -0400 Subject: avc denied messages from boot Message-ID: I found the following in the archives. I upgraded from rh7.2 to 9.0 to fedora 2. When I put in rpm -q policy policy-sources I received back # rpm -q policy policy-sources policy-1.11.3-3 package policy-sources is not installed Should I download policy-sources or is something else broken? For the -12 policy would that be 1.12 or 1.9.2-12? My error messages look like the following: Jul 11 09:50:02 gpi04 kernel: security: 30 classes, 303377 rules Jul 11 09:50:02 gpi04 kernel: SELinux: Completing initialization. Jul 11 09:50:02 gpi04 kernel: SELinux: Setting up existing superblocks. Jul 11 09:50:02 gpi04 kernel: SELinux: initialized (dev , type selinuxfs), uses genfs_contexts Jul 11 09:50:02 gpi04 kernel: SELinux: initialized (dev sda5, type ext3), uses xattr Jul 11 09:50:02 gpi04 kernel: SELinux: initialized (dev ram0, type ext2), uses xattr Jul 11 09:50:02 gpi04 kernel: SELinux: initialized (dev , type mqueue), not configured for labeling Jul 11 09:50:02 gpi04 kernel: SELinux: initialized (dev , type hugetlbfs), not configured for labeling Jul 11 09:50:02 gpi04 kernel: SELinux: initialized (dev , type devpts), uses transition SIDs Jul 11 09:50:02 gpi04 kernel: SELinux: initialized (dev , type eventpollfs), uses genfs_contexts Jul 11 09:50:02 gpi04 kernel: SELinux: initialized (dev , type pipefs), uses task SIDs Jul 11 09:50:02 gpi04 kernel: SELinux: initialized (dev , type tmpfs), uses transition SIDs Jul 11 09:50:03 gpi04 kernel: SELinux: initialized (dev , type futexfs), uses genfs_contexts Jul 11 09:50:03 gpi04 kernel: SELinux: initialized (dev , type sockfs), uses task SIDs Jul 11 09:50:03 gpi04 kernel: SELinux: initialized (dev , type proc), uses genfs_contexts Jul 11 09:50:03 gpi04 kernel: SELinux: initialized (dev , type bdev), uses genfs_contexts Jul 11 09:50:03 gpi04 kernel: SELinux: initialized (dev , type rootfs), uses genfs_contexts Jul 11 09:50:03 gpi04 kernel: SELinux: initialized (dev , type sysfs), uses genfs_contexts Jul 11 09:50:03 gpi04 kernel: audit(1089539246.326:0): avc: denied { read write } for pid=1 exe=/sbin/init path=/dev/console d Jul 11 09:50:03 gpi04 kernel: audit(1089539246.326:0): avc: denied { read } for pid=1 exe=/sbin/init name=libselinux.so.1 dev= Jul 11 09:50:03 gpi04 kernel: audit(1089539246.326:0): avc: denied { getattr } for pid=1 exe=/sbin/init path=/lib/libselinux.s Jul 11 09:50:03 gpi04 kernel: audit(1089539246.326:0): avc: denied { execute } for pid=1 path=/lib/libselinux.so.1 dev=sda5 in Jul 11 09:50:03 gpi04 kernel: audit(1089539246.326:0): avc: denied { read } for pid=1 exe=/sbin/init name=libc.so.6 dev=sda5 i Jul 11 09:50:03 gpi04 kernel: audit(1089539246.327:0): avc: denied { ioctl } for pid=1 exe=/sbin/init path=/dev/tty0 dev=sda5 Jul 11 09:50:03 gpi04 kernel: audit(1089539246.545:0): avc: denied { lock } for pid=1 exe=/sbin/init path=/var/run/utmp dev=sd Jul 11 09:50:03 gpi04 kernel: audit(1089539246.603:0): avc: denied { getattr } for pid=1 exe=/sbin/init path=/dev/initctl dev= Jul 11 09:50:03 gpi04 kernel: audit(1089539246.603:0): avc: denied { read write } for pid=1 exe=/sbin/init name=initctl dev=sd Jul 11 09:50:03 gpi04 kernel: audit(1089539246.612:0): avc: denied { execute_no_trans } for pid=287 exe=/sbin/init path=/etc/r Jul 11 09:50:03 gpi04 kernel: audit(1089539246.618:0): avc: denied { ioctl } for pid=287 exe=/bin/bash path=/etc/rc.d/rc.sysin Jul 11 09:50:03 gpi04 kernel: audit(1089539246.658:0): avc: denied { getattr } for pid=287 exe=/bin/bash path=/ dev=sda5 ino=2 Jul 11 09:50:03 gpi04 kernel: audit(1089539246.675:0): avc: denied { execute } for pid=293 exe=/bin/bash name=hostname dev=sda Jul 11 09:50:03 gpi04 kernel: audit(1089539246.675:0): avc: denied { execute_no_trans } for pid=293 exe=/bin/bash path=/bin/ho Jul 11 09:50:03 gpi04 kernel: audit(1089539246.747:0): avc: denied { getattr } for pid=298 exe=/bin/gawk path=/dev/console dev Jul 11 09:50:03 gpi04 kernel: audit(1089539246.791:0): avc: denied { mounton } for pid=299 exe=/bin/mount path=/proc dev=sda5 Jul 11 09:50:03 gpi04 kernel: audit(1089539246.791:0): avc: denied { mount } for pid=299 exe=/bin/mount name=/ dev= ino=1 scon Jul 11 09:50:03 gpi04 kernel: audit(1089539246.792:0): avc: denied { mount } for pid=300 exe=/bin/mount name=/ dev= ino=1 scon Jul 11 09:50:03 gpi04 xinetd[2420]: xinetd Version 2.3.13 started with libwrap loadavg options compiled in. Jul 11 09:50:03 gpi04 kernel: audit(1089539247.894:0): avc: denied { read } for pid=453 exe=/bin/setfont dev=sda5 ino=2 sconte Jul 11 09:50:03 gpi04 xinetd[2420]: Started working: 2 available services Jul 11 09:50:03 gpi04 kernel: audit(1089539247.990:0): avc: denied { syslog_console } for pid=459 exe=/bin/dmesg scontext=syst Jul 11 09:50:03 gpi04 kernel: audit(1089539248.012:0): avc: denied { mount } for pid=460 exe=/bin/mount name=/ dev= ino=1 scon Jul 11 09:50:03 gpi04 kernel: audit(1089539248.053:0): avc: denied { search } for pid=463 exe=/sbin/sysctl name=sys dev= ino=- Jul 11 09:50:03 gpi04 kernel: audit(1089539248.053:0): avc: denied { search } for pid=463 exe=/sbin/sysctl name=net dev= ino=- Jul 11 09:50:03 gpi04 kernel: audit(1089539248.053:0): avc: denied { write } for pid=463 exe=/sbin/sysctl name=ip_forward dev= Jul 11 09:50:03 gpi04 kernel: audit(1089539248.053:0): avc: denied { getattr } for pid=463 exe=/sbin/sysctl path=/proc/sys/net Jul 11 09:50:03 gpi04 kernel: audit(1089539248.053:0): avc: denied { search } for pid=463 exe=/sbin/sysctl name=kernel dev= in Jul 11 09:50:03 gpi04 kernel: audit(1089539248.053:0): avc: denied { write } for pid=463 exe=/sbin/sysctl name=sysrq dev= ino= Jul 11 09:50:03 gpi04 kernel: audit(1089539248.053:0): avc: denied { getattr } for pid=463 exe=/sbin/sysctl path=/proc/sys/ker Jul 11 09:50:04 gpi04 kernel: audit(1089553650.032:0): avc: denied { read } for pid=470 exe=/bin/date scontext=system_u:system Jul 11 09:50:04 gpi04 kernel: audit(1089553650.256:0): avc: denied { sys_module } for pid=483 exe=/sbin/insmod capability=16 s Jul 11 09:50:04 gpi04 kernel: ACPI: Power Button (FF) [PWRF] Jul 11 09:50:04 gpi04 kernel: audit(1089553650.288:0): avc: denied { read } for pid=489 exe=/sbin/insmod name=modprobe.conf.di Jul 11 09:50:04 gpi04 kernel: audit(1089553650.288:0): avc: denied { getattr } for pid=489 exe=/sbin/insmod path=/etc/modprobe Jul 11 09:50:04 gpi04 kernel: ohci_hcd 0000:00:0f.2: OHCI Host Controller Jul 11 09:50:04 gpi04 kernel: ohci_hcd 0000:00:0f.2: irq 7, pci mem 22831000 Jul 11 09:50:04 gpi04 kernel: SELinux: initialized (dev , type usbdevfs), uses genfs_contexts Jul 11 09:50:04 gpi04 kernel: audit(1089553650.469:0): avc: denied { mount } for pid=493 exe=/sbin/insmod name=/ dev= ino=1195 Jul 11 09:50:04 gpi04 kernel: SELinux: initialized (dev , type usbfs), uses genfs_contexts Jul 11 09:50:04 gpi04 kernel: audit(1089553650.469:0): avc: denied { mount } for pid=493 exe=/sbin/insmod name=/ dev= ino=1196 Jul 11 09:50:04 gpi04 kernel: audit(1089553650.469:0): avc: denied { search } for pid=493 exe=/sbin/insmod dev= ino=1196 scont Jul 11 09:50:04 gpi04 kernel: audit(1089553650.469:0): avc: denied { search } for pid=493 exe=/sbin/insmod dev= ino=1195 scont Jul 11 09:50:04 gpi04 kernel: ohci_hcd 0000:00:0f.2: new USB bus registered, assigned bus number 1 Jul 11 09:50:04 gpi04 kernel: hub 1-0:1.0: USB hub found Jul 11 09:50:04 gpi04 kernel: hub 1-0:1.0: 2 ports detected Jul 11 09:50:04 gpi04 kernel: audit(1089553650.506:0): avc: denied { mounton } for pid=507 exe=/bin/mount path=/proc/bus/usb d Jul 11 09:50:04 gpi04 kernel: audit(1089553650.511:0): avc: denied { read } for pid=510 exe=/bin/grep name=devices dev= ino=11 Jul 11 09:50:04 gpi04 kernel: audit(1089553650.511:0): avc: denied { getattr } for pid=510 exe=/bin/grep path=/proc/bus/usb/de Jul 11 09:50:04 gpi04 kernel: audit(1089553650.527:0): avc: denied { getattr } for pid=500 exe=/bin/bash path=/sys/devices/pci Jul 11 09:50:04 gpi04 kernel: audit(1089553650.528:0): avc: denied { read } for pid=516 exe=/bin/cat name=bNumConfigurations d Jul 11 09:50:04 gpi04 kernel: audit(1089553650.553:0): avc: denied { getattr } for pid=287 exe=/bin/bash path=/forcefsck dev=s Jul 11 09:50:04 gpi04 kernel: audit(1089553650.560:0): avc: denied { getattr } for pid=287 exe=/bin/bash path=/initrd/dev/root Jul 11 09:50:04 gpi04 kernel: audit(1089553650.567:0): avc: denied { getattr } for pid=521 exe=/usr/bin/readlink path=/sys dev Jul 11 09:50:04 gpi04 kernel: audit(1089553650.991:0): avc: denied { read } for pid=526 exe=/sbin/fsck name=sda5 dev=sda5 ino= Jul 11 09:50:04 gpi04 kernel: audit(1089553650.991:0): avc: denied { getattr } for pid=526 exe=/sbin/fsck path=/dev/sda5 dev=s Jul 11 09:50:04 gpi04 kernel: audit(1089553651.014:0): avc: denied { read } for pid=526 exe=/sbin/fsck name=root dev=ram0 ino= Jul 11 09:50:04 gpi04 kernel: audit(1089553651.014:0): avc: denied { ioctl } for pid=526 exe=/sbin/fsck path=/initrd/dev/root Jul 11 09:50:04 gpi04 kernel: audit(1089553651.091:0): avc: denied { write } for pid=536 exe=/sbin/fsck.ext2 name=root dev=ram Jul 11 09:50:04 gpi04 kernel: audit(1089553771.892:0): avc: denied { unmount } for pid=1056 exe=/bin/umount scontext=system_u: Jul 11 09:50:04 gpi04 kernel: audit(1089553771.912:0): avc: denied { ioctl } for pid=1057 exe=/sbin/blockdev path=/dev/ram0 de Jul 11 09:50:04 gpi04 kernel: audit(1089553772.043:0): avc: denied { remount } for pid=1063 exe=/bin/mount scontext=system_u:s Jul 11 09:50:04 gpi04 kernel: EXT3 FS on sda5, internal journal Jul 11 09:50:04 gpi04 kernel: audit(1089553772.062:0): avc: denied { write } for pid=1065 exe=/sbin/minilogd name=dev dev=sda5 Jul 11 09:50:04 gpi04 kernel: audit(1089553772.062:0): avc: denied { add_name } for pid=1065 exe=/sbin/minilogd name=log scont Jul 11 09:50:05 gpi04 kernel: audit(1089553772.062:0): avc: denied { create } for pid=1065 exe=/sbin/minilogd name=log scontex Jul 11 09:50:05 gpi04 kernel: audit(1089553772.062:0): avc: denied { listen } for pid=1065 exe=/sbin/minilogd path=/dev/log sc Jul 11 09:50:05 gpi04 kernel: audit(1089553772.062:0): avc: denied { getattr } for pid=1067 exe=/sbin/minilogd path=/dev/log I know I am very green when it comes to this; A point in the right direction would be greatly appreciated, even a suggested FAQ to read. TIA Frank Marsolais The original message I found follows: ***************************************************************************************** ***************************************************************************************** Re: avc denied messages from boot -------------------------------------------------------------------------------- From: Richard Hally To: "Fedora SELinux support list for users & developers." Subject: Re: avc denied messages from boot Date: Tue, 06 Apr 2004 12:53:04 -0400 -------------------------------------------------------------------------------- Daniel J Walsh wrote: Richard Hally wrote: when booting to runlevel 5 in enforcing mode with the latest policy there were only a few AVC denied messages. they are copied below. [root localhost root]# rpm -q policy policy-sources policy-1.9.2-10 policy-sources-1.9.2-10 [root localhost root]# Hope this helps, Richard Hally There is a bug in the init scripts that leaves /initrd mounted. If you umount this directory most of these messages will disappear. The screensaver ones should be fixed by -12 policy Not sure why gnome is trying to manipulate the registry.xml file. --------------------messages----------------------------- Apr 5 22:37:25 localhost crond: crond startup succeeded Apr 5 22:37:25 localhost kernel: audit(1081219045.889:0): avc: denied { read } for pid=1647 exe=/usr/sbin/crond name=mailman dev=hdc3 ino=539689 scontext=system_u:system_r:crond_t tcontext=system_u:object_r:file_t tclass=file Apr 5 22:37:27 localhost xfs: xfs startup succeeded Apr 5 22:38:04 localhost gdm(pam_unix)[1814]: session opened for user richard by (uid=0) Apr 5 22:38:19 localhost kernel: audit(1081219099.459:0): avc: denied { setattr } for pid=1886 exe=/usr/libexec/gnome-settings-daemon name=registry.xml dev=hdc3 ino=3009195 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:var_t tclass=file Apr 5 22:38:20 localhost kernel: audit(1081219100.136:0): avc: denied { getattr } for pid=1901 exe=/usr/X11R6/bin/xscreensaver path=/home/richard/.xscreensaver dev=hdc3 ino=2469233 scontext=richard:staff_r:staff_screensaver_t tcontext=richard:object_r:staff_home_t tclass=file Apr 5 22:38:29 localhost kernel: audit(1081219109.860:0): avc: denied { getattr } for pid=1955 exe=/usr/libexec/gnome-vfs-daemon path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t tclass=dir Apr 5 22:38:30 localhost kernel: audit(1081219110.466:0): avc: denied { getattr } for pid=1966 exe=/usr/bin/nautilus path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t tclass=dir Apr 5 22:38:30 localhost kernel: audit(1081219110.653:0): avc: denied { getattr } for pid=1967 exe=/usr/bin/nautilus path=/initrd dev=ram0 ino=2 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t tclass=dir Apr 5 22:38:37 localhost kernel: audit(1081219117.803:0): avc: denied { setattr } for pid=1976 exe=/usr/libexec/mixer_applet2 name=registry.xml dev=hdc3 ino=3009195 scontext=richard:staff_r:staff_t tcontext=system_u:object_r:var_t tclas: -- fedora-selinux-list mailing list fedora-selinux-list redhat com http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- fedora-selinux-list mailing list fedora-selinux-list redhat com http://www.redhat.com/mailman/listinfo/fedora-selinux-list Thanks Dan! you and the other people working on SELinux are making great progress. It looks like really will happen :) Richard Hally Frank Marsolais, MCSE, CCA Greenman-Pedersen, Inc. Phone (631) 587-5060 x348 Fax (631) 422-3479 FMarsolais at gpinet.com From jr36 at leicester.ac.uk Mon Jul 12 14:59:29 2004 From: jr36 at leicester.ac.uk (Jonathan Rawle) Date: Mon, 12 Jul 2004 15:59:29 +0100 Subject: FC3... install/update ? References: <40ED8473.4080203@comcast.net> Message-ID: Tom London wrote: > With FC3 about to descend, anyone know if updates > from FC2 will be supported? Only clean installs? > > Any thoughts on SELinux-related areas needing attention? Presumably SELinux will only be installed with fresh FC3 installs, or upgrades from FC2 with SELinux? The default for FC2 was not to enable SELinux, so most people won't get SELinux when they upgrade to FC3 unless they do a fresh install. (This was the case with the graphical boot in the upgrade to FC1 from RH9 - a trivial matter by comparison, but it generated a lot of discussion on the list of the type "Where is the graphical boot"...) Jonathan From sds at epoch.ncsc.mil Mon Jul 12 15:04:14 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 11:04:14 -0400 Subject: avc denied messages from boot In-Reply-To: References: Message-ID: <1089644654.22449.203.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-07-12 at 07:30, Frank Marsolais wrote: > I found the following in the archives. > I upgraded from rh7.2 to 9.0 to fedora 2. > > When I put in rpm -q policy policy-sources > I received back > # rpm -q policy policy-sources > policy-1.11.3-3 > package policy-sources is not installed > > Should I download policy-sources or is something else broken? > For the -12 policy would that be 1.12 or 1.9.2-12? >From the (truncated) log messages, it looked like you might not have labeled your filesystems. In single-user mode, run 'fixfiles relabel', then try rebooting. I'd also suggest uncommenting the development entry in your /etc/yum.conf, adding some mirrors, and doing a 'yum upgrade' to pull in the latest SELinux code and policy. -- Stephen Smalley National Security Agency From ghenry at suretecsystems.com Mon Jul 12 15:04:39 2004 From: ghenry at suretecsystems.com (Gavin Henry) Date: Mon, 12 Jul 2004 16:04:39 +0100 (BST) Subject: Best Source to learn more about seLinux? In-Reply-To: <200407110233.09623.tweeksjunk2@theweeks.org> References: <200407110233.09623.tweeksjunk2@theweeks.org> Message-ID: <46474.193.195.148.66.1089644679.squirrel@193.195.148.66> Tom Weeks said: > Hey guys... > > I need to come up to speed fast on seLinux... What's the best source to > dive > into for this? > > Tweeks > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 587369 M +44 (0) 7930 323266 F +44 (0) 1224 742001 E ghenry at suretecsystems.com Open Source. Open Solutions. http://www.suretecsystems.com/ From sds at epoch.ncsc.mil Mon Jul 12 15:04:54 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 11:04:54 -0400 Subject: Best Source to learn more about seLinux? In-Reply-To: <200407110233.09623.tweeksjunk2@theweeks.org> References: <200407110233.09623.tweeksjunk2@theweeks.org> Message-ID: <1089644693.22449.205.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2004-07-11 at 03:33, Tom Weeks wrote: > Hey guys... > > I need to come up to speed fast on seLinux... What's the best source to dive > into for this? Fedora SELinux FAQ is a reasonable starting point: http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jul 12 15:09:58 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 11:09:58 -0400 Subject: FC3... install/update ? In-Reply-To: <40F2A45B.30507@comcast.net> References: <40F2A45B.30507@comcast.net> Message-ID: <1089644997.22449.211.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-07-12 at 10:46, Tom London wrote: > Thanks. > > I have 3 systems: one running 'stock' FC2, the other 2 > running off the development and Arjan's tree. > > I'll try the 'yum update' on the stock system. As I mentioned, you want to use 'yum upgrade' to get it to pull in selinux-policy-strict, I think. 'yum update' doesn't seem to replace 'policy' with 'selinux-policy-strict'. > I'm assuming (hoping?) that the 'bleeding edge' > systems will just update (i.e., 'yum update') > smoothly..... (they've already lost the '2' > from the login splash screen, and yum.conf > has been updated to point only at the > development tree). I expect so. I have several machines running off of the development tree, with one using targeted policy and the rest using strict policy. > FC2T1 clean install had issues with > SELinux installs (home directories not properly > labeled, ...). The bugzilla entry for this > (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123856) > is not closed.... > > Has this been fixed? Need testing? I don't know; there are file_type_auto_trans() rules in firstboot.te for user home directories, but I'm not clear as to whether all issues have been resolved. useradd really needs a bit of SELinux awareness, IMHO. And I seem to recall /etc/passwd and /etc/group being re-written into the wrong type by firstboot as well during FC2 installs. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jul 12 15:18:01 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 11:18:01 -0400 Subject: FC3... install/update ? In-Reply-To: References: <40ED8473.4080203@comcast.net> Message-ID: <1089645481.22449.222.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-07-12 at 10:59, Jonathan Rawle wrote: > Presumably SELinux will only be installed with fresh FC3 installs, or > upgrades from FC2 with SELinux? > > The default for FC2 was not to enable SELinux, so most people won't get > SELinux when they upgrade to FC3 unless they do a fresh install. > (This was the case with the graphical boot in the upgrade to FC1 from RH9 - > a trivial matter by comparison, but it generated a lot of discussion on the > list of the type "Where is the graphical boot"...) I think that this is true, but am not certain. I would expect the following behavior: 1) Upgrade from FC2/non-SELinux => stays non-SELinux 2) Upgrade from FC2/SELinux => stays SELinux, but replaces policy with selinux-policy-strict. 3) Fresh install => defaults to SELinux with selinux-policy-targeted, but selectable at install time -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Jul 12 17:10:09 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Jul 2004 13:10:09 -0400 Subject: Mozilla accessing java engine yield denials In-Reply-To: <1089405219.30863.19.camel@nexus.verbum.private> References: <1087472582.2260.8.camel@sol800.cawthra.com> <1089405219.30863.19.camel@nexus.verbum.private> Message-ID: <40F2C5F1.7070307@redhat.com> Colin Walters wrote: >On Thu, 2004-06-17 at 07:43 -0400, Francis K Shim wrote: > > >>Edited to show relevant details more clearly: >> >>denied { execute } >> exe=/bin/bash >> name=java >> scontext=user:staff_r:staff_mozilla_t tcontext=system_u:object_r:usr_t >> tclass=file >> >> > >A quick fix may be to label the JVM with bin_t: > >chcon -t bin_t /usr/java/blah/bin/java > > > It should have had this label. What was the label on the java executable? What is the path? >>denied { search } >> exe=/usr/java/j2re1.4.2_01/bin/java >> name=vm >> scontext=user:staff_r:staff_mozilla_t >> tcontext=system_u:object_r:sysctl_vm_t >> tclass=dir >> >> > >You can like likely just ignore this. > > > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From dwalsh at redhat.com Mon Jul 12 17:16:16 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Jul 2004 13:16:16 -0400 Subject: avc denied from mDNSResponder In-Reply-To: <40EF9986.1000005@mindspring.com> References: <40EF9986.1000005@mindspring.com> Message-ID: <40F2C760.2060205@redhat.com> Richard Hally wrote: > When booting in enforcing mode with the latest strict > policy(selinux-policy-strict-sources-1.14.1-5) > the following avc denied message is produced. > > Jul 10 03:12:02 new2 network: Bringing up interface eth0: succeeded > Jul 10 03:12:04 new2 kernel: audit(1089443524.677:0): avc: denied { > name_bind > } for pid=2016 exe=/usr/bin/mDNSResponder > scontext=user_u:user_r:user_t tcontext=system_u:object_r:dns_port_t > tclass=udp_socket > mDNSResponder is not something we ship, (I think). So you need to write special policy for it or allow user_t to bind to the dns_port. > > HTH > Richard Hally > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Mon Jul 12 17:19:18 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 12 Jul 2004 13:19:18 -0400 Subject: acv denied from screensaver In-Reply-To: <40EF9F19.80001@mindspring.com> References: <40EF9F19.80001@mindspring.com> Message-ID: <40F2C816.8000702@redhat.com> Richard Hally wrote: > The messages below occured while booting with the latest strict policy > in enforcing mode. One of the things that is not working is the > screensaver. The first message indicates that the problem with the > screensaver may be related to context of files in /tmp created by xdm. > > > Jul 10 03:13:22 new2 kernel: audit(1089443602.916:0): avc: denied { > search } for pid=3288 exe=/usr/X11R6/bin/xscreensaver name=.X11-unix > dev=hda2 ino=1840550 scontext=richard:staff_r:staff_screensaver_t > tcontext=system_u:object_r:xdm_tmp_t tclass=dir > > The additional messages below may or may not be related. > > Jul 10 03:13:24 new2 kernel: audit(1089443604.337:0): avc: denied { > create } for pid=3161 exe=/usr/bin/gnome-session > scontext=richard:staff_r:staff_t tcontext=richard:staff_r:staff_t > tclass=netlink_route_socket These should have been dontaudited. Are you running with enableaudit? > > the message above repeates 5 times then: > > Jul 10 03:13:30 new2 kernel: audit(1089443610.307:0): avc: denied { > getattr } > for pid=3390 exe=/usr/libexec/gnome-vfs-daemon path=/initrd dev=ram0 > ino=2 scontext=richard:staff_r:staff_t > tcontext=system_u:object_r:file_t tclass=dir > Jul 10 03:13:31 new2 kernel: audit(1089443611.639:0): avc: denied { > getattr } > for pid=3401 exe=/usr/bin/nautilus path=/initrd dev=ram0 ino=2 > scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t > tclass=dir > Jul 10 03:13:31 new2 kernel: audit(1089443611.788:0): avc: denied { > getattr } > for pid=3402 exe=/usr/bin/nautilus path=/initrd dev=ram0 ino=2 > scontext=richard:staff_r:staff_t tcontext=system_u:object_r:file_t > tclass=dir > Jul 10 03:13:36 new2 kernel: audit(1089443616.055:0): avc: denied { > create } for pid=3161 exe=/usr/bin/gnome-session > scontext=richard:staff_r:staff_t tcontext=richard:staff_r:staff_t > tclass=netlink_route_socket > Jul 10 03:15:09 new2 kernel: audit(1089443709.073:0): avc: denied { > create } for pid=3161 exe=/usr/bin/gnome-session > scontext=richard:staff_r:staff_t tcontext=richard:staff_r:staff_t > tclass=netlink_route_socket > /initrd should have been umounted at when the boot completes. we have to figure out why it is not umounted. The rest are being caused because of enableaudit I believe. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From mada at gautier.org Mon Jul 12 17:50:51 2004 From: mada at gautier.org (A. Gautier) Date: Mon, 12 Jul 2004 12:50:51 -0500 (CDT) Subject: Major problems after upgrade from FC1 Message-ID: <35035.68.163.106.78.1089654651.squirrel@68.163.106.78> I am about to pull what little is left of my hair out. I decided to upgrade from FC1 to FC2 by pointing yum to a FC2 repository and upgrading all packages. This worked for the most part but I am having massive problems with SELinux. I am not sure that SELinux got setup properly. One of this biggest problems that I have is that crond now no longer runs. I have been following the Fedora SELinux FAQ to get up to speed with lots of google searches and watching this list but I have not been able to solve my problem. My first problem is that system crond is not running. My user crontab is running fine. So, my question is could someone help me 1.) Make sure my setup is correct. 2.) Get the correct policies setup (I am also having a problem with postfix, but I think if I get #1 then there is enough info on the web to solve that problem). Also, the reason I think there is a configuration problem was because when following the FAQ to add a user: ------------------------------ EXCERPT: http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/index.html#id3004455 Q: How can I create a new Linux user account with the user's home directory having the proper context? A: You can create your new user with the standard useradd command, but first you must become root with a context of sysadm_r. This context switch has been incorporated into the su command: %>su - root Your default context is root:sysadm_r:sysadm_t. Do you want to choose a different one? [n] n %>useradd auser %>ls -Z /home drwxr-xr-x auser auser root:object_r:user_home_dir_t /home/auser ------------------------------ So I thought if I ran ls -Z /home I would get a similar result? ------------------------------ OUTPUT: ls -Z /home drwxr--r--+ (null) Also, I get the (null) report on all directories in /root. ------------------------------ OUTPUT: sudo /usr/sbin/sestatus -v SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Policy version: 17 Policy booleans: user_ping inactive Process contexts: Current context: user_u:sysadm_r:sysadm_t Init context: system_u:system_r:kernel_t /sbin/mingetty system_u:system_r:kernel_t /usr/sbin/sshd system_u:system_r:kernel_t File contexts: Controlling term: user_u:object_r:devpts_t ----------------- EXCERPT: /var/log/messages Jul 12 12:00:00 sun kernel: audit(1089651600.583:0): avc: denied { compute_user } for pid=27396 exe=/usr/sbin/crond scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:security_t tclass=security Jul 12 12:00:00 sun kernel: audit(1089651600.584:0): avc: denied { compute_av } for pid=27396 exe=/usr/sbin/crond scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:security_t tclass=security Jul 12 12:00:00 sun kernel: audit(1089651600.586:0): avc: denied { check_context } for pid=27396 exe=/usr/sbin/crond scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:security_t tclass=security Jul 12 12:00:00 sun kernel: audit(1089651600.586:0): avc: denied { write } for pid=27396 exe=/usr/sbin/crond name=exec dev=proc ino=1795424277 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:kernel_t tclass=file Jul 12 12:00:00 sun kernel: audit(1089651600.587:0): avc: denied { setexec } for pid=27396 exe=/usr/sbin/crond scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:kernel_t tclass=process Jul 12 12:00:00 sun kernel: audit(1089651600.587:0): avc: denied { transition } for pid=27396 exe=/usr/sbin/crond path=/bin/bash dev=hda3 ino=3850263 scontext=system_u:system_r:kernel_t tcontext=user_u:sysadm_r:sysadm_t tclass=process Jul 12 12:00:00 sun kernel: audit(1089651600.590:0): avc: denied { siginh } for pid=27396 exe=/bin/bash scontext=system_u:system_r:kernel_t tcontext=user_u:sysadm_r:sysadm_t tclass=process Jul 12 12:00:00 sun kernel: audit(1089651600.590:0): avc: denied { rlimitinh } for pid=27396 exe=/bin/bash scontext=system_u:system_r:kernel_t tcontext=user_u:sysadm_r:sysadm_t tclass=process Jul 12 12:00:00 sun kernel: audit(1089651600.590:0): avc: denied { noatsecure } for pid=27396 exe=/bin/bash scontext=system_u:system_r:kernel_t tcontext=user_u:sysadm_r:sysadm_t tclass=process Jul 12 12:00:01 sun kernel: audit(1089651601.074:0): avc: denied { execute } for pid=27400 exe=/usr/sbin/crond name=sendmail.postfix dev=hda3 ino=3391852 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:sendmail_exec_t tclass=file Jul 12 12:00:01 sun kernel: audit(1089651601.074:0): avc: denied { execute_no_trans } for pid=27400 exe=/usr/sbin/crond path=/usr/sbin/sendmail.postfix dev=hda3 ino=3391852 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:sendmail_exec_t tclass=file From mada at gautier.org Mon Jul 12 17:56:44 2004 From: mada at gautier.org (A. Gautier) Date: Mon, 12 Jul 2004 12:56:44 -0500 (CDT) Subject: Major problems after upgrade from FC1 In-Reply-To: <35035.68.163.106.78.1089654651.squirrel@68.163.106.78> References: <35035.68.163.106.78.1089654651.squirrel@68.163.106.78> Message-ID: <35051.68.163.106.78.1089655004.squirrel@68.163.106.78> > Also, the reason I think there is a configuration problem was because when > following the FAQ to add a user: > > ------------------------------ > EXCERPT: > http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/index.html#id3004455 > > Q: How can I create a new Linux user account with the user's home > directory having the proper context? > > A: You can create your new user with the standard useradd command, but > first you must become root with a context of sysadm_r. This context switch > has been incorporated into the su command: > > %>su - root > Your default context is root:sysadm_r:sysadm_t. > Do you want to choose a different one? [n] n > %>useradd auser > %>ls -Z /home > drwxr-xr-x auser auser root:object_r:user_home_dir_t > /home/auser > ------------------------------ > > So I thought if I ran ls -Z /home I would get a similar result? > > ------------------------------ > OUTPUT: ls -Z /home > > drwxr--r--+ (null) > I fixed the ls -Z problem by running "setfiles" now it seems that the file system is corrected. I also removed the policy-strict-sources packages. I will see if the warnings will be removed from /var/log/messages. From sds at epoch.ncsc.mil Mon Jul 12 17:48:55 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 13:48:55 -0400 Subject: Major problems after upgrade from FC1 In-Reply-To: <35035.68.163.106.78.1089654651.squirrel@68.163.106.78> References: <35035.68.163.106.78.1089654651.squirrel@68.163.106.78> Message-ID: <1089654535.22449.271.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-07-12 at 13:50, A. Gautier wrote: > I am about to pull what little is left of my hair out. I decided to > upgrade from FC1 to FC2 by pointing yum to a FC2 repository and upgrading > all packages. This worked for the most part but I am having massive > problems with SELinux. If you want to use SELinux, you need to initially label your filesystems, which wouldn't occur automatically on an upgrade (vs. a clean install). Run 'fixfiles relabel' from single-user mode and reboot. But if you don't want to use SELinux, you can disable it; put SELINUX=disabled in /etc/sysconfig/selinux (or /etc/selinux/config if using thte development tree) and be done with it. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jul 12 17:50:24 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 13:50:24 -0400 Subject: Major problems after upgrade from FC1 In-Reply-To: <35051.68.163.106.78.1089655004.squirrel@68.163.106.78> References: <35035.68.163.106.78.1089654651.squirrel@68.163.106.78> <35051.68.163.106.78.1089655004.squirrel@68.163.106.78> Message-ID: <1089654623.22449.274.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-07-12 at 13:56, A. Gautier wrote: > I fixed the ls -Z problem by running "setfiles" now it seems that the file > system is corrected. I also removed the policy-strict-sources packages. I > will see if the warnings will be removed from /var/log/messages. FC2 only had "policy" and "policy-sources" packages. The selinux-policy-strict and selinux-policy-strict-sources packages weren't introduced until after FC2, in the development tree for FC3. So what are you actually using, FC2 or development? -- Stephen Smalley National Security Agency From adam at gautier.org Mon Jul 12 17:27:24 2004 From: adam at gautier.org (Adam T. Gautier) Date: Mon, 12 Jul 2004 12:27:24 -0500 (CDT) Subject: Major problems after upgrade from FC1 Message-ID: <34945.68.163.106.78.1089653244.squirrel@68.163.106.78> I am about to pull what little is left of my hair out. I decided to upgrade from FC1 to FC2 by pointing yum to a FC2 repository and upgrading all packages. This worked for the most part but I am having massive problems with SELinux. I am not sure that SELinux got setup properly. One of this biggest problems that I have is that crond now no longer runs. I have been following the Fedora SELinux FAQ to get up to speed with lots of google searches and watching this list but I have not been able to solve my problem. My first problem is that system crond is not running. My user crontab is running fine. So, my question is could someone help me 1.) Make sure my setup is correct. 2.) Get the correct policies setup (I am also having a problem with postfix, but I think if I get #1 then there is enough info on the web to solve that problem). Also, the reason I think there is a configuration problem was because when following the FAQ to add a user: ------------------------------ EXCERPT: http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/index.html#id3004455 Q: How can I create a new Linux user account with the user's home directory having the proper context? A: You can create your new user with the standard useradd command, but first you must become root with a context of sysadm_r. This context switch has been incorporated into the su command: %>su - root Your default context is root:sysadm_r:sysadm_t. Do you want to choose a different one? [n] n %>useradd auser %>ls -Z /home drwxr-xr-x auser auser root:object_r:user_home_dir_t /home/auser ------------------------------ So I thought if I ran ls -Z /home I would get a similar result? ------------------------------ OUTPUT: ls -Z /home drwxr--r--+ (null) Also, I get the (null) report on all directories in /root. ------------------------------ OUTPUT: sudo /usr/sbin/sestatus -v SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Policy version: 17 Policy booleans: user_ping inactive Process contexts: Current context: user_u:sysadm_r:sysadm_t Init context: system_u:system_r:kernel_t /sbin/mingetty system_u:system_r:kernel_t /usr/sbin/sshd system_u:system_r:kernel_t File contexts: Controlling term: user_u:object_r:devpts_t ----------------- EXCERPT: /var/log/messages Jul 12 12:00:00 sun kernel: audit(1089651600.583:0): avc: denied { compute_user } for pid=27396 exe=/usr/sbin/crond scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:security_t tclass=security Jul 12 12:00:00 sun kernel: audit(1089651600.584:0): avc: denied { compute_av } for pid=27396 exe=/usr/sbin/crond scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:security_t tclass=security Jul 12 12:00:00 sun kernel: audit(1089651600.586:0): avc: denied { check_context } for pid=27396 exe=/usr/sbin/crond scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:security_t tclass=security Jul 12 12:00:00 sun kernel: audit(1089651600.586:0): avc: denied { write } for pid=27396 exe=/usr/sbin/crond name=exec dev=proc ino=1795424277 scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:kernel_t tclass=file Jul 12 12:00:00 sun kernel: audit(1089651600.587:0): avc: denied { setexec } for pid=27396 exe=/usr/sbin/crond scontext=system_u:system_r:kernel_t tcontext=system_u:system_r:kernel_t tclass=process Jul 12 12:00:00 sun kernel: audit(1089651600.587:0): avc: denied { transition } for pid=27396 exe=/usr/sbin/crond path=/bin/bash dev=hda3 ino=3850263 scontext=system_u:system_r:kernel_t tcontext=user_u:sysadm_r:sysadm_t tclass=process Jul 12 12:00:00 sun kernel: audit(1089651600.590:0): avc: denied { siginh } for pid=27396 exe=/bin/bash scontext=system_u:system_r:kernel_t tcontext=user_u:sysadm_r:sysadm_t tclass=process Jul 12 12:00:00 sun kernel: audit(1089651600.590:0): avc: denied { rlimitinh } for pid=27396 exe=/bin/bash scontext=system_u:system_r:kernel_t tcontext=user_u:sysadm_r:sysadm_t tclass=process Jul 12 12:00:00 sun kernel: audit(1089651600.590:0): avc: denied { noatsecure } for pid=27396 exe=/bin/bash scontext=system_u:system_r:kernel_t tcontext=user_u:sysadm_r:sysadm_t tclass=process Jul 12 12:00:01 sun kernel: audit(1089651601.074:0): avc: denied { execute } for pid=27400 exe=/usr/sbin/crond name=sendmail.postfix dev=hda3 ino=3391852 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:sendmail_exec_t tclass=file Jul 12 12:00:01 sun kernel: audit(1089651601.074:0): avc: denied { execute_no_trans } for pid=27400 exe=/usr/sbin/crond path=/usr/sbin/sendmail.postfix dev=hda3 ino=3391852 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:sendmail_exec_t tclass=file From gbpeck at sbcglobal.net Mon Jul 12 19:52:19 2004 From: gbpeck at sbcglobal.net (Gary Peck) Date: Mon, 12 Jul 2004 12:52:19 -0700 Subject: avc denied from mDNSResponder In-Reply-To: <40F2C760.2060205@redhat.com> References: <40EF9986.1000005@mindspring.com> <40F2C760.2060205@redhat.com> Message-ID: <20040712195219.GA15537@realify.com> On Mon, Jul 12, 2004 at 01:16:16PM -0400, Daniel J Walsh wrote: > Richard Hally wrote: > > >When booting in enforcing mode with the latest strict > >policy(selinux-policy-strict-sources-1.14.1-5) > >the following avc denied message is produced. > > > >Jul 10 03:12:02 new2 network: Bringing up interface eth0: succeeded > >Jul 10 03:12:04 new2 kernel: audit(1089443524.677:0): avc: denied { > >name_bind } for pid=2016 exe=/usr/bin/mDNSResponder > >scontext=user_u:user_r:user_t tcontext=system_u:object_r:dns_port_t > >tclass=udp_socket > > > mDNSResponder is not something we ship, (I think). So you need to write > special policy for it or allow user_t to bind to the dns_port. As someone else mentioned, it is being shipped in the latest Rawhide. Package is howl-0.9.5-4: Howl is a cross-platform port of Apple's "Rendezvous" (multicast DNS) service discovery and IP autoconfiguration. gary From sds at epoch.ncsc.mil Mon Jul 12 20:08:28 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 12 Jul 2004 16:08:28 -0400 Subject: avc denied from mDNSResponder In-Reply-To: <1089636792.22449.44.camel@moss-spartans.epoch.ncsc.mil> References: <40EF9986.1000005@mindspring.com> <1089636792.22449.44.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1089662908.22449.296.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2004-07-12 at 08:53, Stephen Smalley wrote: > The fact that it is running in user_u likely means that it is being > started via su (to run in some pseudo user identity), and since that > pseudo user identity does not exist in the policy, it is being remapped > to user_u. I confirmed this; /etc/init.d/mDNSResponder does a su -s /bin/bash - nobody -c mDNSResponder to start the daemon. As "nobody" doesn't exist as a user identity in the SELinux policy, su ends up falling back to user_u as the default. Hence, to start with, you would want to replace the use of su with a wrapper program to set the uid/gid without performing a domain transition, and you would still need to define a domain for mDNSResponder. -- Stephen Smalley National Security Agency From rhally at mindspring.com Mon Jul 12 21:24:43 2004 From: rhally at mindspring.com (Richard Hally) Date: Mon, 12 Jul 2004 17:24:43 -0400 Subject: acv denied from screensaver In-Reply-To: <40F2C816.8000702@redhat.com> References: <40EF9F19.80001@mindspring.com> <40F2C816.8000702@redhat.com> Message-ID: <40F3019B.8090806@mindspring.com> Daniel J Walsh wrote: > Richard Hally wrote: > >> The messages below occured while booting with the latest strict policy >> in enforcing mode. One of the things that is not working is the >> screensaver. The first message indicates that the problem with the >> screensaver may be related to context of files in /tmp created by xdm. >> >> >> Jul 10 03:13:22 new2 kernel: audit(1089443602.916:0): avc: denied { >> search } for pid=3288 exe=/usr/X11R6/bin/xscreensaver name=.X11-unix >> dev=hda2 ino=1840550 scontext=richard:staff_r:staff_screensaver_t >> tcontext=system_u:object_r:xdm_tmp_t tclass=dir >> >> The additional messages below may or may not be related. >> >> Jul 10 03:13:24 new2 kernel: audit(1089443604.337:0): avc: denied { >> create } for pid=3161 exe=/usr/bin/gnome-session >> scontext=richard:staff_r:staff_t tcontext=richard:staff_r:staff_t >> tclass=netlink_route_socket > > > These should have been dontaudited. Are you running with enableaudit? > There was a time when I did 'enableaudit' to get the avc denied messages for something else (Mozilla?). These were posted here just in case they were related. Richard Hally From pmatilai at welho.com Tue Jul 13 08:29:07 2004 From: pmatilai at welho.com (Panu Matilainen) Date: Tue, 13 Jul 2004 11:29:07 +0300 Subject: [apt-rpm] apt and selinux (was: Re: restorecon vs. setfiles) In-Reply-To: <20040628223221.GC2887@taz> References: <1084968582.30873.3.camel@moss-spartans.epoch.ncsc.mil> <40ABB2DE.5090107@redhat.com> <20040625163415.GI16241@realify.com> <1088182761.6872.138.camel@moss-spartans.epoch.ncsc.mil> <40DC5936.1040004@redhat.com> <1088185455.6872.183.camel@moss-spartans.epoch.ncsc.mil> <20040627001234.GJ16241@realify.com> <20040627002742.GK16241@realify.com> <1088448832.17133.75.camel@moss-spartans.epoch.ncsc.mil> <20040628223221.GC2887@taz> Message-ID: <1089707347.4365.24.camel@chip.laiskiainen.org> On Tue, 2004-06-29 at 01:32, Gary Peck wrote: > On Mon, Jun 28, 2004 at 02:53:52PM -0400, Stephen Smalley wrote: > > On Mon, 2004-06-28 at 09:11, Panu Matilainen wrote: > > > I wouldn't call it an apt-problem, you just need to put it into same > > > context as rpm. This should already be the case on Fedora Core 2, dunno > > > about upstream selinux policy packages - this is from stock FC2 > > > /etc/security/selinux/src/policy/file_contexts/program/rpm.fc: > > > /usr/bin/apt-get -- system_u:object_r:rpm_exec_t > > > /usr/bin/apt-shell -- system_u:object_r:rpm_exec_t > > > /usr/bin/synaptic -- system_u:object_r:rpm_exec_t > > The context is not the problem. I'm running the targeted policy from > FCdev, which makes both /bin/rpm and /usr/bin/apt* > system_u:object_r:bin_t. rpm works fine, however, whereas apt-get does > not. > > > It isn't just a policy issue; rpm had to be modified for SELinux to > > set file security contexts when creating files. Those changes are in > > the upstream rpm, and yum seems to work as expected when updating. > > I believe apt needs similar modifications. The attached patch to apt > fixes the problem for me. I'm not too familiar with rpm, apt, or selinux > internals, so this patch might need some work. I just took the code > from rpm's lib/rpminstall.c/rpmInstall() function which seemed to be > missing in apt's apt-pkg/rpm/rpmpm.cc/pkgRPMLibPM::Process() function. Had a closer look and the patch indeed seems correct: applied, thanks! - Panu - From Valdis.Kletnieks at vt.edu Wed Jul 14 17:52:45 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 14 Jul 2004 13:52:45 -0400 Subject: Major problems after upgrade from FC1 In-Reply-To: Your message of "Mon, 12 Jul 2004 13:48:55 EDT." <1089654535.22449.271.camel@moss-spartans.epoch.ncsc.mil> References: <35035.68.163.106.78.1089654651.squirrel@68.163.106.78> <1089654535.22449.271.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200407141752.i6EHqm7C001817@turing-police.cc.vt.edu> On Mon, 12 Jul 2004 13:48:55 EDT, Stephen Smalley said: > On Mon, 2004-07-12 at 13:50, A. Gautier wrote: > > I am about to pull what little is left of my hair out. I decided to > > upgrade from FC1 to FC2 by pointing yum to a FC2 repository and upgrading > > all packages. This worked for the most part but I am having massive > > problems with SELinux. > > If you want to use SELinux, you need to initially label your > filesystems, which wouldn't occur automatically on an upgrade (vs. a > clean install). Run 'fixfiles relabel' from single-user mode and > reboot. But if you don't want to use SELinux, you can disable it; put > SELINUX=disabled in /etc/sysconfig/selinux (or /etc/selinux/config if > using thte development tree) and be done with it. Is it time we hacked up /sbin/init to do the following: if (selinux_enabled && (getfilecon("/etc") == NULL)) { printf("You need to run 'fixfiles relabel'"); exit(1); } or something similar, so people *know* what they did wrong? One can also make the security case that if SELinux is disabled, and init can convince itself the root filesystem isn't labelled, that it should stop right there as a fail-safe? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From kvogelsa at ccs.neu.edu Thu Jul 15 15:26:58 2004 From: kvogelsa at ccs.neu.edu (Kirk Vogelsang) Date: Thu, 15 Jul 2004 11:26:58 -0400 (EDT) Subject: Policy Management Message-ID: I'm contemplating rolling my own policy.conf, using the latest strict as a base and trimming it down and wondering if others have gone this route as well. I'm well aware of the implications in doing this and moving away from the standard m4-based config. But what seem to be trivial tasks in modifying the policy file directly appear to become somewhat non-trivial in trying to make the same modification in the macro files. For example, I wish to disallow user_r any access to selinux_config_t. It appears as though access is granted to selinux_config_t via via full_user_role() via base_file_read_access(). full_user_role(user) adds quite a bit of functionality I want to keep as does base_file_read_access(user). So I'm not quite sure where to go from here. Removing this access from the policy.conf directly appears to be a matter of removing one or two lines. Maybe I'm going about things incorrectly? Do other's write and maintain their own policies independent of the policy*.rpm's? Thanx for and insight... ----- Kirk M. Vogelsang Northeastern University College of Computer Science From sds at epoch.ncsc.mil Thu Jul 15 18:12:47 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 15 Jul 2004 14:12:47 -0400 Subject: Policy Management In-Reply-To: References: Message-ID: <1089915166.31476.88.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-15 at 11:26, Kirk Vogelsang wrote: > I'm contemplating rolling my own policy.conf, using the latest strict > as a base and trimming it down and wondering if others have gone > this route as well. > > I'm well aware of the implications in doing this and moving away from > the standard m4-based config. But what seem to be trivial tasks in > modifying the policy file directly appear to become somewhat non-trivial > in trying to make the same modification in the macro files. > > For example, I wish to disallow user_r any access to selinux_config_t. > It appears as though access is granted to selinux_config_t via > via full_user_role() via base_file_read_access(). full_user_role(user) > adds quite a bit of functionality I want to keep as does > base_file_read_access(user). So I'm not quite sure where to go from > here. Removing this access from the policy.conf directly appears to > be a matter of removing one or two lines. > > Maybe I'm going about things incorrectly? Do other's write and maintain > their own policies independent of the policy*.rpm's? You could make an argument for removing that rule from base_file_read_access(), optionally replacing it with a dontaudit rule. Since libselinux attempts to set up the policy paths via a constructor, every program that links with it ends up triggering an attempt to read /etc/selinux/config, even if that program never truly accesses a policy file. Hence, many audit messages related to /etc/selinux/config are harmless, and any program that does need to access a policy file will ultimately need access to one of the other types (default_context_t, policy_config_t, or policy_src_t) as well as selinux_config_t. Even if you were to maintain this as your own custom policy, I think you likely need to do more than just remove rules between user_t and selinux_config_t, as there may be program domains reachable by user_t that could be used to indirectly read it, particularly if you don't remove the rule from the base_file_read_access() macro itself. Of course, the information in /etc/selinux/config is straightforward to infer anyway; it isn't difficult to determine that you are on a SELinux enforcing system and what kind of policy you are running. -- Stephen Smalley National Security Agency From selinux at comcast.net Thu Jul 15 20:28:01 2004 From: selinux at comcast.net (Tom London) Date: Thu, 15 Jul 2004 13:28:01 -0700 Subject: selinux-policy-strict-1.15.5-2 breaks mozilla.... Message-ID: <40F6E8D1.1030106@comcast.net> selinux-policy-strict-1.15.5-2 mislabels /usr/lib/mozilla-1.7/mozilla-* as lib_t, instead of as mozilla_exec_t. mozilla.fc now has: /usr/lib(64)?/mozilla/mozilla-.* -- system_u:object_r:mozilla_exec_t but the files are in /usr/lib/mozilla-1.7/ Should the line in mozilla.fc be something like: /usr/lib(64)?/mozilla(-[0-9].*)?/mozilla-* -- system_u:object_r:mozilla_exec_t tom From sds at epoch.ncsc.mil Thu Jul 15 20:38:07 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Thu, 15 Jul 2004 16:38:07 -0400 Subject: selinux-policy-strict-1.15.5-2 breaks mozilla.... In-Reply-To: <40F6E8D1.1030106@comcast.net> References: <40F6E8D1.1030106@comcast.net> Message-ID: <1089923887.2406.30.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-15 at 16:28, Tom London wrote: > selinux-policy-strict-1.15.5-2 mislabels /usr/lib/mozilla-1.7/mozilla-* > as lib_t, > instead of as mozilla_exec_t. > > mozilla.fc now has: > /usr/lib(64)?/mozilla/mozilla-.* -- system_u:object_r:mozilla_exec_t > > but the files are in /usr/lib/mozilla-1.7/ > > Should the line in mozilla.fc be something like: > /usr/lib(64)?/mozilla(-[0-9].*)?/mozilla-* -- > system_u:object_r:mozilla_exec_t > I suggested the patch below earlier today. Dan says we also need to generalize the firefox entries. Index: policy/file_contexts/program/mozilla.fc =================================================================== RCS file: /nfshome/pal/CVS/selinux-usr/policy/file_contexts/program/mozilla.fc,v retrieving revision 1.8 diff -u -r1.8 mozilla.fc --- policy/file_contexts/program/mozilla.fc 12 Jul 2004 16:13:11 -0000 1.8 +++ policy/file_contexts/program/mozilla.fc 15 Jul 2004 13:44:59 -0000 @@ -14,7 +14,5 @@ /usr/bin/mozilla-bin-[0-9].* -- system_u:object_r:mozilla_exec_t /usr/lib(64)?/netscape/.+/communicator/communicator-smotif.real -- system_u:object_r:mozilla_exec_t /usr/lib(64)?/netscape/base-4/wrapper -- system_u:object_r:mozilla_exec_t -/usr/lib(64)?/mozilla/reg.+ -- system_u:object_r:mozilla_exec_t -/usr/lib(64)?/mozilla/mozilla-.* -- system_u:object_r:mozilla_exec_t -/usr/lib(64)?/mozilla-snapshot/reg.+ -- system_u:object_r:mozilla_exec_t -/usr/lib(64)?/mozilla-snapshot/mozilla-.* -- system_u:object_r:mozilla_exec_t +/usr/lib(64)?/mozilla[^/]*/reg.+ -- system_u:object_r:mozilla_exec_t +/usr/lib(64)?/mozilla[^/]*/mozilla-.* -- system_u:object_r:mozilla_exec_t -- Stephen Smalley National Security Agency From russell at coker.com.au Fri Jul 16 02:35:38 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 16 Jul 2004 12:35:38 +1000 Subject: /lib64/modules Message-ID: <200407161235.38703.russell@coker.com.au> Will kernel modules ever be stored in /lib64/modules? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From selinux at comcast.net Fri Jul 16 16:44:24 2004 From: selinux at comcast.net (Tom London) Date: Fri, 16 Jul 2004 09:44:24 -0700 Subject: install of kernel-2.6.7-1.492: mkinitrd fails in strict/enforcing ....... Message-ID: <40F805E8.4030003@comcast.net> 'yum update' for the kernel-2.6.7-1.492 doesn't work (strict/enforcing mode, selinux-policy-strict-1.15.5-2): kernel 100 % done 18/47 /bin/bash: /root/.bashrc: Permission denied /lib/modules/2.6.7-1.492 is not a directory. mkinitrd failed / [I checked, and no initrd-2.6.7-1.492.img in /boot] I found this message in /var/log/messages: Jul 16 07:52:15 fedora kernel: audit(1089989535.207:0): avc: denied { getattr } for pid=3420 exe=/bin/bash path=/lib/modules/2.6.7-1.492 dev=hda2 ino=3671053 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:modules_object_t tclass=dir I set 'strict/permissive', did 'rpm -e kernel-2.6.7-1.492' and did the 'yum update' again and got: Dependencies resolved I will do the following: [install: kernel 2.6.7-1.492.i686] Is this ok [y/N]: y Downloading Packages Running test transaction: WARNING: Multiple same specifications for /halt. WARNING: Multiple same specifications for /\.autofsck. Test transaction complete, Success! WARNING: Multiple same specifications for /halt. WARNING: Multiple same specifications for /\.autofsck. kernel 100 % done 1/1 / Kernel Updated/Installed, checking for bootloader Grub found - making this kernel the default Installed: kernel 2.6.7-1.492.i686 Transaction(s) Complete Something change? tom From sds at epoch.ncsc.mil Fri Jul 16 17:49:24 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 16 Jul 2004 13:49:24 -0400 Subject: install of kernel-2.6.7-1.492: mkinitrd fails in strict/enforcing ....... In-Reply-To: <40F805E8.4030003@comcast.net> References: <40F805E8.4030003@comcast.net> Message-ID: <1090000164.10135.20.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-07-16 at 12:44, Tom London wrote: > 'yum update' for the kernel-2.6.7-1.492 doesn't work > (strict/enforcing mode, selinux-policy-strict-1.15.5-2): > > kernel 100 % done 18/47 > /bin/bash: /root/.bashrc: Permission denied > /lib/modules/2.6.7-1.492 is not a directory. > mkinitrd failed > / > > [I checked, and no initrd-2.6.7-1.492.img in /boot] > > I found this message in /var/log/messages: > Jul 16 07:52:15 fedora kernel: audit(1089989535.207:0): avc: > denied { getattr } for pid=3420 exe=/bin/bash > path=/lib/modules/2.6.7-1.492 dev=hda2 ino=3671053 > scontext=root:sysadm_r:bootloader_t > tcontext=system_u:object_r:modules_object_t tclass=dir > > I set 'strict/permissive', did 'rpm -e kernel-2.6.7-1.492' > and did the 'yum update' again and got: > Dependencies resolved > I will do the following: > [install: kernel 2.6.7-1.492.i686] > Is this ok [y/N]: y > Downloading Packages > Running test transaction: > WARNING: Multiple same specifications for /halt. > WARNING: Multiple same specifications for /\.autofsck. > Test transaction complete, Success! > WARNING: Multiple same specifications for /halt. > WARNING: Multiple same specifications for /\.autofsck. > kernel 100 % done 1/1 > / > Kernel Updated/Installed, checking for bootloader > Grub found - making this kernel the default > Installed: kernel 2.6.7-1.492.i686 > Transaction(s) Complete > > Something change? Yes, I think that a cleanup patch from Russell removed an overly general rule from bootloader.te that was giving it getattr permission to all file types, the diff was: @@ -102,7 +104,8 @@ allow bootloader_t self:capability { fsetid sys_rawio sys_admin mknod chown }; # allow bootloader to get attributes of any device node -allow bootloader_t file_type:dir_file_class_set getattr; +allow bootloader_t { device_type ttyfile }:chr_file getattr; +allow bootloader_t device_type:blk_file getattr; dontaudit bootloader_t devpts_t:dir create_dir_perms; allow bootloader_t self:process { fork signal_perms }; To fix, I'd suggest adding getattr to any allow rule where read permission is granted in bootloader.te, or replacing uses of "read" with the r_file_perms macro. -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Fri Jul 16 17:50:13 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 16 Jul 2004 13:50:13 -0400 Subject: install of kernel-2.6.7-1.492: mkinitrd fails in strict/enforcing ....... In-Reply-To: <40F805E8.4030003@comcast.net> References: <40F805E8.4030003@comcast.net> Message-ID: <1090000213.10135.22.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2004-07-16 at 12:44, Tom London wrote: > 'yum update' for the kernel-2.6.7-1.492 doesn't work > Dependencies resolved > I will do the following: > [install: kernel 2.6.7-1.492.i686] > Is this ok [y/N]: y > Downloading Packages > Running test transaction: > WARNING: Multiple same specifications for /halt. > WARNING: Multiple same specifications for /\.autofsck. > Test transaction complete, Success! > WARNING: Multiple same specifications for /halt. > WARNING: Multiple same specifications for /\.autofsck. > kernel 100 % done 1/1 I think the multiple same specifications warning is due to duplicate entries in initrc.fc and rpm.fc; they should be removed from rpm.fc. -- Stephen Smalley National Security Agency From russell at coker.com.au Sat Jul 17 01:34:18 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 17 Jul 2004 11:34:18 +1000 Subject: install of kernel-2.6.7-1.492: mkinitrd fails in strict/enforcing ....... In-Reply-To: <1090000213.10135.22.camel@moss-spartans.epoch.ncsc.mil> References: <40F805E8.4030003@comcast.net> <1090000213.10135.22.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200407171134.18066.russell@coker.com.au> On Sat, 17 Jul 2004 03:50, Stephen Smalley wrote: > I think the multiple same specifications warning is due to duplicate > entries in initrc.fc and rpm.fc; they should be removed from rpm.fc. I think that they should be removed from initrc.fc. The policy to match those fc entries is only included if rpm.te is in the policy. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Sat Jul 17 01:39:43 2004 From: russell at coker.com.au (Russell Coker) Date: Sat, 17 Jul 2004 11:39:43 +1000 Subject: install of kernel-2.6.7-1.492: mkinitrd fails in strict/enforcing ....... In-Reply-To: <1090000164.10135.20.camel@moss-spartans.epoch.ncsc.mil> References: <40F805E8.4030003@comcast.net> <1090000164.10135.20.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200407171139.43514.russell@coker.com.au> > To fix, I'd suggest adding getattr to any allow rule where read > permission is granted in bootloader.te, or replacing uses of "read" with > the r_file_perms macro. The attached patch is needed to make it complete. However this is something we may want to reconsider, currently we don't include policy in the initrd so bootloader_t has no need to read it. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-diff Size: 509 bytes Desc: not available URL: From russell at coker.com.au Sun Jul 18 15:01:12 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 19 Jul 2004 01:01:12 +1000 Subject: howl Message-ID: <200407190101.12741.russell@coker.com.au> In howl there are two daemons, nifd and mDNSResponder. How do these relate to each other? Is there a need to put them in different SE Linux domains or should they both be in the same domain? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From tweeksjunk2 at theweeks.org Mon Jul 19 04:25:40 2004 From: tweeksjunk2 at theweeks.org (Tom Weeks) Date: Sun, 18 Jul 2004 23:25:40 -0500 Subject: Major problems after upgrade from FC1 In-Reply-To: <1089654535.22449.271.camel@moss-spartans.epoch.ncsc.mil> References: <35035.68.163.106.78.1089654651.squirrel@68.163.106.78> <1089654535.22449.271.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200407182325.40754.tweeksjunk2@theweeks.org> On Monday 12 July 2004 12:48 pm, Stephen Smalley wrote: > On Mon, 2004-07-12 at 13:50, A. Gautier wrote: > > I am about to pull what little is left of my hair out. I decided to > > upgrade from FC1 to FC2 by pointing yum to a FC2 repository and upgrading > > all packages. This worked for the most part but I am having massive > > problems with SELinux. > > If you want to use SELinux, you need to initially label your > filesystems, which wouldn't occur automatically on an upgrade (vs. a > clean install). Run 'fixfiles relabel' from single-user mode and > reboot. But if you don't want to use SELinux, you can disable it; put > SELINUX=disabled in /etc/sysconfig/selinux (or /etc/selinux/config if > using thte development tree) and be done with it. Can this also be triggered as a boot time kernel option.. from GRUB (for example)? Tweeks From tweeksjunk2 at theweeks.org Mon Jul 19 04:28:11 2004 From: tweeksjunk2 at theweeks.org (Tom Weeks) Date: Sun, 18 Jul 2004 23:28:11 -0500 Subject: Best Source to learn more about seLinux? In-Reply-To: <46474.193.195.148.66.1089644679.squirrel@193.195.148.66> References: <200407110233.09623.tweeksjunk2@theweeks.org> <46474.193.195.148.66.1089644679.squirrel@193.195.148.66> Message-ID: <200407182328.11228.tweeksjunk2@theweeks.org> On Monday 12 July 2004 10:04 am, Gavin Henry wrote: > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ Thnx.. :) tweeks From russell at coker.com.au Mon Jul 19 13:02:42 2004 From: russell at coker.com.au (Russell Coker) Date: Mon, 19 Jul 2004 23:02:42 +1000 Subject: genhomedircon Message-ID: <200407192302.42130.russell@coker.com.au> The attached patch fixes a bug in genhomedircon. Without this if you create system users with "useradd -r" and give them home directories in unusual locations (such as /usr/DIR or /var/run/DIR) then a file_contexts file will be generated that will mess up your system. This match makes it check /etc/login.defs for the value of UID_MIN. Also perhaps we should make STARTING_UID default to 500. 500 is the default value for this in Fedora. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: text/x-diff Size: 593 bytes Desc: not available URL: From don.patterson at tresys.com Mon Jul 19 15:38:33 2004 From: don.patterson at tresys.com (Don Patterson) Date: Mon, 19 Jul 2004 11:38:33 -0400 Subject: Best Source to learn more about seLinux? In-Reply-To: <200407182328.11228.tweeksjunk2@theweeks.org> Message-ID: <20040719153833.SYDY29389.mm-ismta4.bizmailsrvcs.net@ICEMAN> There is also documentation and information about training that we offer on our website at www.tresys.com/selinux. Don Patterson Tresys Technology http://www.tresys.com -----Original Message----- From: fedora-selinux-list-bounces at redhat.com [mailto:fedora-selinux-list-bounces at redhat.com] On Behalf Of Tom Weeks Sent: Sunday, July 18, 2004 11:28 PM To: Fedora SELinux support list for users & developers. Subject: Re: Best Source to learn more about seLinux? On Monday 12 July 2004 10:04 am, Gavin Henry wrote: > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ Thnx.. :) tweeks -- fedora-selinux-list mailing list fedora-selinux-list at redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at comcast.net Mon Jul 19 17:15:03 2004 From: selinux at comcast.net (Tom London) Date: Mon, 19 Jul 2004 10:15:03 -0700 Subject: hpoj? Message-ID: <40FC0197.1080104@comcast.net> I'm getting some messages from hpoj that I don't remember getting before, shown below. After starting in permissive mode, checking on '/var/run/ptal-mlcd and ptal-printd' shows files (fifos) with context 'system_u:object_r:var_run_t'. I was expecting them to be 'system_u:object_r:ptal_var_run_t'. Have I missed configuring this properly? thanks, tom Audit2allow on permissive avc's yield: allow ptal_t etc_runtime_t:file { getattr }; allow ptal_t etc_t:file { read }; allow ptal_t staff_home_dir_t:dir { search }; allow ptal_t usbdevfs_t:dir { getattr read }; allow ptal_t var_run_t:fifo_file { create read setattr }; allow ptal_t var_run_t:sock_file { create setattr }; (enforcing); Jul 19 09:58:07 fedora kernel: audit(1090256287.964:0): avc: denied { create } for pid=5638 exe=/usr/sbin/ptal-mlcd name=usb:PSC_900_Series scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:var_run_t tclass=sock_file Jul 19 09:58:07 fedora ptal-mlcd: FATAL ERROR at ExMgr.cpp:1250, dev=, pid=5638, e=13, t=1090256287 bind(/var/run/ptal-mlcd/usb:PSC_900_Series) failed! Ensure /var/run/ptal-mlcd/ exists. Jul 19 09:58:07 fedora kernel: audit(1090256287.972:0): avc: denied { search } for pid=5639 exe=/usr/sbin/ptal-printd name=root dev=hda2 ino=1196033 scontext=system_u:system_r:ptal_t tcontext=root:object_r:staff_home_dir_t tclass=dir Jul 19 09:58:07 fedora kernel: audit(1090256287.972:0): avc: denied { read } for pid=5639 exe=/usr/sbin/ptal-printd name=mlc:usb:PSC_900_Series dev=hda2 ino=738368 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:etc_t tclass=file Jul 19 09:58:07 fedora kernel: audit(1090256287.972:0): avc: denied { getattr } for pid=5639 exe=/usr/sbin/ptal-printd path=/etc/ptal/ptal-printd-like dev=hda2 ino=737289 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:etc_runtime_t tclass=file Jul 19 09:58:07 fedora ptal-printd: ptal-printd(mlc:usb:PSC_900_Series): Unable to read file permissions from "/etc/ptal/ptal-printd-like"! Jul 19 09:58:09 fedora ptal-photod: ptal-photod(mlc:usb:PSC_900_Series) successfully initialized, listening on port 5703. (permissive): Jul 19 09:59:41 fedora ptal-mlcd: SYSLOG at ExMgr.cpp:652, dev=, pid=5694, e=2, t=1090256381 ptal-mlcd successfully initialized. Jul 19 09:59:41 fedora ptal-printd: ptal-printd(mlc:usb:PSC_900_Series) successfully initialized using /var/run/ptal-printd/mlc_usb_PSC_900_Series*. Jul 19 09:59:41 fedora kernel: audit(1090256381.301:0): avc: denied { create } for pid=5693 exe=/usr/sbin/ptal-mlcd name=usb:PSC_900_Series scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:var_run_t tclass=sock_file Jul 19 09:59:41 fedora kernel: audit(1090256381.301:0): avc: denied { setattr } for pid=5693 exe=/usr/sbin/ptal-mlcd name=usb:PSC_900_Series dev=hda2 ino=4493726 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:var_run_t tclass=sock_file Jul 19 09:59:41 fedora kernel: audit(1090256381.301:0): avc: denied { read } for pid=5693 exe=/usr/sbin/ptal-mlcd dev=usbdevfs ino=1417 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbdevfs_t tclass=dir Jul 19 09:59:41 fedora kernel: audit(1090256381.301:0): avc: denied { getattr } for pid=5693 exe=/usr/sbin/ptal-mlcd path=/proc/bus/usb dev=usbdevfs ino=1417 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:usbdevfs_t tclass=dir Jul 19 09:59:41 fedora kernel: audit(1090256381.308:0): avc: denied { search } for pid=5695 exe=/usr/sbin/ptal-printd name=root dev=hda2 ino=1196033 scontext=system_u:system_r:ptal_t tcontext=root:object_r:staff_home_dir_t tclass=dir Jul 19 09:59:41 fedora kernel: audit(1090256381.309:0): avc: denied { read } for pid=5695 exe=/usr/sbin/ptal-printd name=mlc:usb:PSC_900_Series dev=hda2 ino=738368 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:etc_t tclass=file Jul 19 09:59:41 fedora kernel: audit(1090256381.309:0): avc: denied { getattr } for pid=5695 exe=/usr/sbin/ptal-printd path=/etc/ptal/ptal-printd-like dev=hda2 ino=737289 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:etc_runtime_t tclass=file Jul 19 09:59:41 fedora kernel: audit(1090256381.309:0): avc: denied { create } for pid=5695 exe=/usr/sbin/ptal-printd name=mlc_usb_PSC_900_Series scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:var_run_t tclass=fifo_file Jul 19 09:59:41 fedora kernel: audit(1090256381.309:0): avc: denied { setattr } for pid=5695 exe=/usr/sbin/ptal-printd name=mlc_usb_PSC_900_Series dev=hda2 ino=4493727 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:var_run_t tclass=fifo_file Jul 19 09:59:41 fedora kernel: audit(1090256381.309:0): avc: denied { read } for pid=5695 exe=/usr/sbin/ptal-printd name=mlc_usb_PSC_900_Series dev=hda2 ino=4493727 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:var_run_t tclass=fifo_file Jul 19 09:59:43 fedora ptal-photod: ptal-photod(mlc:usb:PSC_900_Series) successfully initialized, listening on port 5703. From mike at flyn.org Tue Jul 20 01:49:36 2004 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 19 Jul 2004 20:49:36 -0500 (CDT) Subject: SELinux and stunnel Message-ID: <35168.68.252.239.165.1090288176.squirrel@68.252.239.165> I am using stunnel to create an encrypted tunnel for SMTP connections to my ISP. I have configured xinetd to execute stunnel appropriately when a connection is made to localhost:465. This has stopped working when using recent strict policies. I now see the following errors in my system logs: Jul 19 20:42:16 imp kernel: audit(1090287736.954:0): avc: denied { execute } for pid=6363 exe=/usr/sbin/xinetd name=stunnel dev=dm-0 ino=48915 scontext=root:system_r:inetd_t tcontext=system_u:object_r:sbin_t tclass=file Jul 19 20:42:16 imp kernel: audit(1090287736.954:0): avc: denied { execute_no_trans } for pid=6363 exe=/usr/sbin/xinetd path=/usr/sbin/stunnel dev=dm-0 ino=48915 scontext=root:system_r:inetd_t tcontext=system_u:object_r:sbin_t tclass=file Jul 19 20:42:16 imp kernel: audit(1090287736.956:0): avc: denied { read } for pid=6363 exe=/usr/sbin/xinetd path=/usr/sbin/stunnel dev=dm-0 ino=48915 scontext=root:system_r:inetd_t tcontext=system_u:object_r:sbin_t tclass=file Jul 19 20:42:17 imp kernel: audit(1090287737.391:0): avc: denied { getattr } for pid=6363 exe=/usr/sbin/stunnel path=/dev/urandom dev=dm-0 ino=272235 scontext=root:system_r:inetd_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Jul 19 20:42:17 imp kernel: audit(1090287737.395:0): avc: denied { read } for pid=6363 exe=/usr/sbin/stunnel name=urandom dev=dm-0 ino=272235 scontext=root:system_r:inetd_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file Jul 19 20:42:17 imp kernel: audit(1090287737.395:0): avc: denied { ioctl } for pid=6363 exe=/usr/sbin/stunnel path=/dev/urandom dev=dm-0 ino=272235 scontext=root:system_r:inetd_t tcontext=system_u:object_r:urandom_device_t tclass=chr_file I am using: selinux-policy-strict-sources-1.15.5-2 selinux-policy-strict-1.15.5-2 policycoreutils-1.15.1-1 checkpolicy-1.14.1-1 libselinux-devel-1.15.1-1 libselinux-1.15.1-1 Should I put this in bugzilla? -- Mike From selinux at comcast.net Tue Jul 20 03:24:45 2004 From: selinux at comcast.net (Tom London) Date: Mon, 19 Jul 2004 20:24:45 -0700 Subject: .udev.tdb ? Message-ID: <40FC907D.7010104@comcast.net> I'm getting lots of of 'denied' avc for /dev/.udev.tdb from /sbin/udev. I see an entry in file_contexts for '/dev/udev.tbl' (which doesn't seem to exist on my system). Has .udev.tbd replaced udev.tbl? (udev_db in /etc/udev/udev.conf is set to /dev/.udev.tdb). tom [udev-029-4, selinux-policy-strict-1.15.7-1] ---------------------------------------------------------------- Jul 19 18:58:54 fedora kernel: audit(1090288734.253:0): avc: denied { read write } for pid=2720 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.284:0): avc: denied { read write } for pid=2727 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.314:0): avc: denied { read write } for pid=2734 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.344:0): avc: denied { read write } for pid=2741 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.705:0): avc: denied { read write } for pid=2824 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.707:0): avc: denied { read write } for pid=2825 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file Jul 19 18:58:54 fedora kernel: audit(1090288734.710:0): avc: denied { read write } for pid=2826 exe=/sbin/udev name=.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=file From selinux at comcast.net Tue Jul 20 03:32:38 2004 From: selinux at comcast.net (Tom London) Date: Mon, 19 Jul 2004 20:32:38 -0700 Subject: /etc/exports, /usr/sbin/exportfs ... Message-ID: <40FC9256.7040105@comcast.net> My log shows the following failure: Jul 19 18:58:38 fedora kernel: audit(1090288718.937:0): avc: denied { read } for pid=2363 exe=/usr/sbin/exportfs name=exports dev=hda2 ino=4472848 scontext=system_u:system_r:nfsd_t tcontext=system_u:object_r:exports_t tclass=file Jul 19 18:58:38 fedora exportfs[2363]: can't open /etc/exports for reading Jul 19 18:58:38 fedora exportfs: exportfs: can't open /etc/exports for reading I'm running strict/enforcing. tom From miremadi at ce.sharif.edu Tue Jul 20 05:00:48 2004 From: miremadi at ce.sharif.edu (miremadi at ce.sharif.edu) Date: Tue, 20 Jul 2004 09:30:48 +0430 (IRDT) Subject: SELinux installation! Message-ID: <1226.81.31.164.23.1090299648.squirrel@ce> Hi, I have a little problem in installing SELinux. I begin with writing "linux selinux" at the boot prompt and then after some steps I see that the SELinux has been actived. But when I choose "custom", I don't know which package include "/etc/security/selinux/src"(I mean the "src" directory). Because the "src" directory exist whenever I choose "everything" and installing in this mode will take very long time. thanx, From russell at coker.com.au Tue Jul 20 05:20:58 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 20 Jul 2004 15:20:58 +1000 Subject: SELinux and stunnel In-Reply-To: <35168.68.252.239.165.1090288176.squirrel@68.252.239.165> References: <35168.68.252.239.165.1090288176.squirrel@68.252.239.165> Message-ID: <200407201520.58826.russell@coker.com.au> On Tue, 20 Jul 2004 11:49, "W. Michael Petullo" wrote: > I am using stunnel to create an encrypted tunnel for SMTP connections to > my ISP. I have configured xinetd to execute stunnel appropriately when a > connection is made to localhost:465. This has stopped working when using > recent strict policies. I now see the following errors in my system logs: inetd_child_t has access to /dev/urandom. If stunnel is labelled as inetd_child_exec_t then things should just work for you. Is stunnel commonly used in any other way than through inetd? If not then we'll just change the default policy to label it as inetd_child_exec_t. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Tue Jul 20 04:53:09 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 20 Jul 2004 14:53:09 +1000 Subject: hpoj? In-Reply-To: <40FC0197.1080104@comcast.net> References: <40FC0197.1080104@comcast.net> Message-ID: <200407201453.09844.russell@coker.com.au> On Tue, 20 Jul 2004 03:15, Tom London wrote: > Audit2allow on permissive avc's yield: > allow ptal_t etc_runtime_t:file { getattr }; > allow ptal_t etc_t:file { read }; For file access whenever read access is requested you should allow getattr. For a file type such etc_runtime_t which contains nothing secret if you allow getattr you should allow read. So I added the following to my tree: allow ptal_t { etc_t etc_runtime_t }:file { getattr read }; > allow ptal_t staff_home_dir_t:dir { search }; What does ptal do? Why does it need such access? > allow ptal_t usbdevfs_t:dir { getattr read }; Again, what is it trying to do here? I've never used ptal so I don't know what we should be permitting it to do. > allow ptal_t var_run_t:fifo_file { create read setattr }; > allow ptal_t var_run_t:sock_file { create setattr }; For the sock_file and the fifo_file in question you didn't provide enough information to determine which directory they are in. Please repeat the tests and use "find /var/run -inum ..." to find the full path. If they are under /var/run/ptal-printd or /var/run/ptal-mlcd then they should have the correct type and there should not be any problem (in which case there is some strange mis-labelling issue). If they are not under those directories then I will need to know the directories that they are in to write the correct policy. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Tue Jul 20 07:16:34 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 20 Jul 2004 17:16:34 +1000 Subject: .udev.tdb ? In-Reply-To: <40FC907D.7010104@comcast.net> References: <40FC907D.7010104@comcast.net> Message-ID: <200407201716.34309.russell@coker.com.au> On Tue, 20 Jul 2004 13:24, Tom London wrote: > I'm getting lots of of 'denied' avc for /dev/.udev.tdb from /sbin/udev. > I see an entry in file_contexts for '/dev/udev.tbl' (which doesn't > seem to exist on my system). Has .udev.tbd replaced udev.tbl? > (udev_db in /etc/udev/udev.conf is set to /dev/.udev.tdb). Your analysis sounds reasonable. How do things work if you put the following in udev.fc, run "make install" and then run "restorecon /dev/.udev.tdb"? /dev/\.udev\.tdb -- system_u:object_r:udev_tbl_t -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Tue Jul 20 05:58:25 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 20 Jul 2004 15:58:25 +1000 Subject: /etc/exports, /usr/sbin/exportfs ... In-Reply-To: <40FC9256.7040105@comcast.net> References: <40FC9256.7040105@comcast.net> Message-ID: <200407201558.25886.russell@coker.com.au> On Tue, 20 Jul 2004 13:32, Tom London wrote: > My log shows the following failure: > > Jul 19 18:58:38 fedora kernel: audit(1090288718.937:0): avc: denied { > read } for pid=2363 exe=/usr/sbin/exportfs name=exports dev=hda2 > ino=4472848 scontext=system_u:system_r:nfsd_t > tcontext=system_u:object_r:exports_t tclass=file allow nfsd_t exports_t:file { getattr read }; Add the above to domains/program/rpcd.te . -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Tue Jul 20 12:42:48 2004 From: russell at coker.com.au (Russell Coker) Date: Tue, 20 Jul 2004 22:42:48 +1000 Subject: SELinux installation! In-Reply-To: <1226.81.31.164.23.1090299648.squirrel@ce> References: <1226.81.31.164.23.1090299648.squirrel@ce> Message-ID: <200407202242.48636.russell@coker.com.au> On Tue, 20 Jul 2004 15:00, miremadi at ce.sharif.edu wrote: > I have a little problem in installing SELinux. > I begin with writing "linux selinux" at the boot prompt and then after > some steps I see that the SELinux has been actived. But when I choose > "custom", I don't know which package include "/etc/security/selinux/src"(I > mean the "src" directory). Because the "src" directory exist whenever I > choose "everything" and installing in this mode will take very long time. policy-strict-sources for FC2 or selinux-policy-strict-sources for FC3 test released, or for targeted policy replace "strict" with "targeted" -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From selinux at comcast.net Tue Jul 20 16:19:31 2004 From: selinux at comcast.net (Tom London) Date: Tue, 20 Jul 2004 09:19:31 -0700 Subject: hpoj? In-Reply-To: <200407201453.09844.russell@coker.com.au> References: <40FC0197.1080104@comcast.net> <200407201453.09844.russell@coker.com.au> Message-ID: <40FD4613.40407@comcast.net> From what I understand, ptal implements the mechanism to connect to bidirectional printers/scanners/.... In my case, I have a USB connected HP office jet (an HP PSC-950). I'm guessing it scans through /proc/bus/usb to discover appropriate devices. I made the change you suggested (adding 'allow' for etc_t and etc_runtime_t), and did a 'make install'. 'run_init /etc/rc.d/init.d/hpoj start' now gets a quick 'denied' when attemping to create the socket ('usb:PSC_900_Series'): Jul 20 07:17:56 fedora kernel: audit(1090333076.788:0): avc: denied { create } for pid=3684 exe=/usr/sbin/ptal-mlcd name=usb:PSC_900_Series scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:var_run_t tclass=sock_file Jul 20 07:17:56 fedora ptal-mlcd: FATAL ERROR at ExMgr.cpp:1250, dev=, pid=3684, e=13, t=1090333076 bind(/var/run/ptal-mlcd/usb:PSC_900_Series) failed! Ensure /var/run/ptal-mlcd/ exists. The above shows ptal failing to create sock-file '/var/run/ptal-mcld/usb:....'). (Shouldn't the tcontext be 'ptal_var_run_t'????) Jul 20 07:17:56 fedora kernel: audit(1090333076.799:0): avc: denied { search } for pid=3685 exe=/usr/sbin/ptal-printd name=root dev=hda2 ino=1196033 scontext=system_u:system_r:ptal_t tcontext=root:object_r:staff_home_dir_t tclass=dir I don't know why ptal is trying to seach '/root'. Jul 20 07:17:56 fedora kernel: audit(1090333076.800:0): avc: denied { read } for pid=3685 exe=/usr/sbin/ptal-printd name=mlc:usb:PSC_900_Series dev=hda2 ino=738368 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:etc_t tclass=file 'find / -inum 738368' -> /etc/ptal/mlc:usb:PSC_900_Series -rw-rw---- root lp system_u:object_r:etc_runtime_t ptal-printd-like Jul 20 07:17:56 fedora kernel: audit(1090333076.800:0): avc: denied { getattr } for pid=3685 exe=/usr/sbin/ptal-printd path=/etc/ptal/ptal-printd-like dev=hda2 ino=737289 scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:etc_runtime_t tclass=file Jul 20 07:17:56 fedora ptal-printd: ptal-printd(mlc:usb:PSC_900_Series): Unable to read file permissions from "/etc/ptal/ptal-printd-like"! Jul 20 07:17:58 fedora ptal-photod: ptal-photod(mlc:usb:PSC_900_Series) successfully initialized, listening on port 5703. One of the 'ptal' daemons has started, but others have not. tom Russell Coker wrote: >On Tue, 20 Jul 2004 03:15, Tom London wrote: > > >>Audit2allow on permissive avc's yield: >>allow ptal_t etc_runtime_t:file { getattr }; >>allow ptal_t etc_t:file { read }; >> >> > >For file access whenever read access is requested you should allow getattr. >For a file type such etc_runtime_t which contains nothing secret if you allow >getattr you should allow read. So I added the following to my tree: > >allow ptal_t { etc_t etc_runtime_t }:file { getattr read }; > > > >>allow ptal_t staff_home_dir_t:dir { search }; >> >> > >What does ptal do? Why does it need such access? > > > >>allow ptal_t usbdevfs_t:dir { getattr read }; >> >> > >Again, what is it trying to do here? I've never used ptal so I don't know >what we should be permitting it to do. > > > >>allow ptal_t var_run_t:fifo_file { create read setattr }; >>allow ptal_t var_run_t:sock_file { create setattr }; >> >> > >For the sock_file and the fifo_file in question you didn't provide enough >information to determine which directory they are in. Please repeat the >tests and use "find /var/run -inum ..." to find the full path. > >If they are under /var/run/ptal-printd or /var/run/ptal-mlcd then they should >have the correct type and there should not be any problem (in which case >there is some strange mis-labelling issue). If they are not under those >directories then I will need to know the directories that they are in to >write the correct policy. > > > From selinux at comcast.net Tue Jul 20 16:35:16 2004 From: selinux at comcast.net (Tom London) Date: Tue, 20 Jul 2004 09:35:16 -0700 Subject: .udev.tdb ? In-Reply-To: <200407201716.34309.russell@coker.com.au> References: <40FC907D.7010104@comcast.net> <200407201716.34309.russell@coker.com.au> Message-ID: <40FD49C4.1060200@comcast.net> Yikes.... sorry, but this doesn't look right.... now produces hordes of 'restorecon' avcs.... Jul 20 09:23:46 fedora kernel: audit(1090340592.421:0): avc: denied { read write } for pid=991 exe=/sbin/restorecon path=/dev/.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:udev_tbl_t tclass=file Jul 20 09:23:47 fedora kernel: audit(1090340592.431:0): avc: denied { read write } for pid=992 exe=/sbin/restorecon path=/dev/.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:udev_tbl_t tclass=file Jul 20 09:23:47 fedora kernel: audit(1090340600.740:0): avc: denied { unlink } for pid=1297 exe=/sbin/udev name=microcode dev=hda2 ino=2689375 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:device_t tclass=lnk_file Jul 20 09:23:47 fedora kernel: audit(1090340600.759:0): avc: denied { read write } for pid=1309 exe=/sbin/restorecon path=/dev/.udev.tdb dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t tcontext=system_u:object_r:udev_tbl_t tclass=file Russell Coker wrote: >On Tue, 20 Jul 2004 13:24, Tom London wrote: > > >>I'm getting lots of of 'denied' avc for /dev/.udev.tdb from /sbin/udev. >>I see an entry in file_contexts for '/dev/udev.tbl' (which doesn't >>seem to exist on my system). Has .udev.tbd replaced udev.tbl? >>(udev_db in /etc/udev/udev.conf is set to /dev/.udev.tdb). >> >> > >Your analysis sounds reasonable. How do things work if you put the following >in udev.fc, run "make install" and then run "restorecon /dev/.udev.tdb"? >/dev/\.udev\.tdb -- system_u:object_r:udev_tbl_t > > > From selinux at comcast.net Tue Jul 20 18:15:07 2004 From: selinux at comcast.net (Tom London) Date: Tue, 20 Jul 2004 11:15:07 -0700 Subject: hpoj? In-Reply-To: <40FD4613.40407@comcast.net> References: <40FC0197.1080104@comcast.net> <200407201453.09844.russell@coker.com.au> <40FD4613.40407@comcast.net> Message-ID: <40FD612B.9040908@comcast.net> I 'fiddled' a bit more with this. The following additions to cups.te seem to make it work: allow ptal_t { etc_t etc_runtime_t }:file { getattr read }; ifdef(`usbmodules.te', ` r_dir_file(ptal_t, usbdevfs_t) ') file_type_auto_trans(ptal_t, var_run_t, ptal_var_run_t) The 'allow' you provided lets ptal read /etc/ptal, etc. The 'ifdef' mimics the entries for cups. I'm guessing that ptal needs to 'discover' the USB devices it is to control. The 'file_type_auto_trans' causes the files created in /var/run/ptal* have the correct context. tom Tom London wrote: > From what I understand, ptal implements the mechanism > to connect to bidirectional printers/scanners/.... > In my case, I have a USB connected HP office > jet (an HP PSC-950). I'm guessing it scans > through /proc/bus/usb to discover appropriate > devices. > > I made the change you suggested (adding 'allow' for etc_t > and etc_runtime_t), and did a 'make install'. > 'run_init /etc/rc.d/init.d/hpoj start' now gets > a quick 'denied' when attemping to create the socket > ('usb:PSC_900_Series'): > > Jul 20 07:17:56 fedora kernel: audit(1090333076.788:0): avc: > denied { create } for pid=3684 exe=/usr/sbin/ptal-mlcd > name=usb:PSC_900_Series scontext=system_u:system_r:ptal_t > tcontext=system_u:object_r:var_run_t tclass=sock_file > Jul 20 07:17:56 fedora ptal-mlcd: FATAL ERROR at ExMgr.cpp:1250, > dev=, pid=3684, e=13, t=1090333076 > bind(/var/run/ptal-mlcd/usb:PSC_900_Series) failed! Ensure > /var/run/ptal-mlcd/ exists. > > The above shows ptal failing to create sock-file > '/var/run/ptal-mcld/usb:....'). > (Shouldn't the tcontext be 'ptal_var_run_t'????) > > Jul 20 07:17:56 fedora kernel: audit(1090333076.799:0): avc: > denied { search } for pid=3685 exe=/usr/sbin/ptal-printd name=root > dev=hda2 ino=1196033 scontext=system_u:system_r:ptal_t > tcontext=root:object_r:staff_home_dir_t tclass=dir > > I don't know why ptal is trying to seach '/root'. > > Jul 20 07:17:56 fedora kernel: audit(1090333076.800:0): avc: > denied { read } for pid=3685 exe=/usr/sbin/ptal-printd > name=mlc:usb:PSC_900_Series dev=hda2 ino=738368 > scontext=system_u:system_r:ptal_t tcontext=system_u:object_r:etc_t > tclass=file > > 'find / -inum 738368' -> /etc/ptal/mlc:usb:PSC_900_Series > -rw-rw---- root lp system_u:object_r:etc_runtime_t > ptal-printd-like > > Jul 20 07:17:56 fedora kernel: audit(1090333076.800:0): avc: > denied { getattr } for pid=3685 exe=/usr/sbin/ptal-printd > path=/etc/ptal/ptal-printd-like dev=hda2 ino=737289 > scontext=system_u:system_r:ptal_t > tcontext=system_u:object_r:etc_runtime_t tclass=file > Jul 20 07:17:56 fedora ptal-printd: > ptal-printd(mlc:usb:PSC_900_Series): Unable to read file permissions > from "/etc/ptal/ptal-printd-like"! > Jul 20 07:17:58 fedora ptal-photod: > ptal-photod(mlc:usb:PSC_900_Series) successfully initialized, > listening on port 5703. > One of the 'ptal' daemons has started, but others have not. > > > tom > > > Russell Coker wrote: > >> On Tue, 20 Jul 2004 03:15, Tom London wrote: >> >> >>> Audit2allow on permissive avc's yield: >>> allow ptal_t etc_runtime_t:file { getattr }; >>> allow ptal_t etc_t:file { read }; >>> >> >> >> For file access whenever read access is requested you should allow >> getattr. For a file type such etc_runtime_t which contains nothing >> secret if you allow getattr you should allow read. So I added the >> following to my tree: >> >> allow ptal_t { etc_t etc_runtime_t }:file { getattr read }; >> >> >> >>> allow ptal_t staff_home_dir_t:dir { search }; >>> >> >> >> What does ptal do? Why does it need such access? >> >> >> >>> allow ptal_t usbdevfs_t:dir { getattr read }; >>> >> >> >> Again, what is it trying to do here? I've never used ptal so I don't >> know what we should be permitting it to do. >> >> >> >>> allow ptal_t var_run_t:fifo_file { create read setattr }; >>> allow ptal_t var_run_t:sock_file { create setattr }; >>> >> >> >> For the sock_file and the fifo_file in question you didn't provide >> enough information to determine which directory they are in. Please >> repeat the tests and use "find /var/run -inum ..." to find the full >> path. >> >> If they are under /var/run/ptal-printd or /var/run/ptal-mlcd then >> they should have the correct type and there should not be any problem >> (in which case there is some strange mis-labelling issue). If they >> are not under those directories then I will need to know the >> directories that they are in to write the correct policy. >> >> >> > From selinux at comcast.net Tue Jul 20 18:27:58 2004 From: selinux at comcast.net (Tom London) Date: Tue, 20 Jul 2004 11:27:58 -0700 Subject: /etc/exports, /usr/sbin/exportfs ... In-Reply-To: <200407201558.25886.russell@coker.com.au> References: <40FC9256.7040105@comcast.net> <200407201558.25886.russell@coker.com.au> Message-ID: <40FD642E.3050607@comcast.net> Thanks. That helped! tom Russell Coker wrote: >On Tue, 20 Jul 2004 13:32, Tom London wrote: > > >>My log shows the following failure: >> >>Jul 19 18:58:38 fedora kernel: audit(1090288718.937:0): avc: denied { >>read } for pid=2363 exe=/usr/sbin/exportfs name=exports dev=hda2 >>ino=4472848 scontext=system_u:system_r:nfsd_t >>tcontext=system_u:object_r:exports_t tclass=file >> >> > >allow nfsd_t exports_t:file { getattr read }; > >Add the above to domains/program/rpcd.te . > > > From mike at flyn.org Tue Jul 20 22:06:53 2004 From: mike at flyn.org (W. Michael Petullo) Date: Tue, 20 Jul 2004 17:06:53 -0500 (CDT) Subject: SELinux and stunnel In-Reply-To: <200407201520.58826.russell@coker.com.au> References: <35168.68.252.239.165.1090288176.squirrel@68.252.239.165> <200407201520.58826.russell@coker.com.au> Message-ID: <4945.66.151.13.189.1090361213.squirrel@66.151.13.189> >> I am using stunnel to create an encrypted tunnel for SMTP connections to >> my ISP. I have configured xinetd to execute stunnel appropriately when >> a connection is made to localhost:465. This has stopped working when >> using recent strict policies. I now see the following errors in my >> system logs: > inetd_child_t has access to /dev/urandom. If stunnel is labelled as > inetd_child_exec_t then things should just work for you. > > Is stunnel commonly used in any other way than through inetd? If not then > we'll just change the default policy to label it as inetd_child_exec_t. I use stunnel through inetd. It seems like a good way to use it. That's about all that I can attest to. -- Mike From russell at coker.com.au Wed Jul 21 06:13:38 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 21 Jul 2004 16:13:38 +1000 Subject: .udev.tdb ? In-Reply-To: <40FD49C4.1060200@comcast.net> References: <40FC907D.7010104@comcast.net> <200407201716.34309.russell@coker.com.au> <40FD49C4.1060200@comcast.net> Message-ID: <200407211613.38372.russell@coker.com.au> On Wed, 21 Jul 2004 02:35, Tom London wrote: > Yikes.... sorry, but this doesn't look right.... > now produces hordes of 'restorecon' avcs.... > > Jul 20 09:23:46 fedora kernel: audit(1090340592.421:0): avc: denied { > read write } for pid=991 exe=/sbin/restorecon path=/dev/.udev.tdb > dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t > tcontext=system_u:object_r:udev_tbl_t tclass=file udev calls restorecon to set the correct type of a device node it has just created. restorecon has no business in opening /dev/.udev.tdb and I really doubt that it is doing so. I expect that udev is opening /dev/.udev.tdb, not using fcntl(fd, F_SETFD, FD_CLOEXEC) to set the fd to close on execute, and not calling close(fd) before the exec. Please file a bugzilla report about this. To assist in tracking it down rename /sbin/restorecon to /sbin/restorecon.orig and put the following shell script in place as /sbin/restorecon: #!/bin/sh echo -n params: >> /root/file for n in $*; do echo -n "$n "; done >> /root/file echo "" >> /root/file ls -l /proc/self/fd >> /root/file exec /sbin/restorecon.orig $* Run the machine in permissive mode while doing this and don't bother about the AVC messages about not being permitted to write to /root/file. > Jul 20 09:23:47 fedora kernel: audit(1090340600.740:0): avc: denied { > unlink } for pid=1297 exe=/sbin/udev name=microcode dev=hda2 > ino=2689375 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:device_t tclass=lnk_file allow udev_t device_t:lnk_file create_file_perms; Add the above policy to allow this. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Wed Jul 21 06:40:00 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 21 Jul 2004 16:40:00 +1000 Subject: hpoj? In-Reply-To: <40FD4613.40407@comcast.net> References: <40FC0197.1080104@comcast.net> <200407201453.09844.russell@coker.com.au> <40FD4613.40407@comcast.net> Message-ID: <200407211640.00227.russell@coker.com.au> On Wed, 21 Jul 2004 02:19, Tom London wrote: > avc: denied { create } for pid=3684 exe=/usr/sbin/ptal-mlcd > name=usb:PSC_900_Series scontext=system_u:system_r:ptal_t > tcontext=system_u:object_r:var_run_t tclass=sock_file > fedora ptal-mlcd: FATAL ERROR at ExMgr.cpp:1250, > dev=, pid=3684, e=13, t=1090333076 > bind(/var/run/ptal-mlcd/usb:PSC_900_Series) failed! Ensure > /var/run/ptal-mlcd/ exists. > > The above shows ptal failing to create sock-file > '/var/run/ptal-mcld/usb:....'). > (Shouldn't the tcontext be 'ptal_var_run_t'????) Correct. The directory /var/run/ptal-mcld should have type ptal_var_run_t. The problem was that the below two lines in cups.fc had "--" specified for the type. Remove the "--" and relabel /var/run and things should be fine. /var/run/ptal-printd(/.*)? system_u:object_r:ptal_var_run_t /var/run/ptal-mlcd(/.*)? system_u:object_r:ptal_var_run_t > Jul 20 07:17:56 fedora kernel: audit(1090333076.799:0): avc: > denied { search } for pid=3685 exe=/usr/sbin/ptal-printd name=root > dev=hda2 ino=1196033 scontext=system_u:system_r:ptal_t > tcontext=root:object_r:staff_home_dir_t tclass=dir > > I don't know why ptal is trying to seach '/root'. Lots of daemons do that. dontaudit is the correct solution to that. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Wed Jul 21 06:45:15 2004 From: russell at coker.com.au (Russell Coker) Date: Wed, 21 Jul 2004 16:45:15 +1000 Subject: hpoj? In-Reply-To: <40FD612B.9040908@comcast.net> References: <40FC0197.1080104@comcast.net> <40FD4613.40407@comcast.net> <40FD612B.9040908@comcast.net> Message-ID: <200407211645.15602.russell@coker.com.au> On Wed, 21 Jul 2004 04:15, Tom London wrote: > ifdef(`usbmodules.te', ` > r_dir_file(ptal_t, usbdevfs_t) > ') I think that the above will be needed even without usbmodules.te. Also note that usbdevfs_t is defined in types/file.te so you won't have any compile errors, which is the main reason for ifdef's. I'll add that to my policy without the ifdef. > file_type_auto_trans(ptal_t, var_run_t, ptal_var_run_t) This isn't what we want. It allows ptal_t to directly create sock_file, lnk_file, fifo_file, and dir entries under /var/run which is more access than it needs. Fixing the bug in cups.fc as described in my previous message will solve the problem. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From selinux at comcast.net Wed Jul 21 14:36:16 2004 From: selinux at comcast.net (Tom London) Date: Wed, 21 Jul 2004 07:36:16 -0700 Subject: hpoj? In-Reply-To: <200407211645.15602.russell@coker.com.au> References: <40FC0197.1080104@comcast.net> <40FD4613.40407@comcast.net> <40FD612B.9040908@comcast.net> <200407211645.15602.russell@coker.com.au> Message-ID: <40FE7F60.20202@comcast.net> EXCELLENT! Combined with previous fix to cups.fc, all is working now, and a much better fix than the file_type_auto_trans() hack I came up with. Thanks! tom Russell Coker wrote: >On Wed, 21 Jul 2004 04:15, Tom London wrote: > > >>ifdef(`usbmodules.te', ` >>r_dir_file(ptal_t, usbdevfs_t) >>') >> >> > >I think that the above will be needed even without usbmodules.te. Also note >that usbdevfs_t is defined in types/file.te so you won't have any compile >errors, which is the main reason for ifdef's. I'll add that to my policy >without the ifdef. > > > >>file_type_auto_trans(ptal_t, var_run_t, ptal_var_run_t) >> >> > >This isn't what we want. It allows ptal_t to directly create sock_file, >lnk_file, fifo_file, and dir entries under /var/run which is more access than >it needs. Fixing the bug in cups.fc as described in my previous message will >solve the problem. > > > From selinux at comcast.net Wed Jul 21 16:05:31 2004 From: selinux at comcast.net (Tom London) Date: Wed, 21 Jul 2004 09:05:31 -0700 Subject: .udev.tdb ? In-Reply-To: <200407211613.38372.russell@coker.com.au> References: <40FC907D.7010104@comcast.net> <200407201716.34309.russell@coker.com.au> <40FD49C4.1060200@comcast.net> <200407211613.38372.russell@coker.com.au> Message-ID: <40FE944B.5020507@comcast.net> OK, done. Here are a few entries from the resulting trace of calls to restorecon from a clean reboot with 'enforcing=0'. The first call is the last one in the trace prior to a number of calls from udev: params:/var/run/sm-client.pid total 4 lrwx------ 1 root root 64 Jul 21 07:28 0 -> /dev/pts/0 l-wx------ 1 root root 64 Jul 21 07:28 1 -> /root/file lrwx------ 1 root root 64 Jul 21 07:28 2 -> /dev/pts/0 lr-x------ 1 root root 64 Jul 21 07:28 3 -> /proc/2423/fd params:/dev/lp0 total 6 lrwx------ 1 root root 64 Jul 21 07:28 0 -> socket:[906] l-wx------ 1 root root 64 Jul 21 07:28 1 -> /root/file l-wx------ 1 root root 64 Jul 21 07:28 2 -> pipe:[914] lrwx------ 1 root root 64 Jul 21 07:28 3 -> socket:[915] lrwx------ 1 root root 64 Jul 21 07:28 4 -> /dev/.udev.tdb lr-x------ 1 root root 64 Jul 21 07:28 5 -> /proc/2446/fd params:/dev/snd/timer total 6 lrwx------ 1 root root 64 Jul 21 07:28 0 -> socket:[906] l-wx------ 1 root root 64 Jul 21 07:28 1 -> /root/file l-wx------ 1 root root 64 Jul 21 07:28 2 -> pipe:[914] lrwx------ 1 root root 64 Jul 21 07:28 3 -> socket:[915] lrwx------ 1 root root 64 Jul 21 07:28 4 -> /dev/.udev.tdb lr-x------ 1 root root 64 Jul 21 07:28 5 -> /proc/2632/fd ...... (many more) As you suspected, it looks like udev is leaving fd 4 (/dev/.udev.tdb) open across the exec (i.e., has not set FD_CLOEXEC). I've bugzilla-ed this here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128304 Thanks for helping track this down. tom Russell Coker wrote: >On Wed, 21 Jul 2004 02:35, Tom London wrote: > > >>Yikes.... sorry, but this doesn't look right.... >>now produces hordes of 'restorecon' avcs.... >> >>Jul 20 09:23:46 fedora kernel: audit(1090340592.421:0): avc: denied { >>read write } for pid=991 exe=/sbin/restorecon path=/dev/.udev.tdb >>dev=hda2 ino=2698913 scontext=system_u:system_r:restorecon_t >>tcontext=system_u:object_r:udev_tbl_t tclass=file >> >> > >udev calls restorecon to set the correct type of a device node it has just >created. > >restorecon has no business in opening /dev/.udev.tdb and I really doubt that >it is doing so. I expect that udev is opening /dev/.udev.tdb, not using >fcntl(fd, F_SETFD, FD_CLOEXEC) to set the fd to close on execute, and not >calling close(fd) before the exec. > >Please file a bugzilla report about this. To assist in tracking it down >rename /sbin/restorecon to /sbin/restorecon.orig and put the following shell >script in place as /sbin/restorecon: >#!/bin/sh >echo -n params: >> /root/file >for n in $*; do echo -n "$n "; done >> /root/file >echo "" >> /root/file >ls -l /proc/self/fd >> /root/file >exec /sbin/restorecon.orig $* > >Run the machine in permissive mode while doing this and don't bother about the >AVC messages about not being permitted to write to /root/file. > > > >>Jul 20 09:23:47 fedora kernel: audit(1090340600.740:0): avc: denied { >>unlink } for pid=1297 exe=/sbin/udev name=microcode dev=hda2 >>ino=2689375 scontext=system_u:system_r:udev_t >>tcontext=system_u:object_r:device_t tclass=lnk_file >> >> > >allow udev_t device_t:lnk_file create_file_perms; >Add the above policy to allow this. > > > From selinux at comcast.net Wed Jul 21 17:16:24 2004 From: selinux at comcast.net (Tom London) Date: Wed, 21 Jul 2004 10:16:24 -0700 Subject: /dev/jsflash -> mouse_device_t ?? Message-ID: <40FEA4E8.2080501@comcast.net> I think the latest file_contexts is mislabeling /dev/jsflash.... The problem line is types.fc:/u?dev/js.* -c system_u:object_r:mouse_device_t It overrides earlier lines: types.fc:/u?dev/jsfd -b system_u:object_r:fixed_disk_device_t types.fc:/u?dev/jsflash -c system_u:object_r:fixed_disk_device_t tom From selinux at comcast.net Wed Jul 21 18:09:23 2004 From: selinux at comcast.net (Tom London) Date: Wed, 21 Jul 2004 11:09:23 -0700 Subject: rhgb - bootup denials Message-ID: <40FEB153.1040108@comcast.net> With strict/enforcing, I get the following avcs at bootup. Looks like rhgb does not 'run'; I get a text-style boot display. Jul 21 10:47:52 fedora kernel: audit(1090406834.263:0): avc: denied { mounton } for pid=533 exe=/usr/bin/rhgb path=/initrd dev=ram0 ino=2 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:file_t tclass=dir Jul 21 10:47:52 fedora kernel: audit(1090406834.263:0): avc: denied { sys_admin } for pid=533 exe=/usr/bin/rhgb capability=21 scontext=system_u:system_r:rhgb_t tcontext=system_u:system_r:rhgb_t tclass=capability audit2allow on this yields: allow rhgb_t file_t:dir { mounton }; allow rhgb_t rhgb_t:capability { sys_admin }; but this seems a bit too 'heavy'..... tom From russell at coker.com.au Wed Jul 21 23:07:59 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 22 Jul 2004 09:07:59 +1000 Subject: /dev/jsflash -> mouse_device_t ?? In-Reply-To: <40FEA4E8.2080501@comcast.net> References: <40FEA4E8.2080501@comcast.net> Message-ID: <200407220907.59963.russell@coker.com.au> On Thu, 22 Jul 2004 03:16, Tom London wrote: > I think the latest file_contexts is mislabeling /dev/jsflash.... > > The problem line is > types.fc:/u?dev/js.* -c system_u:object_r:mouse_device_t > > It overrides earlier lines: > types.fc:/u?dev/jsfd -b > system_u:object_r:fixed_disk_device_t > types.fc:/u?dev/jsflash -c > system_u:object_r:fixed_disk_device_t It won't affect jsfd because of the -b vs -c issue. The correct thing to do is to move the jsflash line after the js.* line. It's in my tree, I'll send a patch to Steve when he's ready to do a CVS commit. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From russell at coker.com.au Wed Jul 21 23:33:10 2004 From: russell at coker.com.au (Russell Coker) Date: Thu, 22 Jul 2004 09:33:10 +1000 Subject: rhgb - bootup denials In-Reply-To: <40FEB153.1040108@comcast.net> References: <40FEB153.1040108@comcast.net> Message-ID: <200407220933.11001.russell@coker.com.au> On Thu, 22 Jul 2004 04:09, Tom London wrote: > With strict/enforcing, I get the following avcs at bootup. > Looks like rhgb does not 'run'; I get a text-style boot > display. Is this on FC2, FC3T1 or RawHide? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From selinux at comcast.net Wed Jul 21 23:36:28 2004 From: selinux at comcast.net (Tom London) Date: Wed, 21 Jul 2004 16:36:28 -0700 Subject: rhgb - bootup denials In-Reply-To: <200407220933.11001.russell@coker.com.au> References: <40FEB153.1040108@comcast.net> <200407220933.11001.russell@coker.com.au> Message-ID: <40FEFDFC.8060408@comcast.net> Oops... sorry. This is on FC3T1. tom Russell Coker wrote: >On Thu, 22 Jul 2004 04:09, Tom London wrote: > > >>With strict/enforcing, I get the following avcs at bootup. >>Looks like rhgb does not 'run'; I get a text-style boot >>display. >> >> > >Is this on FC2, FC3T1 or RawHide? > > > From selinux at comcast.net Wed Jul 21 23:43:11 2004 From: selinux at comcast.net (Tom London) Date: Wed, 21 Jul 2004 16:43:11 -0700 Subject: rhgb - bootup denials In-Reply-To: <200407220933.11001.russell@coker.com.au> References: <40FEB153.1040108@comcast.net> <200407220933.11001.russell@coker.com.au> Message-ID: <40FEFF8F.5030604@comcast.net> Let me be more precise: FC3T1, with latest updates from development tree: rhgb-0.12.2-1 Russell Coker wrote: >On Thu, 22 Jul 2004 04:09, Tom London wrote: > > >>With strict/enforcing, I get the following avcs at bootup. >>Looks like rhgb does not 'run'; I get a text-style boot >>display. >> >> > >Is this on FC2, FC3T1 or RawHide? > > > From selinux at comcast.net Thu Jul 22 17:20:12 2004 From: selinux at comcast.net (Tom London) Date: Thu, 22 Jul 2004 10:20:12 -0700 Subject: mozilla-1.7 startup, lib_t vs. shlib_t? Message-ID: <40FFF74C.4040409@comcast.net> [running latest FC3T1 w/ mods from devel tree, strict/enforcing] When starting up mozilla as normal user, I noticed the following avc's: Jul 22 06:58:24 fedora kernel: audit(1090504704.981:0): avc: denied { execute } for pid=3527 path=/usr/java/j2sdk1.5.0/jre/lib/i386/client/libjvm.so dev=hda2 ino=4279850 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:lib_t tclass=file Jul 22 06:58:34 fedora kernel: audit(1090504714.317:0): avc: denied { execute } for pid=3517 path=/usr/java/j2sdk1.5.0/jre/lib/i386/libjavaplugin_nscp.so dev=hda2 ino=4279868 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:lib_t tclass=file Jul 22 06:59:06 fedora kernel: audit(1090504746.751:0): avc: denied { read } for pid=3517 exe=/usr/lib/mozilla-1.7/mozilla-bin name=tmp dev=hda2 ino=4112506 scontext=user_u:user_r:user_mozilla_t tcontext=system_u:object_r:tmp_t tclass=lnk_file The last of these describes an access to the link '/usr/tmp->../var/tmp'. [I can't tell if this is 'breaking' anything, so I don't know if anything needs to change here. Help anyone?] The first 2 denials appear to interfere with plugins. Going into permissive mode identifies the following list of 'java library executes' from scontext=user_u:user_r:user_mozilla_t: /usr/java/j2sdk1.5.0/jre/lib/i386/client/libjvm.so /usr/java/j2sdk1.5.0/jre/lib/i386/libjavaplugin_nscp.so /usr/java/j2sdk1.5.0/jre/lib/i386/native_threads/libhpi.so /usr/java/j2sdk1.5.0/jre/lib/i386/libverify.so /usr/java/j2sdk1.5.0/jre/lib/i386/libjava.so /usr/java/j2sdk1.5.0/jre/lib/i386/libzip.so I changed their contexts to 'system_u:object_r:shlib_t' and plugins started working again. The j2 entries in types.fc are: /usr/java/j2.*/bin(/.*)? system_u:object_r:bin_t /usr/java/j2.*/jre/lib(64)?/i386(/.*)? system_u:object_r:lib_t /usr/java/j2.*/plugin/i386(/.*)?/lib[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t I admit to not really understanding what needs to be here. Is it appropriate to change the second line to /usr/java/j2.*/jre/lib(64)?/i386(/.*)? system_u:object_r:shlib_t or something more specific to 1.5.0? tom From selinux at comcast.net Thu Jul 22 20:25:48 2004 From: selinux at comcast.net (Tom London) Date: Thu, 22 Jul 2004 13:25:48 -0700 Subject: sshd....denied transition...funny looking avc Message-ID: <410022CC.6050106@comcast.net> [running latest FC3T1 w/ latest mods from devel tree, strict/enforcing kernel-2.6.7-1.494, openssh-3.8.1p1-4] Attempting to scp into this host fails with 'Read from remote host HOST: connection reset by peer' /var/log/messages on this host shows: Jul 22 12:05:18 fedora sshd(pam_unix)[13899]: session opened for user root by (uid=0) Jul 22 12:05:18 fedora kernel: audit(1090523118.784:0): avc: denied { transition } for pid=13899 exe=/usr/sbin/sshd Jul 22 12:05:26 fedora sshd(pam_unix)[13902]: session opened for user root by (uid=0) Jul 22 12:05:26 fedora kernel: audit(1090523126.143:0): avc: denied { transition } for pid=13902 exe=/usr/sbin/sshd [There appear to be 145 blank characters after 'kernel:' and before 'audit(' on the lines above.] /usr/sbin/sshd appears to be labeled correctly; -rwxr-xr-x root root system_u:object_r:sshd_exec_t /usr/sbin/sshd tom From venon at fugusec.net Thu Jul 22 22:31:58 2004 From: venon at fugusec.net (Alexis Wagner) Date: Thu, 22 Jul 2004 18:31:58 -0400 Subject: auxv entry ? Message-ID: <4100405E.90807@fugusec.net> Hi, How do I check if my glibc have the auxv entry for AT_SECURE ? By the way, what is a auxv entry ! Thank you. From tweeksjunk2 at theweeks.org Fri Jul 23 03:11:53 2004 From: tweeksjunk2 at theweeks.org (Tom Weeks) Date: Thu, 22 Jul 2004 22:11:53 -0500 Subject: Best Source to learn more about seLinux? In-Reply-To: <20040719153833.SYDY29389.mm-ismta4.bizmailsrvcs.net@ICEMAN> References: <20040719153833.SYDY29389.mm-ismta4.bizmailsrvcs.net@ICEMAN> Message-ID: <200407222211.53787.tweeksjunk2@theweeks.org> On Monday 19 July 2004 10:38 am, Don Patterson wrote: > There is also documentation and information about training that we offer on > our website at www.tresys.com/selinux. > > Don Patterson > Tresys Technology > http://www.tresys.com Thanks for the info.. I'm a trainer myself.. :) Tweeks From russell at coker.com.au Fri Jul 23 05:14:57 2004 From: russell at coker.com.au (Russell Coker) Date: Fri, 23 Jul 2004 15:14:57 +1000 Subject: sshd....denied transition...funny looking avc In-Reply-To: <410022CC.6050106@comcast.net> References: <410022CC.6050106@comcast.net> Message-ID: <200407231514.57613.russell@coker.com.au> On Fri, 23 Jul 2004 06:25, Tom London wrote: > [running latest FC3T1 w/ latest mods from devel tree, strict/enforcing > kernel-2.6.7-1.494, openssh-3.8.1p1-4] > > Attempting to scp into this host fails with > 'Read from remote host HOST: connection reset by peer' Please send me a .tgz format copy of your policy source directory after running "make clean". Also let me know whether you have sshd run from inetd or as a daemon. > [There appear to be 145 blank characters after 'kernel:' and before > 'audit(' on the lines above.] This is a kernel bug we've seen before. It seemed to appear after the transition to the new auditing model. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page From selinux at comcast.net Fri Jul 23 16:18:37 2004 From: selinux at comcast.net (Tom London) Date: Fri, 23 Jul 2004 09:18:37 -0700 Subject: sshd....denied transition...funny looking avc (working with latest policy files) In-Reply-To: <200407231514.57613.russell@coker.com.au> References: <410022CC.6050106@comcast.net> <200407231514.57613.russell@coker.com.au> Message-ID: <41013A5D.6040001@comcast.net> Uhhh.... I just installed the latest strict policy (selinux-policy-strict-sources-1.15.7-4) and sshd now works...... These are now the only messages from 'ssh localhost': Jul 23 09:14:30 fedora kernel: audit(1090599270.275:0): avc: denied { write } for pid=13806 exe=/usr/bin/ssh name=krb5.conf dev=hda2 ino=4474826 scontext=root:sysadm_r:sysadm_ssh_t tcontext=system_u:object_r:krb5_conf_t tclass=file Jul 23 09:14:30 fedora kernel: audit(1090599270.324:0): avc: denied { write } for pid=13806 exe=/usr/bin/ssh name=krb5.conf dev=hda2 ino=4474826 scontext=root:sysadm_r:sysadm_ssh_t tcontext=system_u:object_r:krb5_conf_t tclass=file Jul 23 09:14:34 fedora sshd(pam_unix)[13809]: session opened for user root by root(uid=0) tom Russell Coker wrote: >On Fri, 23 Jul 2004 06:25, Tom London wrote: > > >>[running latest FC3T1 w/ latest mods from devel tree, strict/enforcing >>kernel-2.6.7-1.494, openssh-3.8.1p1-4] >> >>Attempting to scp into this host fails with >>'Read from remote host HOST: connection reset by peer' >> >> > >Please send me a .tgz format copy of your policy source directory after >running "make clean". Also let me know whether you have sshd run from inetd >or as a daemon. > > > >>[There appear to be 145 blank characters after 'kernel:' and before >>'audit(' on the lines above.] >> >> > >This is a kernel bug we've seen before. It seemed to appear after the >transition to the new auditing model. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at epoch.ncsc.mil Mon Jul 26 14:32:39 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 26 Jul 2004 10:32:39 -0400 Subject: auxv entry ? In-Reply-To: <4100405E.90807@fugusec.net> References: <4100405E.90807@fugusec.net> Message-ID: <1090852359.24945.30.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-22 at 18:31, Alexis Wagner wrote: > Hi, > > How do I check if my glibc have the auxv entry for AT_SECURE ? > > By the way, what is a auxv entry ! Fedora Core includes the updated glibc. It is an entry in the ELF auxiliary table put on the initial stack; the kernel uses it to convey to glibc whether or not it should enable its secure mode. This allows secure mode to be enabled not only for setuid/setgid binaries but also for other kinds of changes (e.g. capabilities, SELinux role/domain changes, etc). -- Stephen Smalley National Security Agency From sds at epoch.ncsc.mil Mon Jul 26 15:14:13 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Mon, 26 Jul 2004 11:14:13 -0400 Subject: sshd....denied transition...funny looking avc In-Reply-To: <410022CC.6050106@comcast.net> References: <410022CC.6050106@comcast.net> Message-ID: <1090854853.24945.79.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2004-07-22 at 16:25, Tom London wrote: > [running latest FC3T1 w/ latest mods from devel tree, strict/enforcing > kernel-2.6.7-1.494, openssh-3.8.1p1-4] > > Attempting to scp into this host fails with > 'Read from remote host HOST: connection reset by peer' Looks like run_ssh_inetd tunable was enabled (wrongly) in tunable.te; this replaces the normal transition from initrc_t (normal daemon startup) with one from inetd_t (inetd-based startup), so sshd is left in the wrong domain. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Mon Jul 26 17:45:41 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 26 Jul 2004 13:45:41 -0400 Subject: mozilla-1.7 startup, lib_t vs. shlib_t? In-Reply-To: <40FFF74C.4040409@comcast.net> References: <40FFF74C.4040409@comcast.net> Message-ID: <41054345.10801@redhat.com> Tom London wrote: > [running latest FC3T1 w/ mods from devel tree, strict/enforcing] > > When starting up mozilla as normal user, I noticed the following avc's: > > Jul 22 06:58:24 fedora kernel: audit(1090504704.981:0): avc: denied > { execute } for pid=3527 > path=/usr/java/j2sdk1.5.0/jre/lib/i386/client/libjvm.so dev=hda2 > ino=4279850 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:object_r:lib_t tclass=file > Jul 22 06:58:34 fedora kernel: audit(1090504714.317:0): avc: denied > { execute } for pid=3517 > path=/usr/java/j2sdk1.5.0/jre/lib/i386/libjavaplugin_nscp.so dev=hda2 > ino=4279868 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:object_r:lib_t tclass=file > Jul 22 06:59:06 fedora kernel: audit(1090504746.751:0): avc: denied > { read } for pid=3517 exe=/usr/lib/mozilla-1.7/mozilla-bin name=tmp > dev=hda2 ino=4112506 scontext=user_u:user_r:user_mozilla_t > tcontext=system_u:object_r:tmp_t tclass=lnk_file > > The last of these describes an access to the link '/usr/tmp->../var/tmp'. > [I can't tell if this is 'breaking' anything, so I don't know if anything > needs to change here. Help anyone?] > > The first 2 denials appear to interfere with plugins. > > Going into permissive mode identifies the following list of > 'java library executes' from scontext=user_u:user_r:user_mozilla_t: > /usr/java/j2sdk1.5.0/jre/lib/i386/client/libjvm.so > /usr/java/j2sdk1.5.0/jre/lib/i386/libjavaplugin_nscp.so > /usr/java/j2sdk1.5.0/jre/lib/i386/native_threads/libhpi.so > /usr/java/j2sdk1.5.0/jre/lib/i386/libverify.so > /usr/java/j2sdk1.5.0/jre/lib/i386/libjava.so > /usr/java/j2sdk1.5.0/jre/lib/i386/libzip.so > > I changed their contexts to 'system_u:object_r:shlib_t' > and plugins started working again. > > The j2 entries in types.fc are: > /usr/java/j2.*/bin(/.*)? system_u:object_r:bin_t > /usr/java/j2.*/jre/lib(64)?/i386(/.*)? system_u:object_r:lib_t > /usr/java/j2.*/plugin/i386(/.*)?/lib[^/]*\.so(\.[^/]*)* -- > system_u:object_r:shlib_t > > I admit to not really understanding what needs to be here. > Is it appropriate to change the second line to > /usr/java/j2.*/jre/lib(64)?/i386(/.*)? system_u:object_r:shlib_t > or something more specific to 1.5.0? > How about /usr/java/j2.*/jre/lib(64)?/i386(/.*)?[^/]*\.so(\.[^/]*)* -- system_u:object_r:shlib_t > tom > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From sopwith at redhat.com Tue Jul 27 17:39:17 2004 From: sopwith at redhat.com (Elliot Lee) Date: Tue, 27 Jul 2004 13:39:17 -0400 Subject: Fedora Project Mailing Lists reminder Message-ID: This is a reminder of the mailing lists for the Fedora Project, and the purpose of each list. You can view this information at http://fedora.redhat.com/participate/communicate/ When you're using these mailing lists, please take the time to choose the one that is most appropriate to your post. If you don't know the right mailing list to use for a question or discussion, please contact me. This will help you get the best possible answer for your question, and keep other list subscribers happy! Mailing Lists Mailing lists are email addresses which send email to all users subscribed to the mailing list. Sending an email to a mailing list reaches all users interested in discussing a specific topic and users available to help other users with the topic. The following mailing lists are available. To subscribe, send email to -request at redhat.com (replace with the desired mailing list name such as fedora-list) with the word subscribe in the subject. fedora-announce-list - Announcements of changes and events. To stay aware of news, subscribe to this list. fedora-list - For users of releases. If you want help with a problem installing or using , this is the list for you. fedora-test-list - For testers of test releases. If you would like to discuss experiences using TEST releases, this is the list for you. fedora-devel-list - For developers, developers, developers. If you are interested in helping create releases, this is the list for you. fedora-docs-list - For participants of the docs project fedora-desktop-list - For discussions about desktop issues such as user interfaces, artwork, and usability fedora-config-list - For discussions about the development of configuration tools fedora-legacy-announce - For announcements about the Fedora Legacy Project fedora-legacy-list - For discussions about the Fedora Legacy Project fedora-selinux-list - For discussions about the Fedora SELinux Project fedora-de-list - For discussions about Fedora in the German language fedora-es-list - For discussions about Fedora in the Spanish language fedora-ja-list - For discussions about Fedora in the Japanese language fedora-i18n-list - For discussions about the internationalization of Fedora Core fedora-trans-list - For discussions about translating the software and documentation associated with the Fedora Project German: fedora-trans-de French: fedora-trans-fr Spanish: fedora-trans-es Italian: fedora-trans-it Brazilian Portuguese: fedora-trans-pt_br Japanese: fedora-trans-ja Korean: fedora-trans-ko Simplified Chinese: fedora-trans-zh_cn Traditional Chinese: fedora-trans-zh_tw From sysware at portoweb.com.br Wed Jul 28 16:44:38 2004 From: sysware at portoweb.com.br (Bruno Castro da Silva) Date: Wed, 28 Jul 2004 13:44:38 -0300 Subject: How to use other LSM modules Message-ID: <4107d7f6.35.ed8.23115@portoweb.com.br> Hi, I'm trying to install, on fedora core 2, some modules which also use the LSM framework. Currently selinux is disabled (/usr/bin/selinuxenabled returns 1), but I can't seem to load any other modules. I always get the "There is already a security framework initialized, register_security failed" error. Is there anyway to completly disable selinux or to allow other LSM-based software to run? Also, I think this problem wouldn't exist if selinux was compiled as a module. Is there any reason why this isn't so? Thanks in advance! Bruno From sds at epoch.ncsc.mil Wed Jul 28 19:00:31 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Wed, 28 Jul 2004 15:00:31 -0400 Subject: How to use other LSM modules In-Reply-To: <4107d7f6.35.ed8.23115@portoweb.com.br> References: <4107d7f6.35.ed8.23115@portoweb.com.br> Message-ID: <1091041231.6886.149.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2004-07-28 at 12:44, Bruno Castro da Silva wrote: > I'm trying to install, on fedora core 2, some modules which > also use the LSM framework. Currently selinux is disabled > (/usr/bin/selinuxenabled returns 1), but I can't seem to > load any other modules. > > I always get the "There is already a security framework > initialized, register_security failed" error. > > Is there anyway to completly disable selinux or to allow > other LSM-based software to run? > > Also, I think this problem wouldn't exist if selinux was > compiled as a module. Is there any reason why this isn't so? Both SELinux and the capability module are built into the kernel (and normally stack together); if you disable SELinux, then the capability module simply becomes the primary security module. So you actually want to disable the capability module too. You can boot with selinux=0 capability.disable=1 on the kernel command line to disable them both, I think. SELinux needs to be built-in; it requires early initialization in order to track all kernel objects and apply security labels to them. Security subsystem is too tightly coupled to the core kernel anyway to usefully deal with it as a separate "module"; the LSM API is too large and tightly coupled to the core kernel, and is not guaranteed any stability even within the stable kernel series. We attempted to support SELinux as a loadable module for a while during the development of LSM, but gave it up in 2002 in response to feedback from core kernel developers. -- Stephen Smalley National Security Agency From selinux at comcast.net Thu Jul 29 14:53:49 2004 From: selinux at comcast.net (Tom London) Date: Thu, 29 Jul 2004 07:53:49 -0700 Subject: latest dev pgks: strict/enforcing boot hangs.... Message-ID: <41090F7D.4050300@comcast.net> After installing the latest packages from the development tree, (including selinux-policy-strict-1.15.8-3, etc.), booting with strict/enforcing hangs (but it works with strict/permissive). [Same behavior with both 494 and 499 kernel. And I did a 'fixfiles relabel' to no avail.] Here are the last entries from the log: Jul 28 20:30:45 fedora ntpd[2203]: kernel time sync status 0040 Jul 28 20:30:45 fedora xinetd[2179]: xinetd Version 2.3.13 started with libwrap loadavg options compiled in. Jul 28 20:30:45 fedora xinetd[2179]: Started working: 1 available service Jul 28 20:30:45 fedora ntpd[2203]: frequency initialized 70.900 PPM from /var/lib/ntp/drift Jul 28 20:30:45 fedora ntpd[2203]: configure: keyword "authenticate" unknown, line ignored Jul 28 20:30:45 fedora kernel: Installing knfsd (copyright (C) 1996 okir at monad.swb.de). Jul 28 20:30:45 fedora kernel: SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts Jul 28 20:30:45 fedora nfs: Starting NFS services: succeeded Jul 28 20:30:45 fedora nfs: rpc.rquotad startup succeeded Jul 28 20:30:45 fedora nfs: rpc.nfsd startup succeeded Jul 28 20:30:45 fedora nfs: rpc.mountd startup succeeded Jul 28 20:30:45 fedora rpcidmapd: rpc.idmapd -SIGHUP succeeded Jul 28 20:30:50 fedora udev[2271]: creating device node '/dev/lp0' Jul 28 20:30:50 fedora kernel: audit(1091071850.411:0): avc: denied { search } for pid=2279 exe=/bin/bash name=lock dev=hda2 ino=4456478 scontext=system_u:system_r:udev_t tcontext=system_u:object_r:var_lock_t tclass=dir HANGS HERE.... ALT-CTL-DEL Jul 28 20:31:15 fedora shutdown: shutting down for system reboot Jul 28 20:31:15 fedora init: Switching to runlevel: 6 I thought that perhaps the udev message was indicating something, so I added allow udev_t var_lock_t:dir r_dir_perms; but this seems to be a red herring, all that did was to remove the avc..... still hangs. Any ideas? tom From dwalsh at redhat.com Thu Jul 29 15:15:09 2004 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 29 Jul 2004 11:15:09 -0400 Subject: latest dev pgks: strict/enforcing boot hangs.... In-Reply-To: <41090F7D.4050300@comcast.net> References: <41090F7D.4050300@comcast.net> Message-ID: <4109147D.8010807@redhat.com> Tom London wrote: > After installing the latest packages from the development tree, > (including selinux-policy-strict-1.15.8-3, etc.), booting with > strict/enforcing hangs (but it works with strict/permissive). Do you have any additional messages from strict/permissive? Dan > > [Same behavior with both 494 and 499 kernel. And I did > a 'fixfiles relabel' to no avail.] > > Here are the last entries from the log: > > Jul 28 20:30:45 fedora ntpd[2203]: kernel time sync status 0040 > Jul 28 20:30:45 fedora xinetd[2179]: xinetd Version 2.3.13 started > with libwrap loadavg options compiled in. > Jul 28 20:30:45 fedora xinetd[2179]: Started working: 1 available service > Jul 28 20:30:45 fedora ntpd[2203]: frequency initialized 70.900 PPM > from /var/lib/ntp/drift > Jul 28 20:30:45 fedora ntpd[2203]: configure: keyword "authenticate" > unknown, line ignored > Jul 28 20:30:45 fedora kernel: Installing knfsd (copyright (C) 1996 > okir at monad.swb.de). > Jul 28 20:30:45 fedora kernel: SELinux: initialized (dev nfsd, type > nfsd), uses genfs_contexts > Jul 28 20:30:45 fedora nfs: Starting NFS services: succeeded > Jul 28 20:30:45 fedora nfs: rpc.rquotad startup succeeded > Jul 28 20:30:45 fedora nfs: rpc.nfsd startup succeeded > Jul 28 20:30:45 fedora nfs: rpc.mountd startup succeeded > Jul 28 20:30:45 fedora rpcidmapd: rpc.idmapd -SIGHUP succeeded > Jul 28 20:30:50 fedora udev[2271]: creating device node '/dev/lp0' > Jul 28 20:30:50 fedora kernel: audit(1091071850.411:0): avc: denied > { search } for pid=2279 exe=/bin/bash name=lock dev=hda2 ino=4456478 > scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:var_lock_t tclass=dir > > HANGS HERE.... ALT-CTL-DEL > > Jul 28 20:31:15 fedora shutdown: shutting down for system reboot > Jul 28 20:31:15 fedora init: Switching to runlevel: 6 > > I thought that perhaps the udev message was indicating something, so I > added > allow udev_t var_lock_t:dir r_dir_perms; > but this seems to be a red herring, > all that did was to remove the avc..... still hangs. > > Any ideas? > tom > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list From selinux at comcast.net Thu Jul 29 15:37:57 2004 From: selinux at comcast.net (Tom London) Date: Thu, 29 Jul 2004 08:37:57 -0700 Subject: latest dev pgks: strict/enforcing boot hangs.... Message-ID: <410919D5.8060006@comcast.net> nope. Thats all I get. When I added an allow rule to search /var/lock, I got another one for 'getattr' (so I did the r_dir_perms). But thats all. Should I do an 'enableaudit'? tom > ------------------------------------------------------------------------ > > * /From/: Daniel J Walsh > > ------------------------------------------------------------------------ > Tom London wrote: > >After installing the latest packages from the development tree, >(including selinux-policy-strict-1.15.8-3, etc.), booting with >strict/enforcing hangs (but it works with strict/permissive). > > > > Do you have any additional messages from strict/permissive? > > Dan > >[Same behavior with both 494 and 499 kernel. And I did >a 'fixfiles relabel' to no avail.] > > > Here are the last entries from the log: > > Jul 28 20:30:45 fedora ntpd[2203]: kernel time sync status 0040 > Jul 28 20:30:45 fedora xinetd[2179]: xinetd Version 2.3.13 started > with libwrap loadavg options compiled in. > Jul 28 20:30:45 fedora xinetd[2179]: Started working: 1 available > service > Jul 28 20:30:45 fedora ntpd[2203]: frequency initialized 70.900 > PPM from /var/lib/ntp/drift > Jul 28 20:30:45 fedora ntpd[2203]: configure: keyword > "authenticate" unknown, line ignored > Jul 28 20:30:45 fedora kernel: Installing knfsd (copyright (C) > 1996 okir monad swb de). > Jul 28 20:30:45 fedora kernel: SELinux: initialized (dev nfsd, > type nfsd), uses genfs_contexts > Jul 28 20:30:45 fedora nfs: Starting NFS services: succeeded > Jul 28 20:30:45 fedora nfs: rpc.rquotad startup succeeded > Jul 28 20:30:45 fedora nfs: rpc.nfsd startup succeeded > Jul 28 20:30:45 fedora nfs: rpc.mountd startup succeeded > Jul 28 20:30:45 fedora rpcidmapd: rpc.idmapd -SIGHUP succeeded > Jul 28 20:30:50 fedora udev[2271]: creating device node '/dev/lp0' > Jul 28 20:30:50 fedora kernel: audit(1091071850.411:0): avc: > denied { search } for pid=2279 exe=/bin/bash name=lock dev=hda2 > ino=4456478 scontext=system_u:system_r:udev_t > tcontext=system_u:object_r:var_lock_t tclass=dir > > HANGS HERE.... ALT-CTL-DEL > >Jul 28 20:31:15 fedora shutdown: shutting down for system reboot >Jul 28 20:31:15 fedora init: Switching to runlevel: 6 > > >I thought that perhaps the udev message was indicating something, so I >added > allow udev_t var_lock_t:dir r_dir_perms; >but this seems to be a red herring, >all that did was to remove the avc..... still hangs. > > >Any ideas? > tom >-- >fedora-selinux-list mailing list >fedora-selinux-list redhat com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From sds at epoch.ncsc.mil Fri Jul 30 12:10:54 2004 From: sds at epoch.ncsc.mil (Stephen Smalley) Date: Fri, 30 Jul 2004 08:10:54 -0400 Subject: Caveat: Broken pam Message-ID: <1091189454.21245.22.camel@moss-spartans.epoch.ncsc.mil> Just as a warning, the pam package in rawhide is broken for SELinux; non-root logins will fail under console login, gdm, or ssh when in enforcing mode. I think that this is due to a bug in pam_unix related to execution of the chkpwd helper program. In permissive mode, pam_unix doesn't need to run the helper program, as it can directly read /etc/shadow itself. Fixed pam is available from Dan's site ftp://people.redhat.com/dwalsh/SELinux/Fedora. -- Stephen Smalley National Security Agency From selinux at comcast.net Fri Jul 30 16:36:59 2004 From: selinux at comcast.net (selinux at comcast.net) Date: Fri, 30 Jul 2004 16:36:59 +0000 Subject: Caveat: Broken pam, also latest dev pgks: strict/enforcing boot hangs.... Message-ID: <073020041636.17509.410A792B000DB053000044652200762194989A0207040A9C@comcast.net> Stephen, Thanks for this update. Installing the new pam also fixed my booting problem, where booting was hanging during/after starting cyrus. (Thanks also to Dan for working on this with me). tom --------------------------------------------------------------------------- * From: Stephen Smalley * Date: Fri, 30 Jul 2004 08:10:54 -0400 Just as a warning, the pam package in rawhide is broken for SELinux; non-root logins will fail under console login, gdm, or ssh when in enforcing mode. I think that this is due to a bug in pam_unix related to execution of the chkpwd helper program. In permissive mode, pam_unix doesn't need to run the helper program, as it can directly read /etc/shadow itself. Fixed pam is available from Dan's site ftp://people.redhat.com/dwalsh/SELinux/Fedora. -- Stephen Smalley National Security Agency From kwade at redhat.com Fri Jul 30 19:22:20 2004 From: kwade at redhat.com (Karsten Wade) Date: Fri, 30 Jul 2004 12:22:20 -0700 Subject: Can not access files in own home directory In-Reply-To: <40C865AE.7030908@redhat.com> References: <600B91D5E4B8D211A58C00902724252C01BC06AD@piramida.hermes.si> <40C865AE.7030908@redhat.com> Message-ID: <1091215339.11946.13230.camel@erato.phig.org> On Thu, 2004-06-10 at 06:44, Daniel J Walsh wrote: > After running fixfiles relabel you should always reboot in order to > start programs under the right context, If you do this in level 5 there > is a chance the applications will write files out with bad context after > the relabel, before the reboot. Is it sufficient to do this in run level 3? So far it's worked for me, but is it risky? - Karsten -- Karsten Wade, RHCE, Tech Writer this .signature subject to random changes http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From Valdis.Kletnieks at vt.edu Fri Jul 30 20:36:53 2004 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 30 Jul 2004 16:36:53 -0400 Subject: Can not access files in own home directory In-Reply-To: Your message of "Fri, 30 Jul 2004 12:22:20 PDT." <1091215339.11946.13230.camel@erato.phig.org> References: <600B91D5E4B8D211A58C00902724252C01BC06AD@piramida.hermes.si> <40C865AE.7030908@redhat.com> <1091215339.11946.13230.camel@erato.phig.org> Message-ID: <200407302036.i6UKarli023344@turing-police.cc.vt.edu> On Fri, 30 Jul 2004 12:22:20 PDT, Karsten Wade said: > On Thu, 2004-06-10 at 06:44, Daniel J Walsh wrote: > > > After running fixfiles relabel you should always reboot in order to > > start programs under the right context, If you do this in level 5 there > > is a chance the applications will write files out with bad context after > > the relabel, before the reboot. > > Is it sufficient to do this in run level 3? So far it's worked for me, > but is it risky? > The only real practical difference between 3 and 5 is that 5 launches gdm or other similar graphical GUI interface... so all the *other* daemons are still around and able to possibly blindside you. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From kwade at redhat.com Fri Jul 30 22:58:05 2004 From: kwade at redhat.com (Karsten Wade) Date: Fri, 30 Jul 2004 15:58:05 -0700 Subject: Turn on SELinux In-Reply-To: <40C21435.9080803@mcgill.ca> References: <20040605160027.A1B787590F@hormel.redhat.com> <40C21435.9080803@mcgill.ca> Message-ID: <1091228285.11946.13582.camel@erato.phig.org> On Sat, 2004-06-05 at 11:43, chris albert wrote: > On Sat, 2004-06-05 at 09:11, Khurt Williams wrote: > > >> I installed Fedora Core 2. I did not enable selinux at install. How > >> do I now enable it? > > > >>This may help > >>http://people.redhat.com/kwade/fedora-docs/selinux-faq-en/ > > But it doesn't. I filed a bugzilla request for having post-install-without-selinux selinux installation instructions added to the faq. > I used S.Smalley's remark at the end of > https://listman.redhat.com/archives/fedora-selinux-list/2004-May/msg00202.html These steps are now included in the FC2 version of the SELinux FAQ. Although that is the current FAQ I have posted, that is about to change since I am working on the FC3test1 FAQ. Here is the now and historical link for this question and answer: http://people.redhat.com/kwade/fedora-docs/fc2/selinux-faq-en/index.html#id2854406 - Karsten -- Karsten Wade, RHCE, Tech Writer this .signature subject to random changes http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 From iyigunler at itu.edu.tr Sat Jul 31 04:20:37 2004 From: iyigunler at itu.edu.tr (=?iso-8859-9?B?3XNtYWlsIN15aWf8bmxlcg==?=) Date: Sat, 31 Jul 2004 07:20:37 +0300 Subject: macro ? Message-ID: <460CD43658CA76469A49B3EA56279C2908C5CC@cmiex1.cmi.itu.edu.tr> hi what is macro conceptually ? i'm just a beginner in SELinux, just read your documents and testing in my system, and i'm having lots of denied messages from console usually, is it normal ? and what is the differences between default user_r and staff_r roles, can i group users by their authority by user_r and staff_r roles? , and can i assign "group"s to any roles? If not, how can i do it? thanks for your help :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at comcast.net Sat Jul 31 17:49:16 2004 From: selinux at comcast.net (Tom London) Date: Sat, 31 Jul 2004 10:49:16 -0700 Subject: Kernel install errors w/ strict/enforcing Message-ID: <410BDB9C.9090204@comcast.net> The following started about a week ago (running rawhide and off of Dan's tree: kernel-2.6.7-1.499, selinux-policy-strict-1.15.10-1, ...) 'yum install' for the kernel (.499 and .501) produces the following: failed to stat ./build/include/asm: 13 above message repeated 9 times. The install appears to be correct. Here are the avc's from the log: Jul 31 10:37:35 fedora kernel: audit(1091295455.845:0): avc: denied { getattr } for pid=4689 exe=/sbin/nash path=/lib/modules/2.6.7-1.501/build/include/asm dev=hda2 ino=3637290 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:modules_object_t tclass=lnk_file Jul 31 10:37:38 fedora kernel: audit(1091295458.230:0): avc: denied { getattr } for pid=4695 exe=/sbin/nash path=/lib/modules/2.6.7-1.501/build/include/asm dev=hda2 ino=3637290 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:modules_object_t tclass=lnk_file Jul 31 10:37:39 fedora kernel: audit(1091295459.276:0): avc: denied { getattr } for pid=4701 exe=/sbin/nash path=/lib/modules/2.6.7-1.501/build/include/asm dev=hda2 ino=3637290 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:modules_object_t tclass=lnk_file Jul 31 10:37:39 fedora kernel: audit(1091295459.468:0): avc: denied { transition } for pid=4703 exe=/bin/bash path=/sbin/dmsetup dev=hda2 ino=2310342 scontext=root:sysadm_r:bootloader_t tcontext=root:system_r:lvm_t tclass=process Jul 31 10:37:40 fedora kernel: audit(1091295460.731:0): avc: denied { getattr } for pid=4735 exe=/sbin/nash path=/lib/modules/2.6.7-1.501/build/include/asm dev=hda2 ino=3637290 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:modules_object_t tclass=lnk_file Jul 31 10:37:41 fedora kernel: audit(1091295461.268:0): avc: denied { getattr } for pid=4739 exe=/sbin/nash path=/lib/modules/2.6.7-1.501/build/include/asm dev=hda2 ino=3637290 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:modules_object_t tclass=lnk_file Jul 31 10:37:41 fedora kernel: audit(1091295461.764:0): avc: denied { getattr } for pid=4744 exe=/sbin/nash path=/lib/modules/2.6.7-1.501/build/include/asm dev=hda2 ino=3637290 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:modules_object_t tclass=lnk_file Jul 31 10:37:42 fedora kernel: audit(1091295462.569:0): avc: denied { getattr } for pid=4751 exe=/sbin/nash path=/lib/modules/2.6.7-1.501/build/include/asm dev=hda2 ino=3637290 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:modules_object_t tclass=lnk_file Jul 31 10:37:43 fedora kernel: audit(1091295463.091:0): avc: denied { getattr } for pid=4756 exe=/sbin/nash path=/lib/modules/2.6.7-1.501/build/include/asm dev=hda2 ino=3637290 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:modules_object_t tclass=lnk_file Jul 31 10:37:43 fedora kernel: audit(1091295463.633:0): avc: denied { getattr } for pid=4761 exe=/sbin/nash path=/lib/modules/2.6.7-1.501/build/include/asm dev=hda2 ino=3637290 scontext=root:sysadm_r:bootloader_t tcontext=system_u:object_r:modules_object_t tclass=lnk_file 'audit2allow' on the above yields: allow bootloader_t lvm_t:process { transition }; allow bootloader_t modules_object_t:lnk_file { getattr }; Do we need to make this (or some other) change? thanks tom From selinux at comcast.net Sat Jul 31 18:12:22 2004 From: selinux at comcast.net (Tom London) Date: Sat, 31 Jul 2004 11:12:22 -0700 Subject: install of dev-3.8.3-1.i386 fails w/ strict/enforcing Message-ID: <410BE106.408@comcast.net> Attempting to 'yum update' to dev-3.8.3-1.i386 from dev-3.8.2-1 produces: dev 100 % done 50/101 error: unpacking of archive failed: cpio: lstat and the update fails. No avc's in log. Rerunning 'yum update dev' in permissive mode succeeds. Avc's from permissive mode run: Jul 31 10:56:04 fedora kernel: audit(1091296564.101:0): avc: denied { getattr } for pid=9419 exe=/usr/bin/python path=/dev/dri dev=hda2 ino=2689470 scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t tclass=dir Jul 31 10:56:19 fedora kernel: audit(1091296579.901:0): avc: denied { search } for pid=9421 exe=/usr/sbin/groupadd name=selinux dev=hda2 ino=4509743 scontext=root:sysadm_r:groupadd_t tcontext=system_u:object_r:selinux_config_t tclass=dir Jul 31 10:56:19 fedora kernel: audit(1091296579.901:0): avc: denied { read } for pid=9421 exe=/usr/sbin/groupadd name=config dev=hda2 ino=4509759 scontext=root:sysadm_r:groupadd_t tcontext=system_u:object_r:selinux_config_t tclass=file Jul 31 10:56:19 fedora kernel: audit(1091296579.902:0): avc: denied { getattr } for pid=9421 exe=/usr/sbin/groupadd path=/etc/selinux/config dev=hda2 ino=4509759 scontext=root:sysadm_r:groupadd_t tcontext=system_u:object_r:selinux_config_t tclass=file Jul 31 10:56:20 fedora kernel: audit(1091296580.078:0): avc: denied { search } for pid=9422 exe=/usr/sbin/useradd name=run dev=hda2 ino=4456484 scontext=root:sysadm_r:useradd_t tcontext=system_u:object_r:var_run_t tclass=dir Jul 31 10:56:29 fedora kernel: audit(1091296589.978:0): avc: denied { relabelfrom } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 ino=2689470 scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t tclass=dir Jul 31 10:56:29 fedora kernel: audit(1091296589.979:0): avc: denied { relabelto } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 ino=2689470 scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t tclass=dir Jul 31 10:56:30 fedora kernel: audit(1091296590.011:0): avc: denied { setattr } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 ino=2689470 scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t tclass=dir Jul 31 10:56:30 fedora kernel: audit(1091296590.017:0): avc: denied { search } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 ino=2689470 scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t tclass=dir Jul 31 10:56:30 fedora kernel: audit(1091296590.083:0): avc: denied { write } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 ino=2689470 scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t tclass=dir Jul 31 10:56:30 fedora kernel: audit(1091296590.083:0): avc: denied { add_name } for pid=9419 exe=/usr/bin/python name=card0;410bdd3f scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t tclass=dir Jul 31 10:56:30 fedora kernel: audit(1091296590.136:0): avc: denied { remove_name } for pid=9419 exe=/usr/bin/python name=card0;410bdd3f dev=hda2 ino=2689465 scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t tclass=dir Jul 31 10:57:49 fedora kernel: audit(1091296669.135:0): avc: denied { search } for pid=9419 exe=/usr/bin/python name=dri dev=hda2 ino=2689470 scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t tclass=dir Jul 31 10:57:49 fedora kernel: audit(1091296669.136:0): avc: denied { getattr } for pid=9419 exe=/usr/bin/python path=/dev/dri dev=hda2 ino=2689470 scontext=root:sysadm_r:rpm_t tcontext=system_u:object_r:dri_device_t tclass=dir Audit2allow on the above produces: allow groupadd_t selinux_config_t:dir { search }; allow groupadd_t selinux_config_t:file { getattr read }; allow rpm_t dri_device_t:dir { add_name getattr relabelfrom relabelto remove_name search setattr write }; allow useradd_t var_run_t:dir { search }; Hope this helps, tom From selinux at comcast.net Sat Jul 31 20:48:42 2004 From: selinux at comcast.net (Tom London) Date: Sat, 31 Jul 2004 13:48:42 -0700 Subject: rhgb....still no graphical boot when strict/enforcing Message-ID: <410C05AA.9050009@comcast.net> I'm still getting only text-based boots when running with strict/enforcing, but graphical boots if I set 'enforcing=0' Here are entries from the log from a strict/enforcing boot: Jul 31 11:16:23 fedora kernel: SELinux: initialized (dev sockfs, type sockfs), uses task SIDs Jul 31 11:16:23 fedora kernel: SELinux: initialized (dev proc, type proc), uses genfs_contexts Jul 31 11:16:23 fedora kernel: SELinux: initialized (dev bdev, type bdev), uses genfs_contexts Jul 31 11:16:23 fedora kernel: SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts Jul 31 11:16:23 fedora kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts Jul 31 11:16:23 fedora kernel: audit(1091272545.625:0): avc: denied { mounton } for pid=533 exe=/usr/bin/rhgb path=/initrd dev=ram0 ino=2 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:file_t tclass=dir Jul 31 11:16:23 fedora kernel: audit(1091272545.625:0): avc: denied { sys_admin } for pid=533 exe=/usr/bin/rhgb capability=21 scontext=system_u:system_r:rhgb_t tcontext=system_u:system_r:rhgb_t tclass=capability Here are log entries from an 'enforcing=0' boot: Jul 29 20:40:38 fedora kernel: SELinux: initialized (dev sockfs, type sockfs), uses task SIDs Jul 29 20:40:38 fedora kernel: SELinux: initialized (dev proc, type proc), uses genfs_contexts Jul 29 20:40:38 fedora kernel: SELinux: initialized (dev bdev, type bdev), uses genfs_contexts Jul 29 20:40:38 fedora kernel: SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts Jul 29 20:40:38 fedora kernel: SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts Jul 29 20:40:38 fedora kernel: audit(1091133597.795:0): avc: denied { mounton } for pid=533 exe=/usr/bin/rhgb path=/initrd dev=ram0 ino=2 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:file_t tclass=dir Jul 29 20:40:38 fedora kernel: SELinux: initialized (dev ramfs, type ramfs), uses genfs_contexts Jul 29 20:40:38 fedora kernel: audit(1091133597.795:0): avc: denied { mount } for pid=533 exe=/usr/bin/rhgb name=/ dev=ramfs ino=1291 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:ramfs_t tclass=filesystem Jul 29 20:40:38 fedora kernel: audit(1091133598.713:0): avc: denied { search } for pid=534 exe=/usr/bin/rhgb name=run dev=hda2 ino=4456484 scontext=system_u:system_r:rhgb_t tcontext=system_u:object_r:var_run_t tclass=dir tom