From james.zheng.li at gmail.com Mon Aug 1 01:04:01 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Sun, 31 Jul 2005 21:04:01 -0400 Subject: SElinux policy for pine In-Reply-To: <8a239a560507281942ef33e59@mail.gmail.com> References: <8a239a560507281942ef33e59@mail.gmail.com> Message-ID: <8a239a56050731180430fd7b4b@mail.gmail.com> I was wonder whether strict policy could solve this problem? Thanks a lot. James On 7/28/05, James Z. Li wrote: > Hi all, > > First, sorry for my English. > I wrote a set of SELinux policy rules for pine ( pine-4.63-1.i386.rpm) > on FC4 (targeted). > It works well IF no email attachments involved. As root, you are able > to browse the > whole filesystem: get a file from anywhere as the attachment or save > the attachment > to anywhere you like. Does this make the security policy totally broken? > > At the same time, I was also evaluating LIDS (lids.org). As for pine > under LIDS, > it has same problem: it requires WRITE (including READ) permission to "/" > (inode number of "/"). For SELinux, since the policy is based on > domain/type, it is > even worse in the sense of policy writing: it requires one rw_dir_file > rule for each of > several hundreds of types on the whole filesystem, so several hundreds > of rules will > be added. > > I was thinking if there is a chroot mode for pine but I could not find > any useful info. > > Another potential way to solve this problem is that to create a > directory under user's > (root's) home direcroty, which is only used to store email > attachments: you need > copy files from everywhere else to this directory before you can upload them as > outgoing attachments; and all incoming attachments will be saved to > this directory > first, then you can copy or move them to somewhere else. By doing this, we can > write corresponding policy to label this directory and grant permissions. > > Any suggestions? > > James > > Enclosed pls find my pine.fc and pine.te files > > ################################ > #/etc/selinux/targeted/src/policy/file_contexts/program/pine.fc > # pine.fc > # Authors: james.zheng.li at gmail.com > ################################ > /usr/bin/mailutil -- system_u:object_r:pine_exec_t > /usr/bin/pico -- system_u:object_r:pine_exec_t > /usr/bin/pilot -- system_u:object_r:pine_exec_t > /usr/bin/pine -- system_u:object_r:pine_exec_t > /usr/bin/rpdump -- system_u:object_r:pine_exec_t > /usr/bin/rpload -- system_u:object_r:pine_exec_t > /usr/sbin/mlock -- system_u:object_r:pine_exec_t > > /etc/pine\.info -- system_u:object_r:pine_etc_t > /etc/pine\.conf -- system_u:object_r:pine_etc_t > /etc/pine\.conf\.fixed -- system_u:object_r:pine_etc_t > > HOME_DIR/mail(/.*)? system_u:object_r:pine_user_home_t > HOME_DIR/\.addressbook(\.lu)? -- system_u:object_r:pine_user_home_t > HOME_DIR/\.pine-debug[1-4] -- system_u:object_r:pine_user_home_t > HOME_DIR/\.pinerc -- system_u:object_r:pine_user_home_t > HOME_DIR/\.newsrc -- system_u:object_r:pine_user_home_t > HOME_DIR/\.signature -- system_u:object_r:pine_user_home_t > HOME_DIR/\.mailcap -- system_u:object_r:pine_user_home_t > HOME_DIR/\.mime\.types -- system_u:object_r:pine_user_home_t > HOME_DIR/\.pine-interrupted-mail -- > system_u:object_r:pine_user_home_t > HOME_DIR/dead\.letter -- system_u:object_r:pine_user_home_t > > ################################# > #/etc/selinux/targeted/src/policy/domains/program/pine.te > # pine.te > # Authors: james.zheng.li at gmail.com > ################################# > # > # Rules for the pine domain. > # > # pine_t is the domain for the pine program > # pine_exec_t is the type of the corresponding program. > # > type pine_t, domain,privmail,nscd_client_domain; > type pine_exec_t, file_type, sysadmfile, exec_type; > type pine_user_home_t, file_type, sysadmfile, customizable; > type pine_etc_t, file_type, sysadmfile; > > role sysadm_r types pine_t; > role system_r types pine_t; > #role user_r types pine_t; > > domain_auto_trans(sysadm_t, pine_exec_t, pine_t) > #domain_auto_trans(initrc_t, pine_exec_t, pine_t) > > file_type_auto_trans(pine_t,user_home_dir_t,pine_user_home_t,dir_file_class_set) > general_domain_access(pine_t) > tmp_domain(pine) > can_exec(pine_t, pine_exec_t) > > read_sysctl(pine_t) > uses_shlib(pine_t) > allow pine_t devpts_t:chr_file create_file_perms; > allow pine_t devpts_t:dir search; > allow pine_t etc_t:file { getattr read }; > allow pine_t etc_t:lnk_file read; > read_locale(pine_t) > allow pine_t mail_spool_t:dir rw_dir_perms; > allow pine_t mail_spool_t:file create_file_perms; > allow pine_t proc_t:dir search; > allow pine_t proc_t:lnk_file read; > allow pine_t urandom_device_t:chr_file getattr; > allow pine_t usr_t:file read; > allow pine_t var_spool_t:dir search; > allow pine_t fs_t:filesystem getattr; > allow pine_t net_conf_t:file r_file_perms; > allow pine_t sbin_t:dir search; > allow pine_t sbin_t:lnk_file read; > allow system_mail_t pine_tmp_t:file { read write }; > allow system_mail_t pine_user_home_t:file { read write }; > allow pine_t home_root_t:dir { getattr search }; > allow pine_t self:capability { fsetid fowner}; > From james.zheng.li at gmail.com Mon Aug 1 01:07:29 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Sun, 31 Jul 2005 21:07:29 -0400 Subject: SElinux policy for pine In-Reply-To: <8a239a560507281942ef33e59@mail.gmail.com> References: <8a239a560507281942ef33e59@mail.gmail.com> Message-ID: <8a239a5605073118073f6bb75e@mail.gmail.com> I was wondering whether strict policy could solve this problem? Thanks a lot. James On 7/28/05, James Z. Li wrote: > Hi all, > > First, sorry for my English. > I wrote a set of SELinux policy rules for pine ( pine-4.63-1.i386.rpm) > on FC4 (targeted). > It works well IF no email attachments involved. As root, you are able > to browse the > whole filesystem: get a file from anywhere as the attachment or save > the attachment > to anywhere you like. Does this make the security policy totally broken? > > At the same time, I was also evaluating LIDS (lids.org). As for pine > under LIDS, > it has same problem: it requires WRITE (including READ) permission to "/" > (inode number of "/"). For SELinux, since the policy is based on > domain/type, it is > even worse in the sense of policy writing: it requires one rw_dir_file > rule for each of > several hundreds of types on the whole filesystem, so several hundreds > of rules will > be added. > > I was thinking if there is a chroot mode for pine but I could not find > any useful info. > > Another potential way to solve this problem is that to create a > directory under user's > (root's) home direcroty, which is only used to store email > attachments: you need > copy files from everywhere else to this directory before you can upload them as > outgoing attachments; and all incoming attachments will be saved to > this directory > first, then you can copy or move them to somewhere else. By doing this, we can > write corresponding policy to label this directory and grant permissions. > > Any suggestions? > > James > > Enclosed pls find my pine.fc and pine.te files > > ################################ > #/etc/selinux/targeted/src/policy/file_contexts/program/pine.fc > # pine.fc > # Authors: james.zheng.li at gmail.com > ################################ > /usr/bin/mailutil -- system_u:object_r:pine_exec_t > /usr/bin/pico -- system_u:object_r:pine_exec_t > /usr/bin/pilot -- system_u:object_r:pine_exec_t > /usr/bin/pine -- system_u:object_r:pine_exec_t > /usr/bin/rpdump -- system_u:object_r:pine_exec_t > /usr/bin/rpload -- system_u:object_r:pine_exec_t > /usr/sbin/mlock -- system_u:object_r:pine_exec_t > > /etc/pine\.info -- system_u:object_r:pine_etc_t > /etc/pine\.conf -- system_u:object_r:pine_etc_t > /etc/pine\.conf\.fixed -- system_u:object_r:pine_etc_t > > HOME_DIR/mail(/.*)? system_u:object_r:pine_user_home_t > HOME_DIR/\.addressbook(\.lu)? -- system_u:object_r:pine_user_home_t > HOME_DIR/\.pine-debug[1-4] -- system_u:object_r:pine_user_home_t > HOME_DIR/\.pinerc -- system_u:object_r:pine_user_home_t > HOME_DIR/\.newsrc -- system_u:object_r:pine_user_home_t > HOME_DIR/\.signature -- system_u:object_r:pine_user_home_t > HOME_DIR/\.mailcap -- system_u:object_r:pine_user_home_t > HOME_DIR/\.mime\.types -- system_u:object_r:pine_user_home_t > HOME_DIR/\.pine-interrupted-mail -- > system_u:object_r:pine_user_home_t > HOME_DIR/dead\.letter -- system_u:object_r:pine_user_home_t > > ################################# > #/etc/selinux/targeted/src/policy/domains/program/pine.te > # pine.te > # Authors: james.zheng.li at gmail.com > ################################# > # > # Rules for the pine domain. > # > # pine_t is the domain for the pine program > # pine_exec_t is the type of the corresponding program. > # > type pine_t, domain,privmail,nscd_client_domain; > type pine_exec_t, file_type, sysadmfile, exec_type; > type pine_user_home_t, file_type, sysadmfile, customizable; > type pine_etc_t, file_type, sysadmfile; > > role sysadm_r types pine_t; > role system_r types pine_t; > #role user_r types pine_t; > > domain_auto_trans(sysadm_t, pine_exec_t, pine_t) > #domain_auto_trans(initrc_t, pine_exec_t, pine_t) > > file_type_auto_trans(pine_t,user_home_dir_t,pine_user_home_t,dir_file_class_set) > general_domain_access(pine_t) > tmp_domain(pine) > can_exec(pine_t, pine_exec_t) > > read_sysctl(pine_t) > uses_shlib(pine_t) > allow pine_t devpts_t:chr_file create_file_perms; > allow pine_t devpts_t:dir search; > allow pine_t etc_t:file { getattr read }; > allow pine_t etc_t:lnk_file read; > read_locale(pine_t) > allow pine_t mail_spool_t:dir rw_dir_perms; > allow pine_t mail_spool_t:file create_file_perms; > allow pine_t proc_t:dir search; > allow pine_t proc_t:lnk_file read; > allow pine_t urandom_device_t:chr_file getattr; > allow pine_t usr_t:file read; > allow pine_t var_spool_t:dir search; > allow pine_t fs_t:filesystem getattr; > allow pine_t net_conf_t:file r_file_perms; > allow pine_t sbin_t:dir search; > allow pine_t sbin_t:lnk_file read; > allow system_mail_t pine_tmp_t:file { read write }; > allow system_mail_t pine_user_home_t:file { read write }; > allow pine_t home_root_t:dir { getattr search }; > allow pine_t self:capability { fsetid fowner}; > From byronkeys at inxpress.net Mon Aug 1 02:54:44 2005 From: byronkeys at inxpress.net (Brian) Date: Sun, 31 Jul 2005 21:54:44 -0500 Subject: "Good" sound-editing app for Fedora? Message-ID: <42ED8EF4.40605@inxpress.net> Hello: After some initial guesswork (and deciding to go with a PCI form-factor once and for all), I now have a soundcard installed in a Fedora Core 3 machine. However, although it passes "the test" on the install, I cannot find a suitable app for manipulating imported files such as ".WAV", "*.MP3", etc. They all seem to indicate playback-in-progress with the Fedora "bundled" apps, but no sound. The "Audicity" app is impressive enough with a Mandrake distro, but attempts to find an .RPM or binary for it with Fedora have proven useless so far. Suggestions, amyone? :-) Brian Hagen From claude_jones at levitjames.com Mon Aug 1 03:56:03 2005 From: claude_jones at levitjames.com (Claude Jones) Date: Sun, 31 Jul 2005 23:56:03 -0400 Subject: "Good" sound-editing app for Fedora? In-Reply-To: <42ED8EF4.40605@inxpress.net> References: <42ED8EF4.40605@inxpress.net> Message-ID: <200507312356.03748.claude_jones@levitjames.com> On Sun July 31 2005 10:54 pm, Brian wrote: > Hello: > > After some initial guesswork (and deciding to go with a PCI > form-factor once and for all), I now have a soundcard > installed in a Fedora Core 3 machine. However, although it passes "the > test" on the install, I cannot find a suitable app for manipulating > imported files such as ".WAV", "*.MP3", etc. They all seem to indicate > playback-in-progress with the Fedora "bundled" apps, but no sound. > > The "Audicity" app is impressive enough with a Mandrake distro, but > attempts to find an .RPM or binary for it with Fedora have proven > useless so far. Suggestions, amyone? :-) > I'm not sure why you're asking this question on the Selinux list, but, Audacity is in Fedora Extras - enable your extras repo and $ yum install audacity should do it -- Claude Jones Bluemont, VA, USA From bobk at ocf.berkeley.edu Mon Aug 1 05:21:23 2005 From: bobk at ocf.berkeley.edu (Bobby Kashani) Date: Sun, 31 Jul 2005 22:21:23 -0700 Subject: update from fc3 -> fc4: cyrus/sasl-errors In-Reply-To: <42ECD098.7020406@gwch.net> References: <42ECD098.7020406@gwch.net> Message-ID: <1122873683.2613.1.camel@chaucer> On Sun, 2005-07-31 at 15:22 +0200, Roger Grosswiler wrote: > hi, > > i recently updated from fc3 to fc4. i use this machine as a mailserver > with cyrus. 1st problem was the database - fixed issue. now, on > authentication, i get errors, will say, with selinux enforcing i cannot > authenticate at all. > > from the fc-list i got some help, with a few commands, that should help > better understanding. What can i do, to have this box with selinux > enforcing enabled? ah, yes, in permissive mode it works fine. Have you tried doing a "touch /.autorelabel" and rebooting? Bob > here a sniplet of my logs: > > [root at link ~]# ausearch -i -a 9657218 > > ---- > > type=PATH msg=audit(07/30/05 16:21:20.281:9657218) : item=0 flags=follow inode=262199 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 > > type=SOCKETCALL msg=audit(07/30/05 16:21:20.281:9657218) : nargs=3 a0=b a1=bfd308fa a2=6e > > type=SOCKADDR msg=audit(07/30/05 16:21:20.281:9657218) : saddr=local /var/run/saslauthd/mux > > type=SYSCALL msg=audit(07/30/05 16:21:20.281:9657218) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=bfd2e4b0 a2=dd0228 a3=bfd2e513 items=1 pid=28898 auid=root uid=cyrus gid=mail euid=cyrus suid=cyrus fsuid=cyrus egid=mail sgid=mail fsgid=mail comm=imapd exe=/usr/lib/cyrus-imapd/imapd > > type=AVC msg=audit(07/30/05 16:21:20.281:9657218) : avc: denied { search } for pid=28898 comm=imapd name=saslauthd dev=dm-0 ino=262199 scontext=root:system_r:cyrus_t tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir > > > >> ausearch -i -a 9659874 > >> > >> > > [root at link ~]# ausearch -i -a 9659874 > > ---- > > type=PATH msg=audit(07/30/05 16:21:24.635:9659874) : item=0 flags=follow inode=262199 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 > > type=SOCKETCALL msg=audit(07/30/05 16:21:24.635:9659874) : nargs=3 a0=b a1=bfd308fa a2=6e > > type=SOCKADDR msg=audit(07/30/05 16:21:24.635:9659874) : saddr=local /var/run/saslauthd/mux > > type=SYSCALL msg=audit(07/30/05 16:21:24.635:9659874) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=bfd2e4b0 a2=dd0228 a3=bfd2e513 items=1 pid=28898 auid=root uid=cyrus gid=mail euid=cyrus suid=cyrus fsuid=cyrus egid=mail sgid=mail fsgid=mail comm=imapd exe=/usr/lib/cyrus-imapd/imapd > > type=AVC msg=audit(07/30/05 16:21:24.635:9659874) : avc: denied { search } for pid=28898 comm=imapd name=saslauthd dev=dm-0 ino=262199 scontext=root:system_r:cyrus_t tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir > > > i hope, you can help. > > Thanks a lot > Roger > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Bobby Kashani http://www.ocf.berkeley.edu/~bobk/garnome From hhoffman at ip-solutions.net Mon Aug 1 05:44:05 2005 From: hhoffman at ip-solutions.net (Harry Hoffman) Date: Mon, 1 Aug 2005 01:44:05 -0400 (EDT) Subject: update from fc3 -> fc4: cyrus/sasl-errors In-Reply-To: <1122873683.2613.1.camel@chaucer> References: <42ECD098.7020406@gwch.net> <1122873683.2613.1.camel@chaucer> Message-ID: <20050801014302.K17051@surf.gcrc.upenn.edu> It's a problem with the policy not with a relabel. audit2allow will give you a policy statement to work with... HTH, Harry On Sun, 31 Jul 2005, Bobby Kashani wrote: > On Sun, 2005-07-31 at 15:22 +0200, Roger Grosswiler wrote: > > hi, > > > > i recently updated from fc3 to fc4. i use this machine as a mailserver > > with cyrus. 1st problem was the database - fixed issue. now, on > > authentication, i get errors, will say, with selinux enforcing i cannot > > authenticate at all. > > > > from the fc-list i got some help, with a few commands, that should help > > better understanding. What can i do, to have this box with selinux > > enforcing enabled? ah, yes, in permissive mode it works fine. > > Have you tried doing a "touch /.autorelabel" and rebooting? > > Bob > > > here a sniplet of my logs: > > > [root at link ~]# ausearch -i -a 9657218 > > > ---- > > > type=PATH msg=audit(07/30/05 16:21:20.281:9657218) : item=0 flags=follow inode=262199 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 > > > type=SOCKETCALL msg=audit(07/30/05 16:21:20.281:9657218) : nargs=3 a0=b a1=bfd308fa a2=6e > > > type=SOCKADDR msg=audit(07/30/05 16:21:20.281:9657218) : saddr=local /var/run/saslauthd/mux > > > type=SYSCALL msg=audit(07/30/05 16:21:20.281:9657218) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=bfd2e4b0 a2=dd0228 a3=bfd2e513 items=1 pid=28898 auid=root uid=cyrus gid=mail euid=cyrus suid=cyrus fsuid=cyrus egid=mail sgid=mail fsgid=mail comm=imapd exe=/usr/lib/cyrus-imapd/imapd > > > type=AVC msg=audit(07/30/05 16:21:20.281:9657218) : avc: denied { search } for pid=28898 comm=imapd name=saslauthd dev=dm-0 ino=262199 scontext=root:system_r:cyrus_t tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir > > > > > >> ausearch -i -a 9659874 > > >> > > >> > > > [root at link ~]# ausearch -i -a 9659874 > > > ---- > > > type=PATH msg=audit(07/30/05 16:21:24.635:9659874) : item=0 flags=follow inode=262199 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 > > > type=SOCKETCALL msg=audit(07/30/05 16:21:24.635:9659874) : nargs=3 a0=b a1=bfd308fa a2=6e > > > type=SOCKADDR msg=audit(07/30/05 16:21:24.635:9659874) : saddr=local /var/run/saslauthd/mux > > > type=SYSCALL msg=audit(07/30/05 16:21:24.635:9659874) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=bfd2e4b0 a2=dd0228 a3=bfd2e513 items=1 pid=28898 auid=root uid=cyrus gid=mail euid=cyrus suid=cyrus fsuid=cyrus egid=mail sgid=mail fsgid=mail comm=imapd exe=/usr/lib/cyrus-imapd/imapd > > > type=AVC msg=audit(07/30/05 16:21:24.635:9659874) : avc: denied { search } for pid=28898 comm=imapd name=saslauthd dev=dm-0 ino=262199 scontext=root:system_r:cyrus_t tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir > > > > > > i hope, you can help. > > > > Thanks a lot > > Roger > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- > Bobby Kashani > http://www.ocf.berkeley.edu/~bobk/garnome > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > From jorton at redhat.com Mon Aug 1 08:33:23 2005 From: jorton at redhat.com (Joe Orton) Date: Mon, 1 Aug 2005 09:33:23 +0100 Subject: FC4 httpd_can_network_connect boolean Message-ID: <20050801083323.GA10110@redhat.com> Very useful that this has been introduced - but I had presumed that it applies only to non-local addresses. The httpd parent process needs to be able to make connections to the local address/ports to which the children are bound. After a period of load, when there are idle children stuck in accept(), the parent will make a few connect()s to wake them up. Can this policy be limited to non-local addresses? (the "child garbage collection" process is effectively broken-by-default at the moment) joe From roger at gwch.net Mon Aug 1 09:53:42 2005 From: roger at gwch.net (Roger Grosswiler) Date: Mon, 01 Aug 2005 11:53:42 +0200 Subject: update from fc3 -> fc4: cyrus/sasl-errors In-Reply-To: <20050801014302.K17051@surf.gcrc.upenn.edu> References: <42ECD098.7020406@gwch.net> <1122873683.2613.1.camel@chaucer> <20050801014302.K17051@surf.gcrc.upenn.edu> Message-ID: <42EDF126.5030000@gwch.net> Harry Hoffman wrote: > It's a problem with the policy not with a relabel. > > audit2allow > > will give you a policy statement to work with... > > > HTH, > Harry > > > > On Sun, 31 Jul 2005, Bobby Kashani wrote: > > >>On Sun, 2005-07-31 at 15:22 +0200, Roger Grosswiler wrote: >> >>>hi, >>> >>>i recently updated from fc3 to fc4. i use this machine as a mailserver >>>with cyrus. 1st problem was the database - fixed issue. now, on >>>authentication, i get errors, will say, with selinux enforcing i cannot >>>authenticate at all. >>> >>>from the fc-list i got some help, with a few commands, that should help >>>better understanding. What can i do, to have this box with selinux >>>enforcing enabled? ah, yes, in permissive mode it works fine. >> >>Have you tried doing a "touch /.autorelabel" and rebooting? >> >>Bob >> >> >>>here a sniplet of my logs: >>> >>>>[root at link ~]# ausearch -i -a 9657218 >>>>---- >>>>type=PATH msg=audit(07/30/05 16:21:20.281:9657218) : item=0 flags=follow inode=262199 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 >>>>type=SOCKETCALL msg=audit(07/30/05 16:21:20.281:9657218) : nargs=3 a0=b a1=bfd308fa a2=6e >>>>type=SOCKADDR msg=audit(07/30/05 16:21:20.281:9657218) : saddr=local /var/run/saslauthd/mux >>>>type=SYSCALL msg=audit(07/30/05 16:21:20.281:9657218) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=bfd2e4b0 a2=dd0228 a3=bfd2e513 items=1 pid=28898 auid=root uid=cyrus gid=mail euid=cyrus suid=cyrus fsuid=cyrus egid=mail sgid=mail fsgid=mail comm=imapd exe=/usr/lib/cyrus-imapd/imapd >>>>type=AVC msg=audit(07/30/05 16:21:20.281:9657218) : avc: denied { search } for pid=28898 comm=imapd name=saslauthd dev=dm-0 ino=262199 scontext=root:system_r:cyrus_t tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir >>>> >>>> >>>>>ausearch -i -a 9659874 >>>>> >>>>> >>>> >>>>[root at link ~]# ausearch -i -a 9659874 >>>>---- >>>>type=PATH msg=audit(07/30/05 16:21:24.635:9659874) : item=0 flags=follow inode=262199 dev=fd:00 mode=dir,755 ouid=root ogid=root rdev=00:00 >>>>type=SOCKETCALL msg=audit(07/30/05 16:21:24.635:9659874) : nargs=3 a0=b a1=bfd308fa a2=6e >>>>type=SOCKADDR msg=audit(07/30/05 16:21:24.635:9659874) : saddr=local /var/run/saslauthd/mux >>>>type=SYSCALL msg=audit(07/30/05 16:21:24.635:9659874) : arch=i386 syscall=socketcall(connect) success=no exit=-13(Permission denied) a0=3 a1=bfd2e4b0 a2=dd0228 a3=bfd2e513 items=1 pid=28898 auid=root uid=cyrus gid=mail euid=cyrus suid=cyrus fsuid=cyrus egid=mail sgid=mail fsgid=mail comm=imapd exe=/usr/lib/cyrus-imapd/imapd >>>>type=AVC msg=audit(07/30/05 16:21:24.635:9659874) : avc: denied { search } for pid=28898 comm=imapd name=saslauthd dev=dm-0 ino=262199 scontext=root:system_r:cyrus_t tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir >>> >>> >>>i hope, you can help. >>> >>>Thanks a lot >>>Roger >>> >>> >>>-- >>>fedora-selinux-list mailing list >>>fedora-selinux-list at redhat.com >>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >>-- >>Bobby Kashani >>http://www.ocf.berkeley.edu/~bobk/garnome >> >>-- >>fedora-selinux-list mailing list >>fedora-selinux-list at redhat.com >>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list ok, in /var/log/audit, i did audit2allow -i audit.log and got: [root at link audit]# audit2allow -i audit.log allow apmd_t named_conf_t:dir { getattr search }; allow apmd_t named_zone_t:dir { getattr search }; allow apmd_t user_home_dir_t:dir getattr; allow apmd_t var_lib_t:dir getattr; allow cyrus_t initrc_t:unix_stream_socket connectto; allow cyrus_t saslauthd_var_run_t:dir search; allow cyrus_t saslauthd_var_run_t:sock_file write; allow ftpd_t selinux_config_t:file { getattr read }; allow mysqld_t initrc_t:fd use; allow mysqld_t initrc_t:process sigchld; allow saslauthd_t initrc_t:unix_stream_socket connectto; allow saslauthd_t mysqld_db_t:dir search; allow saslauthd_t mysqld_db_t:sock_file write; allow saslauthd_t selinux_config_t:dir search; allow saslauthd_t selinux_config_t:file { getattr read }; allow saslauthd_t var_lib_t:dir search; what am i gonna do with this? just fixfiles relabel? or do i have to insert them somehow? sorry for keeping you busy... Roger From russell at coker.com.au Mon Aug 1 13:47:57 2005 From: russell at coker.com.au (Russell Coker) Date: Mon, 1 Aug 2005 23:47:57 +1000 Subject: FC4 httpd_can_network_connect boolean In-Reply-To: <20050801083323.GA10110@redhat.com> References: <20050801083323.GA10110@redhat.com> Message-ID: <200508012348.02441.russell@coker.com.au> On Monday 01 August 2005 18:33, Joe Orton wrote: > Very useful that this has been introduced - but I had presumed that it > applies only to non-local addresses. > > The httpd parent process needs to be able to make connections to the > local address/ports to which the children are bound. After a period of > load, when there are idle children stuck in accept(), the parent will > make a few connect()s to wake them up. > > Can this policy be limited to non-local addresses? James, can we limit it to local addresses? Steve, should we consider changing policy more widely to allow programs to connect to their own ports? -- 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 walters at redhat.com Mon Aug 1 16:20:07 2005 From: walters at redhat.com (Colin Walters) Date: Mon, 01 Aug 2005 12:20:07 -0400 Subject: Selinux Apache avc denied In-Reply-To: <200507300356.j6U3uemr010001@turing-police.cc.vt.edu> References: <1122694321.3536.11.camel@humus.cfg.sld.cu> <200507300356.j6U3uemr010001@turing-police.cc.vt.edu> Message-ID: <1122913208.15243.104.camel@nexus.verbum.private> On Fri, 2005-07-29 at 23:56 -0400, Valdis.Kletnieks at vt.edu wrote: > On Fri, 29 Jul 2005 23:32:01 EDT, Alain Reguera Delgado said: > > > I've been stopped the web development. I feel selinux is a brilliant > > technology I'd like to implement in my webserver. > > Actually, you have that almost totally backwards - SELinux is a brilliant > technology that gets implemented in the kernel One of the good things about SELinux actually is that it covers more than the kernel; e.g. dbus acts as a "userspace object manager" in concert with the kernel to secure the whole system. Similarly, there are patches for Xorg. I think it does make sense in some situations to patch the webserver. > Unfortunately, this is *much* too big a can of worms to solve directly - it > would be technically possible to just add a rule that says 'httpd_t can > exec shell_exec_t' - but that would be a *really* *bad* idea because then > any exploit could get a shell (and exec_no_trans only partially minimizes > the problem). I don't see a problem with execute_no_trans; it stays within the httpd_t security domain. > Policy Gurus: How big a hole would adding a 'can_exec(sendmail_exec_t)' or > 'domain_auto_trans(sendmail_t)' cause? And how many of these common "web interface > wants to send mail" problems would it solve? I think policy already has this as httpd_t has the privmail attribute, and policy grants: ./macros/program/mta_macros.te:63:domain_auto_trans(privmail, sendmail_exec_t, system_mail_t) My guess is all we need for this problem is: can_exec(httpd_t, shell_exec_t) From dwalsh at redhat.com Mon Aug 1 16:39:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 01 Aug 2005 12:39:31 -0400 Subject: Selinux Apache avc denied In-Reply-To: <1122913208.15243.104.camel@nexus.verbum.private> References: <1122694321.3536.11.camel@humus.cfg.sld.cu> <200507300356.j6U3uemr010001@turing-police.cc.vt.edu> <1122913208.15243.104.camel@nexus.verbum.private> Message-ID: <42EE5043.3040302@redhat.com> Colin Walters wrote: >On Fri, 2005-07-29 at 23:56 -0400, Valdis.Kletnieks at vt.edu wrote: > > >>On Fri, 29 Jul 2005 23:32:01 EDT, Alain Reguera Delgado said: >> >> >> >>>I've been stopped the web development. I feel selinux is a brilliant >>>technology I'd like to implement in my webserver. >>> >>> >>Actually, you have that almost totally backwards - SELinux is a brilliant >>technology that gets implemented in the kernel >> >> > >One of the good things about SELinux actually is that it covers more >than the kernel; e.g. dbus acts as a "userspace object manager" in >concert with the kernel to secure the whole system. Similarly, there >are patches for Xorg. I think it does make sense in some situations to >patch the webserver. > > > >>Unfortunately, this is *much* too big a can of worms to solve directly - it >>would be technically possible to just add a rule that says 'httpd_t can >>exec shell_exec_t' - but that would be a *really* *bad* idea because then >>any exploit could get a shell (and exec_no_trans only partially minimizes >>the problem). >> >> > >I don't see a problem with execute_no_trans; it stays within the httpd_t >security domain. > > > >>Policy Gurus: How big a hole would adding a 'can_exec(sendmail_exec_t)' or >>'domain_auto_trans(sendmail_t)' cause? And how many of these common "web interface >>wants to send mail" problems would it solve? >> >> > >I think policy already has this as httpd_t has the privmail attribute, >and policy grants: > >./macros/program/mta_macros.te:63:domain_auto_trans(privmail, sendmail_exec_t, system_mail_t) > >My guess is all we need for this problem is: >can_exec(httpd_t, shell_exec_t) > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > What is the settings of httpd_ssi_exec boolean? getsebool httpd_ssi_exec Looks like you need this on to make your sendmail work. setsebool -P httpd_ssi_exec=1 -- From latten at austin.ibm.com Tue Aug 2 18:57:15 2005 From: latten at austin.ibm.com (Joy Latten) Date: Tue, 2 Aug 2005 13:57:15 -0500 Subject: MLS in Fedora Core 4 Message-ID: <200508021857.j72IvF0O018858@faith.austin.ibm.com> I have recently enabled MLS after installing Fedora Core 4 on my system. Would this be the appropriate mailing list to collaborate or ask questions about MLS in Fedora Core 4? Regards, Joy Latten From jmorris at redhat.com Tue Aug 2 19:38:39 2005 From: jmorris at redhat.com (James Morris) Date: Tue, 2 Aug 2005 15:38:39 -0400 (EDT) Subject: MLS in Fedora Core 4 In-Reply-To: <200508021857.j72IvF0O018858@faith.austin.ibm.com> References: <200508021857.j72IvF0O018858@faith.austin.ibm.com> Message-ID: On Tue, 2 Aug 2005, Joy Latten wrote: > I have recently enabled MLS after installing Fedora Core 4 on my system. > Would this be the appropriate mailing list to collaborate or > ask questions about MLS in Fedora Core 4? I don't see why not. - James -- James Morris From paul.moore at hp.com Tue Aug 2 19:54:50 2005 From: paul.moore at hp.com (Paul Moore) Date: Tue, 02 Aug 2005 15:54:50 -0400 Subject: MLS levels and the initial SID for kernel_t Message-ID: <42EFCF8A.60204@hp.com> Dan's latest MLS policy RPM (as well as some past versions) has a patch in it, mlspol.patch, which contains the following change for initial_sid_contexts: -sid kernel system_u:system_r:kernel_t:s0 - s9:c0.c127 +sid kernel system_u:system_r:kernel_t:s9:c0.c127 From what I can tell this causes some problems, the biggest of which being that init starts at s9 which can cause the system to die on boot when trying to fsck the filesystems. I'm not entirely sure why this change was made as I would think we would want the kernel to run at s0-s9 or at the very least s0. Can someone clue me in as to why we want to run the kernel at s9 or, Dan, can you change it back to s0 - s9? Thanks, -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From russell at coker.com.au Wed Aug 3 06:04:48 2005 From: russell at coker.com.au (Russell Coker) Date: Wed, 3 Aug 2005 16:04:48 +1000 Subject: minor patch to apache policy Message-ID: <200508031604.52342.russell@coker.com.au> The attached patch is needed to close bugzilla entries #150292 and #164866. -- 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: 627 bytes Desc: not available URL: From roger at gwch.net Wed Aug 3 06:26:43 2005 From: roger at gwch.net (Roger Grosswiler) Date: Wed, 3 Aug 2005 08:26:43 +0200 (CEST) Subject: update from fc3 -> fc4: cyrus/sasl-errors In-Reply-To: <42EDF126.5030000@gwch.net> References: <42ECD098.7020406@gwch.net> <1122873683.2613.1.camel@chaucer> <20050801014302.K17051@surf.gcrc.upenn.edu> <42EDF126.5030000@gwch.net> Message-ID: <14319.62.2.21.164.1123050403.squirrel@www.gwch.net> Hey, I have seen, that in updates-testing exists a new policy, according my problem. So, i updated as an exception from updates-testing. But: still no success. But, at least, the list from allow2audit (just from the last policy reload now is smaller: [root at link audit]# audit2allow -i audit.log -l allow saslauthd_t var_lib_t:dir search; is this not already better news? Thanks for the update, Dank ;-) Roger From daniela.gradim at fortevisiomedica.com Wed Aug 3 08:29:09 2005 From: daniela.gradim at fortevisiomedica.com (Daniela Gradim) Date: Wed, 03 Aug 2005 10:29:09 +0200 Subject: BackupPC and Selinux Message-ID: <1123057749.5701.2.camel@localhost.localdomain> Hi !!! I reinstall my BackupPC server but now I have one problem when I try to connect that server Error: Unable to connect to BackupPC server. I have installed FC4 and selinux-policy-targeted-1.25.3-6. When I check my audit log I have many kinds of AVC. What shall I do to make this working. type=AVC_PATH msg=audit(1123052401.490:14046033): path="/dev/console" type=CWD msg=audit(1123052401.490:14046033): cwd="/home/users/backuppc" type=PATH msg=audit(1123052401.490:14046033): item=0 name="/bin/ping" flags=101 inode=59080709 dev=09:01 mode=0104755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1123052401.490:14046033): item=1 flags=101 inode=23531242 dev=09:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1123052403.947:14059893): avc: denied { use } for pid=17525 comm="ping" name="console" dev=tmpfs ino=2614 scontext=system_u:system_r:ping_t tcontext=system_u:system_r:init_t tclass=fd type=AVC msg=audit(1123055904.817:14334333): avc: denied { ioctl } for pid=20401 comm="httpd" name="Lib.pm" dev=md1 ino=70811835 scontext=system_u:system_r:httpd_t tcontext=root:object_r:httpd_sys_script_exec_t tclass=file type=SYSCALL msg=audit(1123055904.817:14334333): arch=40000003 syscall=54 success=no exit=-13 a0=1 a1=5401 a2=bfd1bbc8 a3=bfd1bc08 items=0 pid=20401 auid=4294967295 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" type=AVC_PATH msg=audit(1123055904.817:14334333): path="/home/httpd/html/BackupPC/lib/BackupPC/Lib.pm" type=AVC msg=audit(1123055904.899:14334889): avc: denied { ioctl } for pid=2\0401 comm="httpd" name="Lib.pm" dev=md1 ino=70811823 scontext=system_u:system_r\:httpd_t tcontext=root:object_r:httpd_sys_script_exec_t tclass=file type=SYSCALL msg=audit(1123055904.899:14334889): arch=40000003 syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1bbc8 a3=bfd1bc08 items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" type=AVC_PATH msg=audit(1123055904.899:14334889): path="/home/httpd/html/Backu\pPC/lib/BackupPC/CGI/Lib.pm" type=AVC msg=audit(1123055904.961:14334904): avc: denied { ioctl } for pid=2\0401 comm="httpd" name="config.pl" dev=md1 ino=70812030 scontext=system_u:syste\m_r:httpd_t tcontext=root:object_r:httpd_sys_script_exec_t tclass=file type=SYSCALL msg=audit(1123055904.961:14334904): arch=40000003 syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c0f8 a3=bfd1c138 items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" type=AVC_PATH msg=audit(1123055904.961:14334904): path="/home/httpd/html/Backu\pPC/data/conf/config.pl" type=AVC msg=audit(1123055904.968:14334926): avc: denied { ioctl } for pid=2\0401 comm="httpd" name="en.pm" dev=md1 ino=70811804 scontext=system_u:system_r:\httpd_t tcontext=root:object_r:httpd_sys_script_exec_t tclass=file type=SYSCALL msg=audit(1123055904.968:14334926): arch=40000003 syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c0f8 a3=bfd1c138 items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" type=AVC_PATH msg=audit(1123055904.968:14334926): path="/home/httpd/html/Backu\pPC/lib/BackupPC/Lang/en.pm" type=AVC msg=audit(1123055904.980:14334955): avc: denied { ioctl } for pid=2\0401 comm="httpd" name="hosts" dev=md1 ino=70812028 scontext=system_u:system_r:\httpd_t tcontext=root:object_r:httpd_sys_script_exec_t tclass=file type=SYSCALL msg=audit(1123055904.980:14334955): arch=40000003 syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c148 a3=bfd1c188 items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" type=AVC_PATH msg=audit(1123055904.980:14334955): path="/home/httpd/html/Backu\pPC/data/conf/hosts" type=AVC msg=audit(1123055904.982:14334964): avc: denied { ioctl } for pid=20401 comm="httpd" name="GeneralInfo.pm" dev=md1 ino=70811807 scontext=system_u:\system_r:httpd_t tcontext=root:object_r:httpd_sys_script_exec_t tclass=file type=SYSCALL msg=audit(1123055904.982:14334964): arch=40000003 syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c0f8 a3=bfd1c138 items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" type=AVC_PATH msg=audit(1123055904.982:14334964): path="/home/httpd/html/Backu\pPC/lib/BackupPC/type=AVC msg=audit (1123057381.490:15261737): avc: denied { lock } for pid=20\404 comm="httpd" name="LOCK" dev=md1 ino=70811933 scontext=system_u:system_r:ht\tpd_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=file type=SYSCALL msg=audit(1123057381.490:15261737): arch=40000003 syscall=143 succ\ess=no exit=-13 a0=0 a1=2 a2=10ebbc0 a3=9ad4700 items=0 pid=20404 auid=42949672\95 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm="ht\tpd" exe="/usr/sbin/httpd" type=AVC_PATH msg=audit(1123057381.490:15261737): path="/home/httpd/html/Backu\pPC/data/pc/7r04b0j/LOCK" type=AVC msg=audit(1123057387.694:15262203): avc: denied { write } for pid=2\0404 comm="httpd" name="BackupPC.sock" dev=md1 ino=70811920 scontext=system_u:s\ystem_r:httpd_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=sock_\file type=SYSCALL msg=audit(1123057387.694:15262203): arch=40000003 syscall=102 succ\ess=no exit=-13 a0=3 a1=bfd1c490 a2=10ebbc0 a3=6e items=1 pid=20404 auid=429496\7295 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm="\httpd" exe="/usr/sbin/httpd" type=SOCKADDR msg=audit(1123057387.694:15262203): saddr=01002F686F6D652F6874747 \0642F68746D6C2F4261636B757050432F646174612F6C6F672F4261636B757050432E736F636B00\0000000000000000000000000000000000000000000000000000000000000000000000000000000\000000000000000000000000000000000000000 type=SOCKETCALL msg=audit(1123057387.694:15262203): nargs=3 a0=1 a1=9e9c5c8 a2=\6e type=PATH msg=audit(1123057387.694:15262203): item=0 flags=1 inode=70811920 de\v=09:01 mode=0140750 ouid=501 ogid=3 rdev=00:00 CGI/GeneralInfo.pm" type=AVC msg=audit(1123055904.988:14334976): avc: denied { write } for pid=2\0401 comm="httpd" name="BackupPC.sock" dev=md1 ino=70811920 scontext=system_u:s\ystem_r:httpd_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=sock_\file type=SYSCALL msg=audit(1123055904.988:14334976): arch=40000003 syscall=102 succ\ess=no exit=-13 a0=3 a1=bfd1c490 a2=10ebbc0 a3=6e items=1 pid=20401 auid=429496\7295 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm="\httpd" exe="/usr/sbin/httpd" type=SOCKADDR msg=audit(1123055904.988:14334976): saddr=01002F686F6D652F6874747 \0642F68746D6C2F4261636B757050432F646174612F6C6F672F4261636B757050432E736F636B00\0000000000000000000000000000000000000000000000000000000000000000000000000000000\000000000000000000000000000000000000000 type=SOCKETCALL msg=audit(1123055904.988:14334976): nargs=3 a0=1 a1=9e67f28 a2=\6e type=PATH msg=audit(1123055904.988:14334976): item=0 flags=1 inode=70811920 de\v=09:01 mode=0140750 ouid=501 ogid=3 rdev=00:00 type=AVC msg=audit(1123055907.166:14335286): avc: denied { write } for pid=2\0401 comm="httpd" name="BackupPC.sock" dev=md1 ino=70811920 scontext=system_u:s\ystem_r:httpd_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=sock_\file type=SYSCALL msg=audit(1123055907.166:14335286): arch=40000003 syscall=102 succ\ess=no exit=-13 a0=3 a1=bfd1c490 a2=10ebbc0 a3=6e items=1 pid=20401 auid=429496\7295 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm="\httpd" exe="/usr/sbin/httpd" type=SOCKADDR msg=audit(1123055907.166:14335286): saddr=01002F686F6D652F6874747 \0642F68746D6C2F4261636B757050432F646174612F6C6F672F4261636B757050432E736F636B00\0000000000000000000000000000000000000000000000000000000000000000000000000000000\000000000000000000000000000000000000000 type=SOCKETCALL msg=audit(1123055907.166:14335286): nargs=3 a0=d a1=9e7ea88 a2=\6e type=PATH msg=audit(1123055907.166:14335286): item=0 flags=1 inode=70811920 de\v=09:01 mode=0140750 ouid=501 ogid=3 rdev=00:00 Best Regards -- -- Daniela Gradim B.Sc. daniela.gradim at fortevisiomedica.com Mobile phone: +46-(0)765-48 99 95 --------------------------------------------------------------------- Forte Visio Medica AB Hammarby Fabriksv?g 23 S-120 33 Stockholm Sweden Phone: +46-(0)8-440 03 00 Fax: +46-(0)765-310 100 --------------------------------------------------------------------- THIS COMMUNICATION IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL, OR ENTITY, TO WHICH IT IS DIRECTED AND MAY CONTAIN INFORMATION THAT IS PRIVILIGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. IF RECEIVED IN ERROR: PLEASE NOTIFY US IMMEDIATELY THROUGH info at fortevisiomedica.com. --------------------------------------------------------------------- From jorton at redhat.com Wed Aug 3 12:11:12 2005 From: jorton at redhat.com (Joe Orton) Date: Wed, 3 Aug 2005 13:11:12 +0100 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy Message-ID: <20050803121112.GB18144@redhat.com> I wonder whether this boolean should really just be "on" by default. ----- Forwarded message from bugzilla at redhat.com ----- From: bugzilla at redhat.com To: jorton at redhat.com Date: Wed, 3 Aug 2005 08:02:27 -0400 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164992 Summary: Mod_proxy does not work with SElinux default policy Product: Fedora Core Version: fc4 Platform: i386 OS/Version: Linux Status: NEW Severity: low Priority: normal Component: httpd AssignedTo: jorton at redhat.com ReportedBy: trash_alias at swing.be Estimated Hours: 0.0 >From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 Description of problem: Bad: mod_proxy fail if selinux is enabled [Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(67): proxy: HTTP: canonicalising URL //webmail.XXX.be/exchange/ [Wed Aug 03 13:52:12 2005] [debug] mod_proxy.c(419): Trying to run scheme_handler [Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(1062): proxy: HTTP: serving URL https://webmail.XXX.be/exchange/ [Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(186): proxy: HTTP connecting https://webmail.XXX.be/exchange/ to webmail.XXX.be:443 [Wed Aug 03 13:52:12 2005] [debug] proxy_util.c(1139): proxy: HTTP: fam 2 socket created to connect to webmail.XXX.be Bad: [Wed Aug 03 13:52:12 2005] [error] (13)Permission denied: proxy: HTTP: attempt to connect to 123.123.123.123:443 (webmail.XXX.be) failed Version-Release number of selected component (if applicable): selinux-policy-targeted-1.25.3-9 httpd-2.0.54-10.1 How reproducible: Always Steps to Reproduce: 1.setenforce 1 2.access your http server configured ro reverse proxying 3.fail with message: BAD gateway 4. setenforce 0 5. it work. Expected Results: I would expect the default policy to allow proxying and Message is not explicit and I had to search a long time to understand.... Additional info: -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. ----- End forwarded message ----- From dwalsh at redhat.com Wed Aug 3 13:19:35 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Aug 2005 09:19:35 -0400 Subject: MLS levels and the initial SID for kernel_t In-Reply-To: <42EFCF8A.60204@hp.com> References: <42EFCF8A.60204@hp.com> Message-ID: <42F0C467.4080506@redhat.com> Paul Moore wrote: > Dan's latest MLS policy RPM (as well as some past versions) has a > patch in it, mlspol.patch, which contains the following change for > initial_sid_contexts: > > -sid kernel system_u:system_r:kernel_t:s0 - s9:c0.c127 > +sid kernel system_u:system_r:kernel_t:s9:c0.c127 > > From what I can tell this causes some problems, the biggest of which > being that init starts at s9 which can cause the system to die on boot > when trying to fsck the filesystems. I'm not entirely sure why this > change was made as I would think we would want the kernel to run at > s0-s9 or at the very least s0. Can someone clue me in as to why we > want to run the kernel at s9 or, Dan, can you change it back to s0 - s9? > > Thanks, > I will go with either way. I don't recall why the change was made. -- From dwalsh at redhat.com Wed Aug 3 13:23:08 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Aug 2005 09:23:08 -0400 Subject: update from fc3 -> fc4: cyrus/sasl-errors In-Reply-To: <14319.62.2.21.164.1123050403.squirrel@www.gwch.net> References: <42ECD098.7020406@gwch.net> <1122873683.2613.1.camel@chaucer> <20050801014302.K17051@surf.gcrc.upenn.edu> <42EDF126.5030000@gwch.net> <14319.62.2.21.164.1123050403.squirrel@www.gwch.net> Message-ID: <42F0C53C.1050408@redhat.com> Roger Grosswiler wrote: >Hey, > >I have seen, that in updates-testing exists a new policy, according my >problem. So, i updated as an exception from updates-testing. But: still no >success. But, at least, the list from allow2audit (just from the last >policy reload now is smaller: > >[root at link audit]# audit2allow -i audit.log -l >allow saslauthd_t var_lib_t:dir search; > > Can you try this with setenforce 0. So that we get all the AVC messages? Thanks. > >is this not already better news? Thanks for the update, Dank ;-) > >Roger > >-- >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 Wed Aug 3 13:40:18 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Aug 2005 09:40:18 -0400 Subject: BackupPC and Selinux In-Reply-To: <1123057749.5701.2.camel@localhost.localdomain> References: <1123057749.5701.2.camel@localhost.localdomain> Message-ID: <42F0C942.3090101@redhat.com> Daniela Gradim wrote: >Hi !!! > >I reinstall my BackupPC server but now I have one problem when I try to >connect that server Error: Unable to connect to BackupPC server. I have >installed FC4 and selinux-policy-targeted-1.25.3-6. When I check my >audit log I have many kinds of AVC. What shall I do to make this >working. > >type=AVC_PATH msg=audit(1123052401.490:14046033): path="/dev/console" >type=CWD msg=audit(1123052401.490:14046033): cwd="/home/users/backuppc" >type=PATH msg=audit(1123052401.490:14046033): item=0 name="/bin/ping" >flags=101 inode=59080709 dev=09:01 mode=0104755 ouid=0 ogid=0 rdev=00:00 >type=PATH msg=audit(1123052401.490:14046033): item=1 flags=101 >inode=23531242 dev=09:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 >type=AVC msg=audit(1123052403.947:14059893): avc: denied { use } for >pid=17525 comm="ping" name="console" dev=tmpfs ino=2614 >scontext=system_u:system_r:ping_t tcontext=system_u:system_r:init_t >tclass=fd > >type=AVC msg=audit(1123055904.817:14334333): avc: denied { ioctl } for >pid=20401 comm="httpd" name="Lib.pm" dev=md1 ino=70811835 >scontext=system_u:system_r:httpd_t >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file >type=SYSCALL msg=audit(1123055904.817:14334333): arch=40000003 >syscall=54 success=no exit=-13 a0=1 a1=5401 a2=bfd1bbc8 a3=bfd1bc08 >items=0 pid=20401 auid=4294967295 uid=501 gid=48 euid=501 suid=501 >fsuid=501 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" >type=AVC_PATH msg=audit(1123055904.817:14334333): >path="/home/httpd/html/BackupPC/lib/BackupPC/Lib.pm" >type=AVC msg=audit(1123055904.899:14334889): avc: denied { ioctl } for >pid=2\0401 comm="httpd" name="Lib.pm" dev=md1 ino=70811823 >scontext=system_u:system_r\:httpd_t >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file >type=SYSCALL msg=audit(1123055904.899:14334889): arch=40000003 >syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1bbc8 a3=bfd1bc08 >items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 >fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" >type=AVC_PATH msg=audit(1123055904.899:14334889): >path="/home/httpd/html/Backu\pPC/lib/BackupPC/CGI/Lib.pm" >type=AVC msg=audit(1123055904.961:14334904): avc: denied { ioctl } for >pid=2\0401 comm="httpd" name="config.pl" dev=md1 ino=70812030 >scontext=system_u:syste\m_r:httpd_t >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file >type=SYSCALL msg=audit(1123055904.961:14334904): arch=40000003 >syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c0f8 a3=bfd1c138 >items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 >fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" >type=AVC_PATH msg=audit(1123055904.961:14334904): >path="/home/httpd/html/Backu\pPC/data/conf/config.pl" >type=AVC msg=audit(1123055904.968:14334926): avc: denied { ioctl } for >pid=2\0401 comm="httpd" name="en.pm" dev=md1 ino=70811804 >scontext=system_u:system_r:\httpd_t >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file >type=SYSCALL msg=audit(1123055904.968:14334926): arch=40000003 >syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c0f8 a3=bfd1c138 >items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 >fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" >type=AVC_PATH msg=audit(1123055904.968:14334926): >path="/home/httpd/html/Backu\pPC/lib/BackupPC/Lang/en.pm" >type=AVC msg=audit(1123055904.980:14334955): avc: denied { ioctl } for >pid=2\0401 comm="httpd" name="hosts" dev=md1 ino=70812028 >scontext=system_u:system_r:\httpd_t >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file >type=SYSCALL msg=audit(1123055904.980:14334955): arch=40000003 >syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c148 a3=bfd1c188 >items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 >fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" >type=AVC_PATH msg=audit(1123055904.980:14334955): >path="/home/httpd/html/Backu\pPC/data/conf/hosts" >type=AVC msg=audit(1123055904.982:14334964): avc: denied { ioctl } for >pid=20401 comm="httpd" name="GeneralInfo.pm" dev=md1 ino=70811807 >scontext=system_u:\system_r:httpd_t >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file >type=SYSCALL msg=audit(1123055904.982:14334964): arch=40000003 >syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c0f8 a3=bfd1c138 >items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 >fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" >type=AVC_PATH msg=audit(1123055904.982:14334964): >path="/home/httpd/html/Backu\pPC/lib/BackupPC/type=AVC msg=audit >(1123057381.490:15261737): avc: denied { lock } for pid=20\404 >comm="httpd" name="LOCK" dev=md1 ino=70811933 >scontext=system_u:system_r:ht\tpd_t >tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=file >type=SYSCALL msg=audit(1123057381.490:15261737): arch=40000003 >syscall=143 succ\ess=no exit=-13 a0=0 a1=2 a2=10ebbc0 a3=9ad4700 items=0 >pid=20404 auid=42949672\95 uid=501 gid=48 euid=501 suid=501 fsuid=501 >egid=48 sgid=48 fsgid=48 comm="ht\tpd" exe="/usr/sbin/httpd" >type=AVC_PATH msg=audit(1123057381.490:15261737): >path="/home/httpd/html/Backu\pPC/data/pc/7r04b0j/LOCK" >type=AVC msg=audit(1123057387.694:15262203): avc: denied { write } for >pid=2\0404 comm="httpd" name="BackupPC.sock" dev=md1 ino=70811920 >scontext=system_u:s\ystem_r:httpd_t >tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=sock_\file >type=SYSCALL msg=audit(1123057387.694:15262203): arch=40000003 >syscall=102 succ\ess=no exit=-13 a0=3 a1=bfd1c490 a2=10ebbc0 a3=6e >items=1 pid=20404 auid=429496\7295 uid=501 gid=48 euid=501 suid=501 >fsuid=501 egid=48 sgid=48 fsgid=48 comm="\httpd" exe="/usr/sbin/httpd" >type=SOCKADDR msg=audit(1123057387.694:15262203): >saddr=01002F686F6D652F6874747 >\0642F68746D6C2F4261636B757050432F646174612F6C6F672F4261636B757050432E736F636B00\0000000000000000000000000000000000000000000000000000000000000000000000000000000\000000000000000000000000000000000000000 >type=SOCKETCALL msg=audit(1123057387.694:15262203): nargs=3 a0=1 >a1=9e9c5c8 a2=\6e >type=PATH msg=audit(1123057387.694:15262203): item=0 flags=1 >inode=70811920 de\v=09:01 mode=0140750 ouid=501 ogid=3 rdev=00:00 >CGI/GeneralInfo.pm" >type=AVC msg=audit(1123055904.988:14334976): avc: denied { write } for >pid=2\0401 comm="httpd" name="BackupPC.sock" dev=md1 ino=70811920 >scontext=system_u:s\ystem_r:httpd_t >tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=sock_\file >type=SYSCALL msg=audit(1123055904.988:14334976): arch=40000003 >syscall=102 succ\ess=no exit=-13 a0=3 a1=bfd1c490 a2=10ebbc0 a3=6e >items=1 pid=20401 auid=429496\7295 uid=501 gid=48 euid=501 suid=501 >fsuid=501 egid=48 sgid=48 fsgid=48 comm="\httpd" exe="/usr/sbin/httpd" >type=SOCKADDR msg=audit(1123055904.988:14334976): >saddr=01002F686F6D652F6874747 >\0642F68746D6C2F4261636B757050432F646174612F6C6F672F4261636B757050432E736F636B00\0000000000000000000000000000000000000000000000000000000000000000000000000000000\000000000000000000000000000000000000000 >type=SOCKETCALL msg=audit(1123055904.988:14334976): nargs=3 a0=1 >a1=9e67f28 a2=\6e >type=PATH msg=audit(1123055904.988:14334976): item=0 flags=1 >inode=70811920 de\v=09:01 mode=0140750 ouid=501 ogid=3 rdev=00:00 >type=AVC msg=audit(1123055907.166:14335286): avc: denied { write } for >pid=2\0401 comm="httpd" name="BackupPC.sock" dev=md1 ino=70811920 >scontext=system_u:s\ystem_r:httpd_t >tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=sock_\file >type=SYSCALL msg=audit(1123055907.166:14335286): arch=40000003 >syscall=102 succ\ess=no exit=-13 a0=3 a1=bfd1c490 a2=10ebbc0 a3=6e >items=1 pid=20401 auid=429496\7295 uid=501 gid=48 euid=501 suid=501 >fsuid=501 egid=48 sgid=48 fsgid=48 comm="\httpd" exe="/usr/sbin/httpd" >type=SOCKADDR msg=audit(1123055907.166:14335286): >saddr=01002F686F6D652F6874747 >\0642F68746D6C2F4261636B757050432F646174612F6C6F672F4261636B757050432E736F636B00\0000000000000000000000000000000000000000000000000000000000000000000000000000000\000000000000000000000000000000000000000 >type=SOCKETCALL msg=audit(1123055907.166:14335286): nargs=3 a0=d >a1=9e7ea88 a2=\6e >type=PATH msg=audit(1123055907.166:14335286): item=0 flags=1 >inode=70811920 de\v=09:01 mode=0140750 ouid=501 ogid=3 rdev=00:00 > > >Best Regards > > > Why is everything labeled httpd_sys_script_exec_t? Only the beginning script should be, these files should be labeled httpd_sys_content_t, to get rid of most of the warnings. The sock_file will require a policy update although you can label it httpd_var_run_t for a workaround. -- From dwalsh at redhat.com Wed Aug 3 13:41:43 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 03 Aug 2005 09:41:43 -0400 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <20050803121112.GB18144@redhat.com> References: <20050803121112.GB18144@redhat.com> Message-ID: <42F0C997.5090907@redhat.com> Joe Orton wrote: >I wonder whether this boolean should really just be "on" by default. > >----- Forwarded message from bugzilla at redhat.com ----- > >From: bugzilla at redhat.com >To: jorton at redhat.com >Date: Wed, 3 Aug 2005 08:02:27 -0400 >Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy > >Please do not reply directly to this email. All additional >comments should be made in the comments box of this bug report. > > > > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164992 > > Summary: Mod_proxy does not work with SElinux default policy > Product: Fedora Core > Version: fc4 > Platform: i386 > OS/Version: Linux > Status: NEW > Severity: low > Priority: normal > Component: httpd > AssignedTo: jorton at redhat.com > ReportedBy: trash_alias at swing.be > Estimated Hours: 0.0 > > >>From Bugzilla Helper: >User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 > >Description of problem: >Bad: mod_proxy fail if selinux is enabled > >[Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(67): proxy: HTTP: canonicalising URL //webmail.XXX.be/exchange/ >[Wed Aug 03 13:52:12 2005] [debug] mod_proxy.c(419): Trying to run scheme_handler >[Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(1062): proxy: HTTP: serving URL https://webmail.XXX.be/exchange/ >[Wed Aug 03 13:52:12 2005] [debug] proxy_http.c(186): proxy: HTTP connecting https://webmail.XXX.be/exchange/ to webmail.XXX.be:443 >[Wed Aug 03 13:52:12 2005] [debug] proxy_util.c(1139): proxy: HTTP: fam 2 socket created to >connect to webmail.XXX.be >Bad: [Wed Aug 03 13:52:12 2005] [error] (13)Permission denied: proxy: HTTP: attempt to connect to 123.123.123.123:443 (webmail.XXX.be) failed > > >Version-Release number of selected component (if applicable): >selinux-policy-targeted-1.25.3-9 httpd-2.0.54-10.1 > >How reproducible: >Always > >Steps to Reproduce: >1.setenforce 1 >2.access your http server configured ro reverse proxying >3.fail with message: BAD gateway >4. setenforce 0 >5. it work. > > >Expected Results: I would expect the default policy to allow proxying and Message is not explicit and I had to search a long time to understand.... > >Additional info: > > > We could allow apache to connect to apache ports by default, if that would satisfy this. -- From paul.moore at hp.com Wed Aug 3 13:42:33 2005 From: paul.moore at hp.com (Paul Moore) Date: Wed, 03 Aug 2005 09:42:33 -0400 Subject: MLS levels and the initial SID for kernel_t In-Reply-To: <42F0C467.4080506@redhat.com> References: <42EFCF8A.60204@hp.com> <42F0C467.4080506@redhat.com> Message-ID: <42F0C9C9.7090409@hp.com> Daniel J Walsh wrote: > Paul Moore wrote: > >> Dan's latest MLS policy RPM (as well as some past versions) has a >> patch in it, mlspol.patch, which contains the following change for >> initial_sid_contexts: >> >> -sid kernel system_u:system_r:kernel_t:s0 - s9:c0.c127 >> +sid kernel system_u:system_r:kernel_t:s9:c0.c127 >> >> From what I can tell this causes some problems, the biggest of which >> being that init starts at s9 which can cause the system to die on boot >> when trying to fsck the filesystems. I'm not entirely sure why this >> change was made as I would think we would want the kernel to run at >> s0-s9 or at the very least s0. Can someone clue me in as to why we >> want to run the kernel at s9 or, Dan, can you change it back to s0 - s9? >> >> Thanks, >> > I will go with either way. I don't recall why the change was made. > If given a choice I would say s0 - s9 makes the most sense. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From jorton at redhat.com Wed Aug 3 13:45:07 2005 From: jorton at redhat.com (Joe Orton) Date: Wed, 3 Aug 2005 14:45:07 +0100 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <42F0C997.5090907@redhat.com> References: <20050803121112.GB18144@redhat.com> <42F0C997.5090907@redhat.com> Message-ID: <20050803134507.GC18144@redhat.com> On Wed, Aug 03, 2005 at 09:41:43AM -0400, Daniel J Walsh wrote: > Joe Orton wrote: > >Expected Results: I would expect the default policy to allow proxying and > >Message is not explicit and I had to search a long time to understand.... > > > >Additional info: > > > > > > > We could allow apache to connect to apache ports by default, if that > would satisfy this. No, when mod_proxy is used as a generic HTTP proxy (a not entirely uncommon configuration) it needs to be able to connect to any remote port on any remote address. joe From chanson at TrustedCS.com Wed Aug 3 13:46:59 2005 From: chanson at TrustedCS.com (Chad Hanson) Date: Wed, 3 Aug 2005 09:46:59 -0400 Subject: MLS levels and the initial SID for kernel_t Message-ID: <36282A1733C57546BE392885C0618592B51721@chaos.tcs.tcs-sec.com> The kernel on an MLS system should be at system high. There is a range transition rule for init to transition to s0 (system low). fsck should have mls privileges to read the raw devices which are protected at system high, the same label as the kernel. If these privileges are missing we need to add them into the policy. The kernel itself shouldn't be a ranged object, it should system high, especially since this should also be the label of devices such as kmem, because they don't arbitrate access to objects, but instead give access to raw data (memory). Since the data is raw, the safe assumption to make is that the data might be system_high so it should be labeled as such. The same holds true for unlabeled files. Interfaces such as filesystems arbitrate access to data and make an MLS decision based on the label of subject and object. -Chad > Paul Moore wrote: > > > Dan's latest MLS policy RPM (as well as some past versions) has a > > patch in it, mlspol.patch, which contains the following change for > > initial_sid_contexts: > > > > -sid kernel system_u:system_r:kernel_t:s0 - s9:c0.c127 > > +sid kernel system_u:system_r:kernel_t:s9:c0.c127 > > > > From what I can tell this causes some problems, the biggest > of which > > being that init starts at s9 which can cause the system to > die on boot > > when trying to fsck the filesystems. I'm not entirely sure > why this > > change was made as I would think we would want the kernel to run at > > s0-s9 or at the very least s0. Can someone clue me in as to why we > > want to run the kernel at s9 or, Dan, can you change it > back to s0 - s9? > > > > Thanks, > > > I will go with either way. I don't recall why the change was made. > From paul.moore at hp.com Wed Aug 3 14:26:17 2005 From: paul.moore at hp.com (Paul Moore) Date: Wed, 03 Aug 2005 10:26:17 -0400 Subject: MLS levels and the initial SID for kernel_t In-Reply-To: <36282A1733C57546BE392885C0618592B51721@chaos.tcs.tcs-sec.com> References: <36282A1733C57546BE392885C0618592B51721@chaos.tcs.tcs-sec.com> Message-ID: <42F0D409.2000008@hp.com> Chad Hanson wrote: > The kernel on an MLS system should be at system high. There is a range > transition rule for init to transition to s0 (system low). fsck should have > mls privileges to read the raw devices which are protected at system high, > the same label as the kernel. If these privileges are missing we need to add > them into the policy. > > The kernel itself shouldn't be a ranged object, it should system high, > especially since this should also be the label of devices such as kmem, > because they don't arbitrate access to objects, but instead give access to > raw data (memory). Since the data is raw, the safe assumption to make is > that the data might be system_high so it should be labeled as such. The same > holds true for unlabeled files. > > Interfaces such as filesystems arbitrate access to data and make an MLS > decision based on the label of subject and object. > > -Chad Thanks for the explanation Chad. With not clear reason and only a problem, I was getting so frustrated with this problem that I was starting to convince myself that both ways were right. However, running the kernel at s9 puts me right back to where I started, a busted system. Looking at domains/misc/kernel.te I see the following lines: ifdef(`mls_policy', ` # run init with maximum MLS range range_transition kernel_t init_exec_t s0 - s9:c0.c127; ') checking further I see that 'mls_policy' is enabled and the range_transition rule is in fact present in the policy.conf file (in fact it is the *only* range_transition rule present). I have verified that '/sbin/init' is labeled properly and even tried changing the range_transition rule from s0 - s9 to simply s0 and have not had any luck (a shot in the dark). This makes me think one of three things is happening: 1. A type running at levels X1 - X2 can only transition to a subset of those levels, i.e. s7-s9 can transition to s8-s9 or s9 but not s0-s9. A comment in the 'mls' file looks like this may be the case (but I am still not 100% clear on how to read this file): # new process labels must be dominated by the relabeling subject's # clearance and sensitivity level changes require privilege mlsconstrain process transition (( h1 dom h2 ) and (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or (( t1 == privrangetrans ) and ( t2 == mlsrangetrans )))); mlsconstrain process dyntransition (( h1 dom h2 ) and (( l1 eq l2 ) or ( t1 == mlsprocsetsl ))); 2. The range_transition rule in the kernel is broken. 3. The range_transition rule in kernel.te is incorrectly written. Thoughts? >>Paul Moore wrote: >> >> >>>Dan's latest MLS policy RPM (as well as some past versions) has a >>>patch in it, mlspol.patch, which contains the following change for >>>initial_sid_contexts: >>> >>> -sid kernel system_u:system_r:kernel_t:s0 - s9:c0.c127 >>> +sid kernel system_u:system_r:kernel_t:s9:c0.c127 >>> >>>From what I can tell this causes some problems, the biggest >> >>of which >> >>>being that init starts at s9 which can cause the system to >> >>die on boot >> >>>when trying to fsck the filesystems. I'm not entirely sure >> >>why this >> >>>change was made as I would think we would want the kernel to run at >>>s0-s9 or at the very least s0. Can someone clue me in as to why we >>>want to run the kernel at s9 or, Dan, can you change it >> >>back to s0 - s9? >> >>>Thanks, >>> >> >>I will go with either way. I don't recall why the change was made. >> > > -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From fedora at grifent.com Wed Aug 3 17:42:39 2005 From: fedora at grifent.com (John Griffiths) Date: Wed, 03 Aug 2005 13:42:39 -0400 Subject: httpd conect to database In-Reply-To: <20050803160026.C8A20738EC@hormel.redhat.com> References: <20050803160026.C8A20738EC@hormel.redhat.com> Message-ID: <42F1020F.9060200@grifent.com> I currently run a forum using phpBB with postgresql as the database. It is currently hosted on SuSE 9.2. I would like to move from SuSE to FC4 and I want to keep the SELinux protections. If I have SELinux enforcing in targeted, phpBB cannot connect to the database. If SELinux is in permissive, phpBB can connect to the database. I am a newbie to SELinux and have no idea how to write my own rules and the learning curve seems a bit steep. I will get there, but any help would be appreciated solving this. TIA, John From paul at city-fan.org Wed Aug 3 18:24:38 2005 From: paul at city-fan.org (Paul Howarth) Date: Wed, 03 Aug 2005 19:24:38 +0100 Subject: httpd conect to database In-Reply-To: <42F1020F.9060200@grifent.com> References: <20050803160026.C8A20738EC@hormel.redhat.com> <42F1020F.9060200@grifent.com> Message-ID: <1123093479.2851.366.camel@laurel.intra.city-fan.org> On Wed, 2005-08-03 at 13:42 -0400, John Griffiths wrote: > I currently run a forum using phpBB with postgresql as the database. It > is currently hosted on SuSE 9.2. > > I would like to move from SuSE to FC4 and I want to keep the SELinux > protections. If I have SELinux enforcing in targeted, phpBB cannot > connect to the database. If SELinux is in permissive, phpBB can connect > to the database. > > I am a newbie to SELinux and have no idea how to write my own rules and > the learning curve seems a bit steep. I will get there, but any help > would be appreciated solving this. You might find the FC3 SELinux Apache FAQ useful. Most of it is still useful in FC4, and it's what introduced me to tweaking SELinux policy. http://fedora.redhat.com/docs/selinux-apache-fc3/sn-debugging-and-customizing.html The document's examples assume you're using the strict policy rather than targeted, so watch out for that, but other than that there's probably enough there to get you sorted. Paul. -- Paul Howarth From kwade at redhat.com Thu Aug 4 08:40:45 2005 From: kwade at redhat.com (Karsten Wade) Date: Thu, 04 Aug 2005 01:40:45 -0700 Subject: live FAQ updates at LinuxWorld Message-ID: <1123144845.6692.70.camel@erato.phig.org> Better than getting your face painted! This coming week I'll be at the Fedora Project booth at LinuxWorld in San Francisco. Sometime in there I'll be giving an SELinux presentation, and I'm working on having some play equipment during part of the expo. If you come by to talk SELinux and we get to a good question for the SELinux FAQ[1], I'll do a live update of the FAQ with your question and hopefully an answer. Hope to see you there! - Karsten [1] Languishing at http://fedora.redhat.com/docs/selinux-faq/ without an FC4 version, that is what I'll be working on. Live changes will go immediately to source CVS, and I'll do regular updates of the website copy when it makes sense to. -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Red Hat SELinux Guide http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/ -------------- 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 daniela.gradim at fortevisiomedica.com Thu Aug 4 10:11:52 2005 From: daniela.gradim at fortevisiomedica.com (Daniela Gradim) Date: Thu, 04 Aug 2005 12:11:52 +0200 Subject: BackupPC and Selinux In-Reply-To: <42F0C942.3090101@redhat.com> References: <1123057749.5701.2.camel@localhost.localdomain> <42F0C942.3090101@redhat.com> Message-ID: <1123150312.4886.6.camel@localhost.localdomain> On Wed, 2005-08-03 at 09:40 -0400, Daniel J Walsh wrote: > Daniela Gradim wrote: > > >Hi !!! > > > >I reinstall my BackupPC server but now I have one problem when I try to > >connect that server Error: Unable to connect to BackupPC server. I have > >installed FC4 and selinux-policy-targeted-1.25.3-6. When I check my > >audit log I have many kinds of AVC. What shall I do to make this > >working. > > > >type=AVC_PATH msg=audit(1123052401.490:14046033): path="/dev/console" > >type=CWD msg=audit(1123052401.490:14046033): cwd="/home/users/backuppc" > >type=PATH msg=audit(1123052401.490:14046033): item=0 name="/bin/ping" > >flags=101 inode=59080709 dev=09:01 mode=0104755 ouid=0 ogid=0 rdev=00:00 > >type=PATH msg=audit(1123052401.490:14046033): item=1 flags=101 > >inode=23531242 dev=09:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 > >type=AVC msg=audit(1123052403.947:14059893): avc: denied { use } for > >pid=17525 comm="ping" name="console" dev=tmpfs ino=2614 > >scontext=system_u:system_r:ping_t tcontext=system_u:system_r:init_t > >tclass=fd > > > >type=AVC msg=audit(1123055904.817:14334333): avc: denied { ioctl } for > >pid=20401 comm="httpd" name="Lib.pm" dev=md1 ino=70811835 > >scontext=system_u:system_r:httpd_t > >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file > >type=SYSCALL msg=audit(1123055904.817:14334333): arch=40000003 > >syscall=54 success=no exit=-13 a0=1 a1=5401 a2=bfd1bbc8 a3=bfd1bc08 > >items=0 pid=20401 auid=4294967295 uid=501 gid=48 euid=501 suid=501 > >fsuid=501 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" > >type=AVC_PATH msg=audit(1123055904.817:14334333): > >path="/home/httpd/html/BackupPC/lib/BackupPC/Lib.pm" > >type=AVC msg=audit(1123055904.899:14334889): avc: denied { ioctl } for > >pid=2\0401 comm="httpd" name="Lib.pm" dev=md1 ino=70811823 > >scontext=system_u:system_r\:httpd_t > >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file > >type=SYSCALL msg=audit(1123055904.899:14334889): arch=40000003 > >syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1bbc8 a3=bfd1bc08 > >items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 > >fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" > >type=AVC_PATH msg=audit(1123055904.899:14334889): > >path="/home/httpd/html/Backu\pPC/lib/BackupPC/CGI/Lib.pm" > >type=AVC msg=audit(1123055904.961:14334904): avc: denied { ioctl } for > >pid=2\0401 comm="httpd" name="config.pl" dev=md1 ino=70812030 > >scontext=system_u:syste\m_r:httpd_t > >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file > >type=SYSCALL msg=audit(1123055904.961:14334904): arch=40000003 > >syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c0f8 a3=bfd1c138 > >items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 > >fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" > >type=AVC_PATH msg=audit(1123055904.961:14334904): > >path="/home/httpd/html/Backu\pPC/data/conf/config.pl" > >type=AVC msg=audit(1123055904.968:14334926): avc: denied { ioctl } for > >pid=2\0401 comm="httpd" name="en.pm" dev=md1 ino=70811804 > >scontext=system_u:system_r:\httpd_t > >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file > >type=SYSCALL msg=audit(1123055904.968:14334926): arch=40000003 > >syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c0f8 a3=bfd1c138 > >items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 > >fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" > >type=AVC_PATH msg=audit(1123055904.968:14334926): > >path="/home/httpd/html/Backu\pPC/lib/BackupPC/Lang/en.pm" > >type=AVC msg=audit(1123055904.980:14334955): avc: denied { ioctl } for > >pid=2\0401 comm="httpd" name="hosts" dev=md1 ino=70812028 > >scontext=system_u:system_r:\httpd_t > >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file > >type=SYSCALL msg=audit(1123055904.980:14334955): arch=40000003 > >syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c148 a3=bfd1c188 > >items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 > >fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" > >type=AVC_PATH msg=audit(1123055904.980:14334955): > >path="/home/httpd/html/Backu\pPC/data/conf/hosts" > >type=AVC msg=audit(1123055904.982:14334964): avc: denied { ioctl } for > >pid=20401 comm="httpd" name="GeneralInfo.pm" dev=md1 ino=70811807 > >scontext=system_u:\system_r:httpd_t > >tcontext=root:object_r:httpd_sys_script_exec_t tclass=file > >type=SYSCALL msg=audit(1123055904.982:14334964): arch=40000003 > >syscall=54 succe\ss=no exit=-13 a0=1 a1=5401 a2=bfd1c0f8 a3=bfd1c138 > >items=0 pid=20401 auid=4294\967295 uid=501 gid=48 euid=501 suid=501 > >fsuid=501 egid=48 sgid=48 fsgid=48 comm\="httpd" exe="/usr/sbin/httpd" > >type=AVC_PATH msg=audit(1123055904.982:14334964): > >path="/home/httpd/html/Backu\pPC/lib/BackupPC/type=AVC msg=audit > >(1123057381.490:15261737): avc: denied { lock } for pid=20\404 > >comm="httpd" name="LOCK" dev=md1 ino=70811933 > >scontext=system_u:system_r:ht\tpd_t > >tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=file > >type=SYSCALL msg=audit(1123057381.490:15261737): arch=40000003 > >syscall=143 succ\ess=no exit=-13 a0=0 a1=2 a2=10ebbc0 a3=9ad4700 items=0 > >pid=20404 auid=42949672\95 uid=501 gid=48 euid=501 suid=501 fsuid=501 > >egid=48 sgid=48 fsgid=48 comm="ht\tpd" exe="/usr/sbin/httpd" > >type=AVC_PATH msg=audit(1123057381.490:15261737): > >path="/home/httpd/html/Backu\pPC/data/pc/7r04b0j/LOCK" > >type=AVC msg=audit(1123057387.694:15262203): avc: denied { write } for > >pid=2\0404 comm="httpd" name="BackupPC.sock" dev=md1 ino=70811920 > >scontext=system_u:s\ystem_r:httpd_t > >tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=sock_\file > >type=SYSCALL msg=audit(1123057387.694:15262203): arch=40000003 > >syscall=102 succ\ess=no exit=-13 a0=3 a1=bfd1c490 a2=10ebbc0 a3=6e > >items=1 pid=20404 auid=429496\7295 uid=501 gid=48 euid=501 suid=501 > >fsuid=501 egid=48 sgid=48 fsgid=48 comm="\httpd" exe="/usr/sbin/httpd" > >type=SOCKADDR msg=audit(1123057387.694:15262203): > >saddr=01002F686F6D652F6874747 > >\0642F68746D6C2F4261636B757050432F646174612F6C6F672F4261636B757050432E736F636B00\0000000000000000000000000000000000000000000000000000000000000000000000000000000\000000000000000000000000000000000000000 > >type=SOCKETCALL msg=audit(1123057387.694:15262203): nargs=3 a0=1 > >a1=9e9c5c8 a2=\6e > >type=PATH msg=audit(1123057387.694:15262203): item=0 flags=1 > >inode=70811920 de\v=09:01 mode=0140750 ouid=501 ogid=3 rdev=00:00 > >CGI/GeneralInfo.pm" > >type=AVC msg=audit(1123055904.988:14334976): avc: denied { write } for > >pid=2\0401 comm="httpd" name="BackupPC.sock" dev=md1 ino=70811920 > >scontext=system_u:s\ystem_r:httpd_t > >tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=sock_\file > >type=SYSCALL msg=audit(1123055904.988:14334976): arch=40000003 > >syscall=102 succ\ess=no exit=-13 a0=3 a1=bfd1c490 a2=10ebbc0 a3=6e > >items=1 pid=20401 auid=429496\7295 uid=501 gid=48 euid=501 suid=501 > >fsuid=501 egid=48 sgid=48 fsgid=48 comm="\httpd" exe="/usr/sbin/httpd" > >type=SOCKADDR msg=audit(1123055904.988:14334976): > >saddr=01002F686F6D652F6874747 > >\0642F68746D6C2F4261636B757050432F646174612F6C6F672F4261636B757050432E736F636B00\0000000000000000000000000000000000000000000000000000000000000000000000000000000\000000000000000000000000000000000000000 > >type=SOCKETCALL msg=audit(1123055904.988:14334976): nargs=3 a0=1 > >a1=9e67f28 a2=\6e > >type=PATH msg=audit(1123055904.988:14334976): item=0 flags=1 > >inode=70811920 de\v=09:01 mode=0140750 ouid=501 ogid=3 rdev=00:00 > >type=AVC msg=audit(1123055907.166:14335286): avc: denied { write } for > >pid=2\0401 comm="httpd" name="BackupPC.sock" dev=md1 ino=70811920 > >scontext=system_u:s\ystem_r:httpd_t > >tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=sock_\file > >type=SYSCALL msg=audit(1123055907.166:14335286): arch=40000003 > >syscall=102 succ\ess=no exit=-13 a0=3 a1=bfd1c490 a2=10ebbc0 a3=6e > >items=1 pid=20401 auid=429496\7295 uid=501 gid=48 euid=501 suid=501 > >fsuid=501 egid=48 sgid=48 fsgid=48 comm="\httpd" exe="/usr/sbin/httpd" > >type=SOCKADDR msg=audit(1123055907.166:14335286): > >saddr=01002F686F6D652F6874747 > >\0642F68746D6C2F4261636B757050432F646174612F6C6F672F4261636B757050432E736F636B00\0000000000000000000000000000000000000000000000000000000000000000000000000000000\000000000000000000000000000000000000000 > >type=SOCKETCALL msg=audit(1123055907.166:14335286): nargs=3 a0=d > >a1=9e7ea88 a2=\6e > >type=PATH msg=audit(1123055907.166:14335286): item=0 flags=1 > >inode=70811920 de\v=09:01 mode=0140750 ouid=501 ogid=3 rdev=00:00 > > > > > >Best Regards > > > > > > > Why is everything labeled httpd_sys_script_exec_t? > Only the beginning script should be, these files should be labeled > httpd_sys_content_t, to get rid of most of the warnings. The sock_file > will require a policy update although you can label it httpd_var_run_t > for a workaround. > Tanks for your help. I change the httpd_sys_script_exec_t now I don't have more the warnings. I still have a problem with the sock_file, I update the policy and now the message error change. Now I have this version selinux-policy-targeted-1.25.3-9. type=AVC msg=audit(1123150177.621:5759070): avc: denied { connectto } for pid=20403 comm="httpd" name="BackupPC.sock" scontext=system_u:system_r:httpd_t tcontext=system_u:system_r:initrc_t tclass=unix_stream_socket type=SYSCALL msg=audit(1123150177.621:5759070): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfd1c490 a2=10ebbc0 a3=6e items=1 pid=20403 auid=4294967295 uid=501 gid=48 euid=501 suid=501 fsuid=501 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" type=AVC_PATH msg=audit(1123150177.621:5759070): path="/home/httpd/html/BackupPC/data/log/BackupPC.sock" type=SOCKADDR msg=audit(1123150177.621:5759070): saddr=01002F686F6D652F68747470642F68746D6C2F4261636B757050432F646174612F6C6F672F4261636B757050432E736F636B000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 type=SOCKETCALL msg=audit(1123150177.621:5759070): nargs=3 a0=1 a1=9fcabd8 a2=6etype=PATH msg=audit(1123150177.621:5759070): item=0 flags=1 inode=70811920 dev=09:01 mode=0140750 ouid=501 ogid=3 rdev=00:00 One thing more what means this message above type=AVC msg=audit(1123149608.771:5722457): avc: denied { use } for pid=32158 comm="ping" name="console" dev=tmpfs ino=2614 scontext=system_u:system_r:ping_t tcontext=system_u:system_r:init_t tclass=fd type=SYSCALL msg=audit(1123149608.771:5722457): arch=40000003 syscall=11 success=yes exit=0 a0=a295650 a1=a290ff0 a2=9cf3b38 a3=bfb69718 items=2 pid=32158 auid=4294967295 uid=501 gid=3 euid=0 suid=0 fsuid=0 egid=3 sgid=3 fsgid=3 comm="ping" exe="/bin/ping" type=AVC_PATH msg=audit(1123149608.771:5722457): path="/dev/console" type=CWD msg=audit(1123149608.771:5722457): cwd="/home/users/backuppc" type=PATH msg=audit(1123149608.771:5722457): item=0 name="/bin/ping" flags=101 inode=59080709 dev=09:01 mode=0104755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1123149608.771:5722457): item=1 flags=101 inode=23531242 dev=09:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 Best Regards. -- -- Daniela Gradim B.Sc. daniela.gradim at fortevisiomedica.com Mobile phone: +46-(0)765-48 99 95 --------------------------------------------------------------------- Forte Visio Medica AB Hammarby Fabriksv?g 23 S-120 33 Stockholm Sweden Phone: +46-(0)8-440 03 00 Fax: +46-(0)765-310 100 --------------------------------------------------------------------- THIS COMMUNICATION IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL, OR ENTITY, TO WHICH IT IS DIRECTED AND MAY CONTAIN INFORMATION THAT IS PRIVILIGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. IF RECEIVED IN ERROR: PLEASE NOTIFY US IMMEDIATELY THROUGH info at fortevisiomedica.com. --------------------------------------------------------------------- From jkim at TrustedCS.com Fri Aug 5 15:36:25 2005 From: jkim at TrustedCS.com (Jonathan Kim) Date: Fri, 5 Aug 2005 11:36:25 -0400 Subject: MLS levels and the initial SID for kernel_t Message-ID: <36282A1733C57546BE392885C0618592B51A96@chaos.tcs.tcs-sec.com> Paul, I recall that the problems you were having were resolved after you followed the steps I sent. Did you follow the exact procedure I sent you? If not, could you let me know the exact procedure you followed? Below are answers to your questions: > 1. A type running at levels X1 - X2 can only transition to > a subset of > those levels, i.e. s7-s9 can transition to s8-s9 or s9 but not > s0-s9. A comment in the 'mls' file looks like this may > be the case > (but I am still not 100% clear on how to read this file): > > # new process labels must be dominated by the relabeling > subject's > # clearance and sensitivity level changes require privilege > mlsconstrain process transition > (( h1 dom h2 ) and > (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or > (( t1 == privrangetrans ) and ( t2 == mlsrangetrans )))); We want init_t:s0-s9:c0.c127 as a result of kernel_t:s9 executing init_exec_t binary. The type transition happens because domain_auto_trans(kernel_t, init_exec_t, init_t) is stated in kernel.te. The MLS level transition happens because range_transition kernel_t init_exec_t s0 - s9:c0.c127 is stated in kernel.te. Now we want to make sure the above "process transition" constraint is not preventing this transition. Subject domain (t1) is kernel_t, effective level (l1) is s9 and clearance level (h1) is s9. Object domain (t2) is init_t and effective level (l2) is s0 and clearance level (h2) is s9. Since h1 dominates h2, then to satisfy the above constraint, one of the following conditions needs to be met: 1. l1 eq l2, or 2. t1 == mlsprocsetsl, or 3. t1 == privrangetrans and t2 == mlsrangetrans 1 and 2 are false, but 3 is true since privrangetrans is assigned to kernel_t (in kernel.te) mlsrangetrans is assigned to init_t (in init.te) So the above rule should not cause any problem and is correct. Moreover all the necessary rules for the transition is provided in the policy. And the dyntransition constraints have nothing to do with this topic, so we don't have to review them here. > -----Original Message----- > From: Paul Moore [mailto:paul.moore at hp.com] > Sent: Wednesday, August 03, 2005 9:26 AM > To: Chad Hanson > Cc: Daniel J Walsh; fedora-selinux-list at redhat.com > Subject: Re: MLS levels and the initial SID for kernel_t > > > Chad Hanson wrote: > > The kernel on an MLS system should be at system high. There > is a range > > transition rule for init to transition to s0 (system low). > fsck should have > > mls privileges to read the raw devices which are protected > at system high, > > the same label as the kernel. If these privileges are > missing we need to add > > them into the policy. > > > > The kernel itself shouldn't be a ranged object, it should > system high, > > especially since this should also be the label of devices > such as kmem, > > because they don't arbitrate access to objects, but instead > give access to > > raw data (memory). Since the data is raw, the safe > assumption to make is > > that the data might be system_high so it should be labeled > as such. The same > > holds true for unlabeled files. > > > > Interfaces such as filesystems arbitrate access to data and > make an MLS > > decision based on the label of subject and object. > > > > -Chad > > Thanks for the explanation Chad. With not clear reason and only a > problem, I was getting so frustrated with this problem that I was > starting to convince myself that both ways were right. > > However, running the kernel at s9 puts me right back to where > I started, > a busted system. Looking at domains/misc/kernel.te I see the > following > lines: > > ifdef(`mls_policy', ` > # run init with maximum MLS range > range_transition kernel_t init_exec_t s0 - s9:c0.c127; > ') > > checking further I see that 'mls_policy' is enabled and the > range_transition rule is in fact present in the policy.conf file (in > fact it is the *only* range_transition rule present). I have > verified > that '/sbin/init' is labeled properly and even tried changing the > range_transition rule from s0 - s9 to simply s0 and have not had any > luck (a shot in the dark). > > This makes me think one of three things is happening: > > 1. A type running at levels X1 - X2 can only transition to > a subset of > those levels, i.e. s7-s9 can transition to s8-s9 or s9 but not > s0-s9. A comment in the 'mls' file looks like this may > be the case > (but I am still not 100% clear on how to read this file): > > # new process labels must be dominated by the relabeling > subject's > # clearance and sensitivity level changes require privilege > mlsconstrain process transition > (( h1 dom h2 ) and > (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or > (( t1 == privrangetrans ) and ( t2 == mlsrangetrans )))); > mlsconstrain process dyntransition > (( h1 dom h2 ) and > (( l1 eq l2 ) or ( t1 == mlsprocsetsl ))); > > 2. The range_transition rule in the kernel is broken. > 3. The range_transition rule in kernel.te is incorrectly written. > > Thoughts? > > >>Paul Moore wrote: > >> > >> > >>>Dan's latest MLS policy RPM (as well as some past versions) has a > >>>patch in it, mlspol.patch, which contains the following change for > >>>initial_sid_contexts: > >>> > >>> -sid kernel system_u:system_r:kernel_t:s0 - s9:c0.c127 > >>> +sid kernel system_u:system_r:kernel_t:s9:c0.c127 > >>> > >>>From what I can tell this causes some problems, the biggest > >> > >>of which > >> > >>>being that init starts at s9 which can cause the system to > >> > >>die on boot > >> > >>>when trying to fsck the filesystems. I'm not entirely sure > >> > >>why this > >> > >>>change was made as I would think we would want the kernel > to run at > >>>s0-s9 or at the very least s0. Can someone clue me in as > to why we > >>>want to run the kernel at s9 or, Dan, can you change it > >> > >>back to s0 - s9? > >> > >>>Thanks, > >>> > >> > >>I will go with either way. I don't recall why the change was made. > >> > > > > > > > From paul.moore at hp.com Fri Aug 5 15:54:40 2005 From: paul.moore at hp.com (Paul Moore) Date: Fri, 05 Aug 2005 11:54:40 -0400 Subject: MLS levels and the initial SID for kernel_t In-Reply-To: <36282A1733C57546BE392885C0618592B51A96@chaos.tcs.tcs-sec.com> References: <36282A1733C57546BE392885C0618592B51A96@chaos.tcs.tcs-sec.com> Message-ID: <42F38BC0.1080000@hp.com> Jonathan Kim wrote: > Paul, > > I recall that the problems you were having were resolved after you followed > the steps I sent. > Did you follow the exact procedure I sent you? > If not, could you let me know the exact procedure you followed? Yes, the steps you sent me a few weeks ago did work but later versions of the policy RPM caused it to fail. Fresh install or upgrades both resulted in failure. The reason appears to be here in security/selinux/ss/mls.c line 521: if (rangetr->dom == scontext->type && rangetr->type == tcontext->type) { /* Set the range from the rule */ return mls_range_set(newcontext, &rangetr->range); } For some reason the 'dom'/'type' values for the only rule in 'rangetr' do not match with the values of 'kernel_t' and 'init_exec_t' in 'scontext->type' and 'tcontext->type' respectively. Looking at the range_transition types in the binary policy file, policy.19, the types in the file appear to match the types stored in 'rangetr' which appear to match the 'kernel_t' and 'init_exec_t' type values inside of checkpolicy-1.25.3/policy_parse.y as returned by the following lines of debug code I inserted: { type_datum_t *kt, *it; kt = hashtab_search(policydbp->p_types.table, "kernel_t"); it = hashtab_search(policydbp->p_types.table, "init_exec_t"); printf("PMD(#4): kernel_t=%u init_exec_t=%u\n", kt->value, it->value); } This is where I am currently at, trying to figure out why 'scontext->type' and 'tcontext->type' appear to change values in the kernel ... or why I am barking up the wrong tree :) If anyone has any suggestions I am all ears ... > Below are answers to your questions: > > >> 1. A type running at levels X1 - X2 can only transition to >>a subset of >> those levels, i.e. s7-s9 can transition to s8-s9 or s9 but not >> s0-s9. A comment in the 'mls' file looks like this may >>be the case >> (but I am still not 100% clear on how to read this file): >> >> # new process labels must be dominated by the relabeling >>subject's >> # clearance and sensitivity level changes require privilege >> mlsconstrain process transition >> (( h1 dom h2 ) and >> (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or >> (( t1 == privrangetrans ) and ( t2 == mlsrangetrans )))); > > > We want init_t:s0-s9:c0.c127 as a result of kernel_t:s9 executing > init_exec_t binary. > > The type transition happens because domain_auto_trans(kernel_t, init_exec_t, > init_t) is stated in kernel.te. > > The MLS level transition happens because range_transition kernel_t > init_exec_t s0 - s9:c0.c127 is stated in kernel.te. > > Now we want to make sure the above "process transition" constraint is not > preventing this transition. > > Subject domain (t1) is kernel_t, effective level (l1) is s9 and clearance > level (h1) is s9. > Object domain (t2) is init_t and effective level (l2) is s0 and clearance > level (h2) is s9. > > Since h1 dominates h2, then to satisfy the above constraint, one of > the following conditions needs to be met: > 1. l1 eq l2, or > 2. t1 == mlsprocsetsl, or > 3. t1 == privrangetrans and t2 == mlsrangetrans > > 1 and 2 are false, but 3 is true since > privrangetrans is assigned to kernel_t (in kernel.te) > mlsrangetrans is assigned to init_t (in init.te) > > So the above rule should not cause any problem and is correct. > Moreover all the necessary rules for the transition is provided in the > policy. > > And the dyntransition constraints have nothing to do with this topic, so we > don't have to review them here. > > > >>-----Original Message----- >>From: Paul Moore [mailto:paul.moore at hp.com] >>Sent: Wednesday, August 03, 2005 9:26 AM >>To: Chad Hanson >>Cc: Daniel J Walsh; fedora-selinux-list at redhat.com >>Subject: Re: MLS levels and the initial SID for kernel_t >> >> >>Chad Hanson wrote: >> >>>The kernel on an MLS system should be at system high. There >> >>is a range >> >>>transition rule for init to transition to s0 (system low). >> >>fsck should have >> >>>mls privileges to read the raw devices which are protected >> >>at system high, >> >>>the same label as the kernel. If these privileges are >> >>missing we need to add >> >>>them into the policy. >>> >>>The kernel itself shouldn't be a ranged object, it should >> >>system high, >> >>>especially since this should also be the label of devices >> >>such as kmem, >> >>>because they don't arbitrate access to objects, but instead >> >>give access to >> >>>raw data (memory). Since the data is raw, the safe >> >>assumption to make is >> >>>that the data might be system_high so it should be labeled >> >>as such. The same >> >>>holds true for unlabeled files. >>> >>>Interfaces such as filesystems arbitrate access to data and >> >>make an MLS >> >>>decision based on the label of subject and object. >>> >>>-Chad >> >>Thanks for the explanation Chad. With not clear reason and only a >>problem, I was getting so frustrated with this problem that I was >>starting to convince myself that both ways were right. >> >>However, running the kernel at s9 puts me right back to where >>I started, >>a busted system. Looking at domains/misc/kernel.te I see the >>following >>lines: >> >> ifdef(`mls_policy', ` >> # run init with maximum MLS range >> range_transition kernel_t init_exec_t s0 - s9:c0.c127; >> ') >> >>checking further I see that 'mls_policy' is enabled and the >>range_transition rule is in fact present in the policy.conf file (in >>fact it is the *only* range_transition rule present). I have >>verified >>that '/sbin/init' is labeled properly and even tried changing the >>range_transition rule from s0 - s9 to simply s0 and have not had any >>luck (a shot in the dark). >> >>This makes me think one of three things is happening: >> >> 1. A type running at levels X1 - X2 can only transition to >>a subset of >> those levels, i.e. s7-s9 can transition to s8-s9 or s9 but not >> s0-s9. A comment in the 'mls' file looks like this may >>be the case >> (but I am still not 100% clear on how to read this file): >> >> # new process labels must be dominated by the relabeling >>subject's >> # clearance and sensitivity level changes require privilege >> mlsconstrain process transition >> (( h1 dom h2 ) and >> (( l1 eq l2 ) or ( t1 == mlsprocsetsl ) or >> (( t1 == privrangetrans ) and ( t2 == mlsrangetrans )))); >> mlsconstrain process dyntransition >> (( h1 dom h2 ) and >> (( l1 eq l2 ) or ( t1 == mlsprocsetsl ))); >> >> 2. The range_transition rule in the kernel is broken. >> 3. The range_transition rule in kernel.te is incorrectly written. >> >>Thoughts? >> >> >>>>Paul Moore wrote: >>>> >>>> >>>> >>>>>Dan's latest MLS policy RPM (as well as some past versions) has a >>>>>patch in it, mlspol.patch, which contains the following change for >>>>>initial_sid_contexts: >>>>> >>>>>-sid kernel system_u:system_r:kernel_t:s0 - s9:c0.c127 >>>>>+sid kernel system_u:system_r:kernel_t:s9:c0.c127 >>>>> >>>> >>>>>From what I can tell this causes some problems, the biggest >>>> >>>>of which >>>> >>>> >>>>>being that init starts at s9 which can cause the system to >>>> >>>>die on boot >>>> >>>> >>>>>when trying to fsck the filesystems. I'm not entirely sure >>>> >>>>why this >>>> >>>> >>>>>change was made as I would think we would want the kernel >> >>to run at >> >>>>>s0-s9 or at the very least s0. Can someone clue me in as >> >>to why we >> >>>>>want to run the kernel at s9 or, Dan, can you change it >>>> >>>>back to s0 - s9? >>>> >>>> >>>>>Thanks, >>>>> >>>> >>>>I will go with either way. I don't recall why the change was made. >>>> >>> >>> >> > > -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From dwalsh at redhat.com Fri Aug 5 18:49:37 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 05 Aug 2005 14:49:37 -0400 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <20050803134507.GC18144@redhat.com> References: <20050803121112.GB18144@redhat.com> <42F0C997.5090907@redhat.com> <20050803134507.GC18144@redhat.com> Message-ID: <42F3B4C1.1040000@redhat.com> Joe Orton wrote: >On Wed, Aug 03, 2005 at 09:41:43AM -0400, Daniel J Walsh wrote: > > >>Joe Orton wrote: >> >> >>>Expected Results: I would expect the default policy to allow proxying and >>>Message is not explicit and I had to search a long time to understand.... >>> >>>Additional info: >>> >>> >>> >>> >>> >>We could allow apache to connect to apache ports by default, if that >>would satisfy this. >> >> > >No, when mod_proxy is used as a generic HTTP proxy (a not entirely >uncommon configuration) it needs to be able to connect to any remote >port on any remote address. > >joe > > Defaulting apache to can_network_connect_any=1 could allow a subverted apache web server to be setup as a spammer, or a launch site for further attacks. So I don't think this would be a good idea. -- From paul.moore at hp.com Fri Aug 5 20:29:28 2005 From: paul.moore at hp.com (Paul Moore) Date: Fri, 05 Aug 2005 16:29:28 -0400 Subject: MLS levels and the initial SID for kernel_t In-Reply-To: <42F38BC0.1080000@hp.com> References: <36282A1733C57546BE392885C0618592B51A96@chaos.tcs.tcs-sec.com> <42F38BC0.1080000@hp.com> Message-ID: <42F3CC28.5080008@hp.com> Paul Moore wrote: > Jonathan Kim wrote: > >> Paul, >> >> I recall that the problems you were having were resolved after you >> followed >> the steps I sent. >> Did you follow the exact procedure I sent you? If not, could you let >> me know the exact procedure you followed? > > > Yes, the steps you sent me a few weeks ago did work but later versions > of the policy RPM caused it to fail. Fresh install or upgrades both > resulted in failure. The reason appears to be here in > security/selinux/ss/mls.c line 521: > > if (rangetr->dom == scontext->type && > rangetr->type == tcontext->type) { > /* Set the range from the rule */ > return mls_range_set(newcontext, > &rangetr->range); > } > > For some reason the 'dom'/'type' values for the only rule in 'rangetr' > do not match with the values of 'kernel_t' and 'init_exec_t' in > 'scontext->type' and 'tcontext->type' respectively. Looking at the > range_transition types in the binary policy file, policy.19, the types > in the file appear to match the types stored in 'rangetr' which appear > to match the 'kernel_t' and 'init_exec_t' type values inside of > checkpolicy-1.25.3/policy_parse.y as returned by the following lines of > debug code I inserted: > > { > type_datum_t *kt, *it; > > kt = hashtab_search(policydbp->p_types.table, "kernel_t"); > it = hashtab_search(policydbp->p_types.table, "init_exec_t"); > > printf("PMD(#4): kernel_t=%u init_exec_t=%u\n", > kt->value, > it->value); > } > > This is where I am currently at, trying to figure out why > 'scontext->type' and 'tcontext->type' appear to change values in the > kernel ... or why I am barking up the wrong tree :) If anyone has any > suggestions I am all ears ... > I found the problem, it was in libsepol. I just posted a patch over on the SELinux Developers list. -- . paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . paul.moore at hp.com hewlett packard . (603) 884-5056 linux security From goeran at uddeborg.se Sat Aug 6 10:05:49 2005 From: goeran at uddeborg.se (=?iso-8859-1?q?G=F6ran_Uddeborg?=) Date: Sat, 6 Aug 2005 12:05:49 +0200 Subject: List of operations Message-ID: <17140.35709.767215.185526@mimmi.uddeborg.se> Maybe this is a FAQ, but I haven't found it answered in any of the FAQ:s I've looked through: Is there some kind of documentation list over the available classes and operations (permissions)? Other concepts, like types and roles are defined in the policy, with some luck together with a comment. In some cases there are even manual pages, like httpd_selinux. But the list of available classes and operations must be defined by the kernel module if I understand things correctly. I could extract a list from the flask/access_vectors file. But I would have liked something with a sentence or so of explanation. Some names may be self-explanatory, but many are not obvious. I'm imagining some kind of list like the appendices of the O'Reilley book, but updated for the current version. Does such a list exist somewhere? Or is it just in my imagination? :-) From al4in at jagua.cfg.sld.cu Sat Aug 6 21:28:24 2005 From: al4in at jagua.cfg.sld.cu (Alain Reguera Delgado) Date: Sat, 06 Aug 2005 17:28:24 -0400 Subject: Selinux Apache avc denied In-Reply-To: <42EE5043.3040302@redhat.com> References: <1122694321.3536.11.camel@humus.cfg.sld.cu> <200507300356.j6U3uemr010001@turing-police.cc.vt.edu> <1122913208.15243.104.camel@nexus.verbum.private> <42EE5043.3040302@redhat.com> Message-ID: <1123363704.4501.2.camel@humus.cfg.sld.cu> On Mon, 2005-08-01 at 12:39 -0400, Daniel J Walsh wrote: > Colin Walters wrote: > > >On Fri, 2005-07-29 at 23:56 -0400, Valdis.Kletnieks at vt.edu wrote: > > > > > >>On Fri, 29 Jul 2005 23:32:01 EDT, Alain Reguera Delgado said: > >> > >> > >> > >>>I've been stopped the web development. I feel selinux is a brilliant > >>>technology I'd like to implement in my webserver. > >>> > >>> > >>Actually, you have that almost totally backwards - SELinux is a brilliant > >>technology that gets implemented in the kernel > >> > >> > > > >One of the good things about SELinux actually is that it covers more > >than the kernel; e.g. dbus acts as a "userspace object manager" in > >concert with the kernel to secure the whole system. Similarly, there > >are patches for Xorg. I think it does make sense in some situations to > >patch the webserver. > > > > > > > >>Unfortunately, this is *much* too big a can of worms to solve directly - it > >>would be technically possible to just add a rule that says 'httpd_t can > >>exec shell_exec_t' - but that would be a *really* *bad* idea because then > >>any exploit could get a shell (and exec_no_trans only partially minimizes > >>the problem). > >> > >> > > > >I don't see a problem with execute_no_trans; it stays within the httpd_t > >security domain. > > > > > > > >>Policy Gurus: How big a hole would adding a 'can_exec(sendmail_exec_t)' or > >>'domain_auto_trans(sendmail_t)' cause? And how many of these common "web interface > >>wants to send mail" problems would it solve? > >> > >> > > > >I think policy already has this as httpd_t has the privmail attribute, > >and policy grants: > > > >./macros/program/mta_macros.te:63:domain_auto_trans(privmail, sendmail_exec_t, system_mail_t) > > > >My guess is all we need for this problem is: > >can_exec(httpd_t, shell_exec_t) > > > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > What is the settings of httpd_ssi_exec boolean? > > getsebool httpd_ssi_exec > > Looks like you need this on to make your sendmail work. > > setsebool -P httpd_ssi_exec=1 Daniel, I did what you said, and now all is ok. The application is able to send mails without problems. Thanks to all of you for the help solving the problem. > > -- > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -------------- 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 mayerf at tresys.com Mon Aug 8 12:30:43 2005 From: mayerf at tresys.com (Frank Mayer) Date: Mon, 8 Aug 2005 08:30:43 -0400 Subject: List of operations In-Reply-To: <17140.35709.767215.185526@mimmi.uddeborg.se> Message-ID: <200508081230.j78CUhss013816@gotham.columbia.tresys.com> G?ran Uddeborg wrote: > Is there some kind of documentation list over the available classes > and operations (permissions)? There's a paper on NSA's site that should help. Also we've been trying to keep exactly what you asked for at http://www.tresys.com/selinux/obj_perms_help.html. We intend to keep it up to date (it currently has a date of April), but there might be some minor changes not reflected. > I'm imagining some kind > of list like the appendices of the O'Reilley book, but updated for > the current version. Does such a list exist somewhere? Or is it > just in my imagination? :-) Several of us here (at Tresys) at trying hard to write a book on SELinux, based on large part on our policy writing course, for Addison-Wesley in our copious spare time :-) Probably won't be out until after the new year. The material on the above web site will be in an appendix. Nonetheless, we hope to keep the above site update periodically. Frank From sds at tycho.nsa.gov Mon Aug 8 13:19:20 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 08 Aug 2005 09:19:20 -0400 Subject: List of operations In-Reply-To: <200508081230.j78CUhss013816@gotham.columbia.tresys.com> References: <200508081230.j78CUhss013816@gotham.columbia.tresys.com> Message-ID: <1123507160.13654.151.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-08-08 at 08:30 -0400, Frank Mayer wrote: > G?ran Uddeborg wrote: > > Is there some kind of documentation list over the available classes > > and operations (permissions)? > > There's a paper on NSA's site that should help. Also we've been trying to > keep exactly what you asked for at > http://www.tresys.com/selinux/obj_perms_help.html. We intend to keep it up > to date (it currently has a date of April), but there might be some minor > changes not reflected. The original set of classes and permissions were described in the report available from http://www.nsa.gov/selinux/papers/slinux-abs.cfm That report described the classes and permissions and what permission checks were applied for each syscall (the control requirements) for the original SELinux kernel patch. A subsequent report on the LSM-based SELinux available from http://www.nsa.gov/selinux/papers/module-abs.cfm describes changes from the original SELinux kernel patch and what permission checks are applied for each LSM hook function. We have been periodically updating that report, and its sources are included in the selinux-doc tarball. -- Stephen Smalley National Security Agency From iocc at fedora-selinux.lists.flashdance.cx Sun Aug 7 00:59:40 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Sun, 7 Aug 2005 02:59:40 +0200 (CEST) Subject: cant create dirs from vsftpd Message-ID: selinux-policy-targeted-1.25.3-9 in FC4 surely isnt perfect. Cant create dirs when I login over ftp: type=CWD msg=audit(1123375603.524:11258814): cwd="/home/iocc" type=PATH msg=audit(1123375603.524:11258814): item=0 name="mp3" flags=10 inode=5046274 dev=03:01 mode=040755 ouid=636 ogid=636 rdev=00:00 type=AVC msg=audit(1123375603.539:11258878): avc: denied { getattr } for pid=10556 comm="vsftpd" name="/" dev=0:10 ino=49161 scontext=root:system_r:ftpd_t tcontext=system_u:object_r:nfs_t tclass=dir type=SYSCALL msg=audit(1123375603.539:11258878): arch=40000003 syscall=196 success=no exit=-13 a0=9527930 a1=9523328 a2=3a3ff4 a3=797eec items=1 pid=10556 auid=636 uid=636 gid=636 euid=636 suid=636 fsuid=636 egid=636 sgid=636 fsgid=636 comm="vsftpd" exe="/usr/sbin/vsftpd" Cant find what I should turn off in /etc/selinux/targeted/booleans to make it work. So I need a little help. Later, I want to upload files in that dir also. Also, Im not so sure that I like that I cant see alot of dirs when Im logged in at the ftp. From paul at city-fan.org Mon Aug 8 14:43:56 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 08 Aug 2005 15:43:56 +0100 Subject: cant create dirs from vsftpd In-Reply-To: References: Message-ID: <42F76FAC.5030805@city-fan.org> Peter Magnusson wrote: > selinux-policy-targeted-1.25.3-9 in FC4 surely isnt perfect. Cant create > dirs when I login over ftp: > > type=CWD msg=audit(1123375603.524:11258814): cwd="/home/iocc" > type=PATH msg=audit(1123375603.524:11258814): item=0 name="mp3" flags=10 > inode=5046274 dev=03:01 mode=040755 ouid=636 ogid=636 rdev=00:00 > type=AVC msg=audit(1123375603.539:11258878): avc: denied { getattr } > for pid=10556 comm="vsftpd" name="/" dev=0:10 ino=49161 > scontext=root:system_r:ftpd_t tcontext=system_u:object_r:nfs_t tclass=dir > type=SYSCALL msg=audit(1123375603.539:11258878): arch=40000003 > syscall=196 success=no exit=-13 a0=9527930 a1=9523328 a2=3a3ff4 > a3=797eec items=1 pid=10556 auid=636 uid=636 gid=636 euid=636 suid=636 > fsuid=636 egid=636 sgid=636 fsgid=636 comm="vsftpd" exe="/usr/sbin/vsftpd" > > Cant find what I should turn off in /etc/selinux/targeted/booleans to > make it work. So I need a little help. Later, I want to upload files in > that dir also. > > Also, Im not so sure that I like that I cant see alot of dirs when Im > logged in at the ftp. Did you read "man ftpd_selinux"? I'd suggest: # setsebool -P ftp_home_dir 1 If your ftp server is running as a daemon rather than from inetd you'll also need: # setsebool -P ftpd_is_daemon 1 As you appear to have an NFS-mounted home directory, I'd also suggest (from "man nfs_selinux"): # setsebool -P use_nfs_home_dirs 1 Paul. From jorton at redhat.com Mon Aug 8 15:40:42 2005 From: jorton at redhat.com (Joe Orton) Date: Mon, 8 Aug 2005 16:40:42 +0100 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <42F3B4C1.1040000@redhat.com> References: <20050803121112.GB18144@redhat.com> <42F0C997.5090907@redhat.com> <20050803134507.GC18144@redhat.com> <42F3B4C1.1040000@redhat.com> Message-ID: <20050808154042.GA22758@redhat.com> On Fri, Aug 05, 2005 at 02:49:37PM -0400, Daniel J Walsh wrote: > Joe Orton wrote: > >No, when mod_proxy is used as a generic HTTP proxy (a not entirely > >uncommon configuration) it needs to be able to connect to any remote > >port on any remote address. > > > > > Defaulting apache to can_network_connect_any=1 could allow a subverted > apache web server to be setup as a spammer, or a launch site for further > attacks. So I don't think this would be a good idea. Currently the following is known to be broken in the default configuration: 1) web applications which connect to remote {my,postgre}SQL databases (and similarly, I guess, the Apache SQL-based-authentication modules) 2) all mod_proxy configurations (reverse proxy, forward proxy) 3) the parent connect()-to-listening-port "reap idle children" interface, which has the impact: a) one log message written to error_log per second when the server acquiesces after a period of above-normal load and tries to reap idle children b) graceful restart does not work properly The above all represent important functionality. I'm not convinced that the security vs usability tradeoff is being won in favour of enabling the boolean by default. Regards, joe From craig.burrell at gmail.com Mon Aug 8 16:12:26 2005 From: craig.burrell at gmail.com (Craig Burrell) Date: Mon, 8 Aug 2005 12:12:26 -0400 Subject: Getting started with Fedora SE Linux Message-ID: Hello, all. I have recently installed Fedora Core 3 and begun exploring the SE Linux security model. I have a number of questions, but perhaps I'll begin with something simple. I have been reading Bill McCarty's book on SE Linux (O'Reilly), which is written for Fedora Core 2. He makes frequent reference to files (*.fc and *.te files, for instance) in the source directory (/etc/security/selinux/src/). In my installation, however, I don't have that directory, nor can I find elsewhere on my system any of the files to which he refers. Have I made an error in my installation, or is Fedora Core 3 that different from Core 2? Where in my installation are the security policy source files to be kept? Thanks for your help, Craig Burrell From paul at city-fan.org Mon Aug 8 16:19:38 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 08 Aug 2005 17:19:38 +0100 Subject: Getting started with Fedora SE Linux In-Reply-To: References: Message-ID: <42F7861A.3020504@city-fan.org> Craig Burrell wrote: > Hello, all. > > I have recently installed Fedora Core 3 and begun exploring the SE > Linux security model. I have a number of questions, but perhaps I'll > begin with something simple. > > I have been reading Bill McCarty's book on SE Linux (O'Reilly), which > is written for Fedora Core 2. He makes frequent reference to files > (*.fc and *.te files, for instance) in the source directory > (/etc/security/selinux/src/). In my installation, however, I don't > have that directory, nor can I find elsewhere on my system any of the > files to which he refers. > > Have I made an error in my installation, or is Fedora Core 3 that > different from Core 2? Where in my installation are the security > policy source files to be kept? Install the packages selinux-policy-targeted-sources and/or selinux-policy-strict-sources The sources will then be in directories: /etc/selinux/targeted/src /etc/selinux/strict/src The "targeted" policy is the default policy in FC3 and FC4. Paul. From sds at tycho.nsa.gov Mon Aug 8 16:43:47 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 08 Aug 2005 12:43:47 -0400 Subject: Getting started with Fedora SE Linux In-Reply-To: References: Message-ID: <1123519427.13654.260.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-08-08 at 12:12 -0400, Craig Burrell wrote: > Hello, all. > > I have recently installed Fedora Core 3 and begun exploring the SE > Linux security model. I have a number of questions, but perhaps I'll > begin with something simple. > > I have been reading Bill McCarty's book on SE Linux (O'Reilly), which > is written for Fedora Core 2. He makes frequent reference to files > (*.fc and *.te files, for instance) in the source directory > (/etc/security/selinux/src/). In my installation, however, I don't > have that directory, nor can I find elsewhere on my system any of the > files to which he refers. > > Have I made an error in my installation, or is Fedora Core 3 that > different from Core 2? Where in my installation are the security > policy source files to be kept? > > Thanks for your help, - You have to install the policy sources package (selinux-policy-targeted-sources or selinux-policy-strict-sources) explicitly; by default, only the binary policy is installed. - Policy and the config file have moved under /etc/selinux, with separate subtrees for each kind of policy, e.g. /etc/selinux/targeted, /etc/selinux/strict. The /etc/selinux/config file specifies the active policy via the SELINUXTYPE definition. - FC3 introduced the targeted policy and made it the default, enabling SELinux to be enabled by default in FC3 and later. See the FC3 release notes and the FC3 SELinux FAQ. Strict policy is still available, but you have to explicitly install it and switch to it if you want to use it, and it isn't as well supported (you essentially need to track rawhide if you want updates to it). - Note that FC4 was released in June, so you might want to consider upgrading or re-installing to be more current. -- Stephen Smalley National Security Agency From ejtr at layer3.co.uk Mon Aug 8 17:42:37 2005 From: ejtr at layer3.co.uk (Ted Rule) Date: Mon, 08 Aug 2005 18:42:37 +0100 Subject: vsftpd non-anonymous chrooting Message-ID: <1123522957.5442.60.camel@topaz.bugfinder.co.uk> Whilst using vsftpd in chroot'ed mode for non-anonymous usage, I've found that I appear to have to add this to my SELinux strict policy: allow ftpd_t self:capability { dac_override dac_read_search }; or possibly just this: allow ftpd_t self:capability { dac_read_search }; Without at least the dac_read_search, an ftp login always seems to fail. The description of these "dac" permissions on Tresys' site suggests to me that vsftpd is being too "greedy" in requiring these permissions to chroot successfully. Since anonymous ftp with SELinux surely works Ok without this capability, (or too many other people would have complained ), does this mean that the correct fix for this is a minor rewrite to vsftpd, rather than a change in SELinux policy? My current ftpd/SELinux/chroot related configuration: $ sudo grep ftp /etc/selinux/strict/booleans ftpd_is_daemon=1 ftp_home_dir=1 $ $ sudo grep chroot /etc/vsftpd/vsftpd.conf | grep -v "^#" chroot_list_enable=YES passwd_chroot_enable=YES chroot_list_file=/etc/vsftpd/vsftpd.chroot_user_list userlist_file=/etc/vsftpd/vsftpd.chroot_user_list $ -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From fedora at grifent.com Tue Aug 9 14:35:54 2005 From: fedora at grifent.com (John Griffiths) Date: Tue, 09 Aug 2005 10:35:54 -0400 Subject: fedora-selinux-list Digest, Vol 18, Issue 9 In-Reply-To: <20050808160017.0E52D737B3@hormel.redhat.com> References: <20050808160017.0E52D737B3@hormel.redhat.com> Message-ID: <42F8BF4A.2020003@grifent.com> An HTML attachment was scrubbed... URL: From jorton at redhat.com Tue Aug 9 15:36:42 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 9 Aug 2005 16:36:42 +0100 Subject: fedora-selinux-list Digest, Vol 18, Issue 9 In-Reply-To: <42F8BF4A.2020003@grifent.com> References: <20050808160017.0E52D737B3@hormel.redhat.com> <42F8BF4A.2020003@grifent.com> Message-ID: <20050809153642.GA16633@redhat.com> On Tue, Aug 09, 2005 at 10:35:54AM -0400, John Griffiths wrote: > Joe Orton wrote: > The above all represent important functionality. > > > Agreed. > > I'm not convinced that the security vs usability tradeoff is being won > in favour of enabling the boolean by default. > > > I don't quite understand this sentence. Are you saying the boolean should > be enabled by default? We certainly need the functionality. When security > gets in the way of getting the job done, then we have lost the war. Sorry, I inverted the logic! I'm arguing that the httpd_can_network_connect boolean should be enabled by default, yes. joe From fedora at grifent.com Tue Aug 9 18:48:59 2005 From: fedora at grifent.com (John Griffiths) Date: Tue, 09 Aug 2005 14:48:59 -0400 Subject: httpd_can_network_connect In-Reply-To: <20050809160017.AE5F073A3F@hormel.redhat.com> References: <20050809160017.AE5F073A3F@hormel.redhat.com> Message-ID: <42F8FA9B.5090505@grifent.com> An HTML attachment was scrubbed... URL: From james.zheng.li at gmail.com Tue Aug 9 21:22:15 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Tue, 9 Aug 2005 17:22:15 -0400 Subject: Questions about /net and /proc Message-ID: <8a239a5605080914226519ed08@mail.gmail.com> Hi all, I have several root shell scripts which need create directories under /net or /proc. They are running well under Fedora Core 2. After I upgrate to FC4 with targeted SELinux policy, those scripts are not running under either enforcing or permissive mode. Error messages like Unable to create directories under /net or /proc. I used "ls -Z" to check security contexts for /net and /proc, they both have empty security labels. As a root (root:system_r:unconfined_t), I cannot manually create anything under those two directories. What should I do in order to make /net and /proc writtable? Thanks, James From tmerritt at email.arizona.edu Wed Aug 10 14:50:48 2005 From: tmerritt at email.arizona.edu (Todd Merritt) Date: Wed, 10 Aug 2005 07:50:48 -0700 Subject: ... is not a valid context Message-ID: <1123685448.8508.84.camel@hive.ccit.arizona.edu> I'm having trouble adding a new role to selinux on FC4. I added the following lines to domains/user.te: limited_user_role(ua_pw_user) role_tty_type_change(user, ua_pw_user) role_tty_type_change(sysadm, ua_pw_user) and to macros/user_macros.te added role ua_pw_user_r types $1; to in_user_role. and to appconfig/default_type: ua_pw_user_r:ua_pw_user_t and to users: user tmerritt roles { user_r ua_pw_user_r }; Now when I try to switch to that role I get: [tmerritt at host ~]$ id -Z tmerritt:user_r:user_t [tmerritt at host ~]$ newrole -r ua_pw_user_r Authenticating tmerritt. Password: tmerritt:ua_pw_user_r:ua_pw_user_t is not a valid context Am I missing something obvious ? Thanks, Todd From Valdis.Kletnieks at vt.edu Wed Aug 10 15:02:55 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 10 Aug 2005 11:02:55 -0400 Subject: ... is not a valid context In-Reply-To: Your message of "Wed, 10 Aug 2005 07:50:48 PDT." <1123685448.8508.84.camel@hive.ccit.arizona.edu> References: <1123685448.8508.84.camel@hive.ccit.arizona.edu> Message-ID: <200508101502.j7AF2tXh015828@turing-police.cc.vt.edu> On Wed, 10 Aug 2005 07:50:48 PDT, Todd Merritt said: > limited_user_role(ua_pw_user) > [tmerritt at host ~]$ newrole -r ua_pw_user_r > Authenticating tmerritt. > Password: > tmerritt:ua_pw_user_r:ua_pw_user_t is not a valid context > > > Am I missing something obvious ? Umm... reloading the policy? I've been bitten by *that* one a few times..... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From tmerritt at email.arizona.edu Wed Aug 10 15:47:11 2005 From: tmerritt at email.arizona.edu (Todd Merritt) Date: Wed, 10 Aug 2005 08:47:11 -0700 Subject: ... is not a valid context In-Reply-To: <200508101502.j7AF2tXh015828@turing-police.cc.vt.edu> References: <1123685448.8508.84.camel@hive.ccit.arizona.edu> <200508101502.j7AF2tXh015828@turing-police.cc.vt.edu> Message-ID: <1123688832.8508.91.camel@hive.ccit.arizona.edu> [root at tubb policy]# make load make: Nothing to be done for `load'. On Wed, 2005-08-10 at 11:02 -0400, Valdis.Kletnieks at vt.edu wrote: > On Wed, 10 Aug 2005 07:50:48 PDT, Todd Merritt said: > > > limited_user_role(ua_pw_user) > > > [tmerritt at host ~]$ newrole -r ua_pw_user_r > > Authenticating tmerritt. > > Password: > > tmerritt:ua_pw_user_r:ua_pw_user_t is not a valid context > > > > > > Am I missing something obvious ? > > Umm... reloading the policy? I've been bitten by *that* one a few times..... From sds at tycho.nsa.gov Wed Aug 10 15:57:59 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 10 Aug 2005 11:57:59 -0400 Subject: ... is not a valid context In-Reply-To: <1123685448.8508.84.camel@hive.ccit.arizona.edu> References: <1123685448.8508.84.camel@hive.ccit.arizona.edu> Message-ID: <1123689479.3018.74.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-08-10 at 07:50 -0700, Todd Merritt wrote: > I'm having trouble adding a new role to selinux on FC4. I added the > following lines to domains/user.te: > > limited_user_role(ua_pw_user) > > role_tty_type_change(user, ua_pw_user) > role_tty_type_change(sysadm, ua_pw_user) > > > and to macros/user_macros.te added > > role ua_pw_user_r types $1; > > to in_user_role. > > and to appconfig/default_type: > ua_pw_user_r:ua_pw_user_t > > and to users: > user tmerritt roles { user_r ua_pw_user_r }; > > Now when I try to switch to that role I get: > > [tmerritt at host ~]$ id -Z > tmerritt:user_r:user_t > [tmerritt at host ~]$ newrole -r ua_pw_user_r > Authenticating tmerritt. > Password: > tmerritt:ua_pw_user_r:ua_pw_user_t is not a valid context > > > Am I missing something obvious ? Doesn't look like limited_user_role() adds a: role $1_r types $1_t; statement to authorize the role for the type. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Aug 10 16:05:47 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 10 Aug 2005 12:05:47 -0400 Subject: ... is not a valid context In-Reply-To: <1123689479.3018.74.camel@moss-spartans.epoch.ncsc.mil> References: <1123685448.8508.84.camel@hive.ccit.arizona.edu> <1123689479.3018.74.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1123689947.3018.77.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-08-10 at 11:57 -0400, Stephen Smalley wrote: > Doesn't look like limited_user_role() adds a: > role $1_r types $1_t; > statement to authorize the role for the type. Looks like the corresponding statement for full_user_role() is pushed all the way down to user_domain(). Likely should be brought up to limited_user_role() and thereby included in both limited_user_role() and full_user_role() at that level. -- Stephen Smalley National Security Agency From tmerritt at email.arizona.edu Wed Aug 10 16:26:05 2005 From: tmerritt at email.arizona.edu (Todd Merritt) Date: Wed, 10 Aug 2005 09:26:05 -0700 Subject: ... is not a valid context In-Reply-To: <1123689947.3018.77.camel@moss-spartans.epoch.ncsc.mil> References: <1123685448.8508.84.camel@hive.ccit.arizona.edu> <1123689479.3018.74.camel@moss-spartans.epoch.ncsc.mil> <1123689947.3018.77.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1123691165.8508.107.camel@hive.ccit.arizona.edu> On Wed, 2005-08-10 at 12:05 -0400, Stephen Smalley wrote: > On Wed, 2005-08-10 at 11:57 -0400, Stephen Smalley wrote: > > Doesn't look like limited_user_role() adds a: > > role $1_r types $1_t; > > statement to authorize the role for the type. > > Looks like the corresponding statement for full_user_role() is pushed > all the way down to user_domain(). Likely should be brought up to > limited_user_role() and thereby included in both limited_user_role() and > full_user_role() at that level. > It's getting in there from somewhere: [root at tubb policy]# grep allow policy.conf |grep ua_pw_user_r allow user_r ua_pw_user_r; allow sysadm_r ua_pw_user_r; But, after switching it to full_user role allow system_r ua_pw_user_r; is added to the policy and everything works. Thanks, Todd From sds at tycho.nsa.gov Wed Aug 10 16:30:49 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 10 Aug 2005 12:30:49 -0400 Subject: ... is not a valid context In-Reply-To: <1123691165.8508.107.camel@hive.ccit.arizona.edu> References: <1123685448.8508.84.camel@hive.ccit.arizona.edu> <1123689479.3018.74.camel@moss-spartans.epoch.ncsc.mil> <1123689947.3018.77.camel@moss-spartans.epoch.ncsc.mil> <1123691165.8508.107.camel@hive.ccit.arizona.edu> Message-ID: <1123691449.3018.100.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-08-10 at 09:26 -0700, Todd Merritt wrote: > It's getting in there from somewhere: > > [root at tubb policy]# grep allow policy.conf |grep ua_pw_user_r > allow user_r ua_pw_user_r; > allow sysadm_r ua_pw_user_r; > > But, after switching it to full_user role > > allow system_r ua_pw_user_r; > > is added to the policy and everything works. The issue isn't the allow rule - it is the missing role statement, i.e. role ua_pw_user_r types ua_pw_user_t; -- Stephen Smalley National Security Agency From tmerritt at email.arizona.edu Wed Aug 10 16:34:31 2005 From: tmerritt at email.arizona.edu (Todd Merritt) Date: Wed, 10 Aug 2005 09:34:31 -0700 Subject: ... is not a valid context In-Reply-To: <1123691449.3018.100.camel@moss-spartans.epoch.ncsc.mil> References: <1123685448.8508.84.camel@hive.ccit.arizona.edu> <1123689479.3018.74.camel@moss-spartans.epoch.ncsc.mil> <1123689947.3018.77.camel@moss-spartans.epoch.ncsc.mil> <1123691165.8508.107.camel@hive.ccit.arizona.edu> <1123691449.3018.100.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1123691671.8508.110.camel@hive.ccit.arizona.edu> On Wed, 2005-08-10 at 12:30 -0400, Stephen Smalley wrote: > On Wed, 2005-08-10 at 09:26 -0700, Todd Merritt wrote: > > It's getting in there from somewhere: > > > > [root at tubb policy]# grep allow policy.conf |grep ua_pw_user_r > > allow user_r ua_pw_user_r; > > allow sysadm_r ua_pw_user_r; > > > > But, after switching it to full_user role > > > > allow system_r ua_pw_user_r; > > > > is added to the policy and everything works. > > The issue isn't the allow rule - it is the missing role statement, i.e. > role ua_pw_user_r types ua_pw_user_t; > I realized that after I fired off the message, sorry about that. From jorton at redhat.com Wed Aug 10 20:21:48 2005 From: jorton at redhat.com (Joe Orton) Date: Wed, 10 Aug 2005 21:21:48 +0100 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <20050808154042.GA22758@redhat.com> References: <20050803121112.GB18144@redhat.com> <42F0C997.5090907@redhat.com> <20050803134507.GC18144@redhat.com> <42F3B4C1.1040000@redhat.com> <20050808154042.GA22758@redhat.com> Message-ID: <20050810202148.GA28397@redhat.com> On Mon, Aug 08, 2005 at 04:40:42PM +0100, Joe Orton wrote: > On Fri, Aug 05, 2005 at 02:49:37PM -0400, Daniel J Walsh wrote: > > Joe Orton wrote: > > >No, when mod_proxy is used as a generic HTTP proxy (a not entirely > > >uncommon configuration) it needs to be able to connect to any remote > > >port on any remote address. > > > > > > > > Defaulting apache to can_network_connect_any=1 could allow a subverted > > apache web server to be setup as a spammer, or a launch site for further > > attacks. So I don't think this would be a good idea. > > Currently the following is known to be broken in the default > configuration: Another one, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165592 4) web applications which connect to remote LDAP databases, and similarly, I guess, the Apache LDAP-based authentication module, if configured to use remote LDAP databases. From roger at gwch.net Thu Aug 11 10:07:48 2005 From: roger at gwch.net (Roger Grosswiler) Date: Thu, 11 Aug 2005 12:07:48 +0200 (CEST) Subject: update from fc3 -> fc4: cyrus/sasl-errors In-Reply-To: <20050801014302.K17051@surf.gcrc.upenn.edu> References: <42ECD098.7020406@gwch.net> <1122873683.2613.1.camel@chaucer> <20050801014302.K17051@surf.gcrc.upenn.edu> Message-ID: <12175.62.2.21.164.1123754868.squirrel@www.gwch.net> > It's a problem with the policy not with a relabel. > > audit2allow > > will give you a policy statement to work with... > > > HTH, > Harry > > > > On Sun, 31 Jul 2005, Bobby Kashani wrote: > >> On Sun, 2005-07-31 at 15:22 +0200, Roger Grosswiler wrote: >> > hi, >> > >> > i recently updated from fc3 to fc4. i use this machine as a mailserver >> > with cyrus. 1st problem was the database - fixed issue. now, on >> > authentication, i get errors, will say, with selinux enforcing i >> cannot >> > authenticate at all. >> > >> > from the fc-list i got some help, with a few commands, that should >> help >> > better understanding. What can i do, to have this box with selinux >> > enforcing enabled? ah, yes, in permissive mode it works fine. >> >> Have you tried doing a "touch /.autorelabel" and rebooting? >> >> Bob >> >> > here a sniplet of my logs: >> > > [root at link ~]# ausearch -i -a 9657218 >> > > ---- >> > > type=PATH msg=audit(07/30/05 16:21:20.281:9657218) : item=0 >> flags=follow inode=262199 dev=fd:00 mode=dir,755 ouid=root ogid=root >> rdev=00:00 >> > > type=SOCKETCALL msg=audit(07/30/05 16:21:20.281:9657218) : nargs=3 >> a0=b a1=bfd308fa a2=6e >> > > type=SOCKADDR msg=audit(07/30/05 16:21:20.281:9657218) : saddr=local >> /var/run/saslauthd/mux >> > > type=SYSCALL msg=audit(07/30/05 16:21:20.281:9657218) : arch=i386 >> syscall=socketcall(connect) success=no exit=-13(Permission denied) >> a0=3 a1=bfd2e4b0 a2=dd0228 a3=bfd2e513 items=1 pid=28898 auid=root >> uid=cyrus gid=mail euid=cyrus suid=cyrus fsuid=cyrus egid=mail >> sgid=mail fsgid=mail comm=imapd exe=/usr/lib/cyrus-imapd/imapd >> > > type=AVC msg=audit(07/30/05 16:21:20.281:9657218) : avc: denied { >> search } for pid=28898 comm=imapd name=saslauthd dev=dm-0 >> ino=262199 scontext=root:system_r:cyrus_t >> tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir >> > > >> > >> ausearch -i -a 9659874 >> > >> >> > >> >> > > [root at link ~]# ausearch -i -a 9659874 >> > > ---- >> > > type=PATH msg=audit(07/30/05 16:21:24.635:9659874) : item=0 >> flags=follow inode=262199 dev=fd:00 mode=dir,755 ouid=root ogid=root >> rdev=00:00 >> > > type=SOCKETCALL msg=audit(07/30/05 16:21:24.635:9659874) : nargs=3 >> a0=b a1=bfd308fa a2=6e >> > > type=SOCKADDR msg=audit(07/30/05 16:21:24.635:9659874) : saddr=local >> /var/run/saslauthd/mux >> > > type=SYSCALL msg=audit(07/30/05 16:21:24.635:9659874) : arch=i386 >> syscall=socketcall(connect) success=no exit=-13(Permission denied) >> a0=3 a1=bfd2e4b0 a2=dd0228 a3=bfd2e513 items=1 pid=28898 auid=root >> uid=cyrus gid=mail euid=cyrus suid=cyrus fsuid=cyrus egid=mail >> sgid=mail fsgid=mail comm=imapd exe=/usr/lib/cyrus-imapd/imapd >> > > type=AVC msg=audit(07/30/05 16:21:24.635:9659874) : avc: denied { >> search } for pid=28898 comm=imapd name=saslauthd dev=dm-0 >> ino=262199 scontext=root:system_r:cyrus_t >> tcontext=system_u:object_r:saslauthd_var_run_t tclass=dir >> > >> > >> > i hope, you can help. >> > >> > Thanks a lot >> > Roger >> > >> > >> > -- >> > fedora-selinux-list mailing list >> > fedora-selinux-list at redhat.com >> > http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> -- >> Bobby Kashani >> http://www.ocf.berkeley.edu/~bobk/garnome >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > Hi, i am completely unexperienced in selinux, but i was trying changing the policy local.te and added the following: allow saslauthd_t initrc_t:unix_stream_socket connectto; allow saslauthd_t mysqld_db_t:dir search; allow saslauthd_t mysqld_var_run_t:sock_file write; allow saslauthd_t var_lib_t:dir search; ...since then, it is working. My imap authenticates agains sasl which uses mysql for user-authentication (pam_mysql.so) can any expert say, if i openend a hole in my security other than authentication? Thanks roger From roger at gwch.net Fri Aug 12 06:04:52 2005 From: roger at gwch.net (Roger Grosswiler) Date: Fri, 12 Aug 2005 08:04:52 +0200 Subject: Vsftpd in a chrooted environement Message-ID: <42FC3C04.8020801@gwch.net> Hi, i run vsftpd in a chrooted environement. Since yesterday, again in targeted mode. Loggin in, gives a 500 OOPS - Message according to audit.log, the following is missing: type=AVC msg=audit(1123825815.048:14086489): avc: denied { dac_override } for pid=21576 comm="vsftpd" capability=1 scontext=system_u:system_r:ftpd_t tcontext=system_u:system_r:ftpd_t tclass=capability i inserted in local.te the following (according to audit2allow) allow ftpd_t self:capability { dac_override dac_read_search }; ...and now it works. Can anybody check this for other securiy holes? Or did i just do an error in my config now? using the ftpd_home...-boolean, this did not help, nor did ftpd_disable_trans=1 (what was not my wish) Thanks for your reply Roger From dwalsh at redhat.com Mon Aug 15 15:21:51 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 15 Aug 2005 11:21:51 -0400 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <20050810202148.GA28397@redhat.com> References: <20050803121112.GB18144@redhat.com> <42F0C997.5090907@redhat.com> <20050803134507.GC18144@redhat.com> <42F3B4C1.1040000@redhat.com> <20050808154042.GA22758@redhat.com> <20050810202148.GA28397@redhat.com> Message-ID: <4300B30F.9010704@redhat.com> Joe Orton wrote: >On Mon, Aug 08, 2005 at 04:40:42PM +0100, Joe Orton wrote: > > >>On Fri, Aug 05, 2005 at 02:49:37PM -0400, Daniel J Walsh wrote: >> >> >>>Joe Orton wrote: >>> >>> >>>>No, when mod_proxy is used as a generic HTTP proxy (a not entirely >>>>uncommon configuration) it needs to be able to connect to any remote >>>>port on any remote address. >>>> >>>> >>>> >>>> >>>Defaulting apache to can_network_connect_any=1 could allow a subverted >>>apache web server to be setup as a spammer, or a launch site for further >>>attacks. So I don't think this would be a good idea. >>> >>> >>Currently the following is known to be broken in the default >>configuration: >> >> > >Another one, https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165592 > >4) web applications which connect to remote LDAP databases, and >similarly, I guess, the Apache LDAP-based authentication module, if >configured to use remote LDAP databases. > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Latest policy has can_ldap(httpd_t) which should allow httpd scripts to connect to the ldap port. Could I give a similar connect to mysql to solve your problem? -- From jorton at redhat.com Mon Aug 15 15:28:04 2005 From: jorton at redhat.com (Joe Orton) Date: Mon, 15 Aug 2005 16:28:04 +0100 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <4300B30F.9010704@redhat.com> References: <20050803121112.GB18144@redhat.com> <42F0C997.5090907@redhat.com> <20050803134507.GC18144@redhat.com> <42F3B4C1.1040000@redhat.com> <20050808154042.GA22758@redhat.com> <20050810202148.GA28397@redhat.com> <4300B30F.9010704@redhat.com> Message-ID: <20050815152804.GA30450@redhat.com> On Mon, Aug 15, 2005 at 11:21:51AM -0400, Daniel J Walsh wrote: > Latest policy has > > can_ldap(httpd_t) which should allow httpd scripts to connect to the > ldap port. Could I give a similar connect to mysql to solve your problem? That won't fix (2) or (3), either of which alone would be sufficient justification to enable the boolean by default: reminder for 2 and 3: 2) all mod_proxy configurations (reverse proxy, forward proxy) 3) the parent connect()-to-listening-port "reap idle children" interface, which has the impact: joe From dwalsh at redhat.com Mon Aug 15 15:30:27 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 15 Aug 2005 11:30:27 -0400 Subject: fedora-selinux-list Digest, Vol 18, Issue 9 In-Reply-To: <20050809153642.GA16633@redhat.com> References: <20050808160017.0E52D737B3@hormel.redhat.com> <42F8BF4A.2020003@grifent.com> <20050809153642.GA16633@redhat.com> Message-ID: <4300B513.4060101@redhat.com> Joe Orton wrote: >On Tue, Aug 09, 2005 at 10:35:54AM -0400, John Griffiths wrote: > > >> Joe Orton wrote: >> The above all represent important functionality. >> >> >> Agreed. >> >> I'm not convinced that the security vs usability tradeoff is being won >> in favour of enabling the boolean by default. >> >> >> I don't quite understand this sentence. Are you saying the boolean should >> be enabled by default? We certainly need the functionality. When security >> gets in the way of getting the job done, then we have lost the war. >> >> > >Sorry, I inverted the logic! I'm arguing that the >httpd_can_network_connect boolean should be enabled by default, yes. > >joe > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > How about I add # allow httpd to connect to mysql/posgresql databases allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; can_ldap(httpd_t) By default and leave the boolean off? Dan -- From dwalsh at redhat.com Mon Aug 15 15:34:27 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 15 Aug 2005 11:34:27 -0400 Subject: Questions about /net and /proc In-Reply-To: <8a239a5605080914226519ed08@mail.gmail.com> References: <8a239a5605080914226519ed08@mail.gmail.com> Message-ID: <4300B603.7040205@redhat.com> James Z. Li wrote: >Hi all, > >I have several root shell scripts which need create directories >under /net or /proc. They are running well under Fedora Core 2. >After I upgrate to FC4 with targeted SELinux policy, those >scripts are not running under either enforcing or permissive mode. >Error messages like Unable to create directories under /net or /proc. >I used "ls -Z" to check security contexts for /net and /proc, >they both have empty security labels. >As a root (root:system_r:unconfined_t), I cannot manually create >anything under those two directories. > >What should I do in order to make /net and /proc writtable? > >Thanks, > >James > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > Could you supply the avc messages from /var/log/audit/audit.log or /var/log/messages. -- From dwalsh at redhat.com Mon Aug 15 15:59:52 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 15 Aug 2005 11:59:52 -0400 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <20050815152804.GA30450@redhat.com> References: <20050803121112.GB18144@redhat.com> <42F0C997.5090907@redhat.com> <20050803134507.GC18144@redhat.com> <42F3B4C1.1040000@redhat.com> <20050808154042.GA22758@redhat.com> <20050810202148.GA28397@redhat.com> <4300B30F.9010704@redhat.com> <20050815152804.GA30450@redhat.com> Message-ID: <4300BBF8.8050104@redhat.com> Joe Orton wrote: >On Mon, Aug 15, 2005 at 11:21:51AM -0400, Daniel J Walsh wrote: > > >>Latest policy has >> >>can_ldap(httpd_t) which should allow httpd scripts to connect to the >>ldap port. Could I give a similar connect to mysql to solve your problem? >> >> > >That won't fix (2) or (3), either of which alone would be sufficient >justification to enable the boolean by default: > >reminder for 2 and 3: > >2) all mod_proxy configurations (reverse proxy, forward proxy) > >3) the parent connect()-to-listening-port "reap idle children" >interface, which has the impact: > >joe > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > How about... ######################################## # Set up networking ######################################## can_network(httpd_t) can_kerberos(httpd_t) can_resolve(httpd_t) can_ypbind(httpd_t) can_ldap(httpd_t) allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind; # allow httpd to connect to mysql/posgresql allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; # allow httpd to work as a relay allow httpd_t { gopher_port_t ftp_port_t http_port_t http_cache_port_t }:tcp_socket name_connect; -- From james.zheng.li at gmail.com Mon Aug 15 21:25:27 2005 From: james.zheng.li at gmail.com (James Z. Li) Date: Mon, 15 Aug 2005 17:25:27 -0400 Subject: Questions about /net and /proc In-Reply-To: <4300B603.7040205@redhat.com> References: <8a239a5605080914226519ed08@mail.gmail.com> <4300B603.7040205@redhat.com> Message-ID: <8a239a5605081514256fcd87f5@mail.gmail.com> In the shell script, namely redhat-install.sh ... REDHAT_AREA=/net/redhat; SERVER=abc.foo.edu; if [ ! -d ${REDHAT_AREA}/bin ]; then mkdir -p ${REDHAT_AREA}/bin; fi echo "Copying some files from server" scp -r ${SERVER}:${REDHAT_AREA}/bin/ ${REDHAT_AREA} ... I labeled the redhat-install.sh script as file_t and shell_exec_t, but they both did not work. There is no security context for /net and /net is empty on my machine, so when I run this script, the error messages are: mkdir: cannot create directory `/net/redhat': Permission denied Copying some files from server /net/redhat: Permission denied There is no AVC messages in either /var/log/messages or /var/log/audit/audit.log. There are these lines in /var/log/messages: Aug 15 16:51:17 ko automount[3254]: >> /usr/sbin/showmount: can't get address for redhat Aug 15 16:51:17 ko automount[3254]: lookup(program): lookup for redhat failed Aug 15 16:51:17 ko automount[3254]: failed to mount /net/redhat Thanks a lot, James On 8/15/05, Daniel J Walsh wrote: > James Z. Li wrote: > > >Hi all, > > > >I have several root shell scripts which need create directories > >under /net or /proc. They are running well under Fedora Core 2. > >After I upgrate to FC4 with targeted SELinux policy, those > >scripts are not running under either enforcing or permissive mode. > >Error messages like Unable to create directories under /net or /proc. > >I used "ls -Z" to check security contexts for /net and /proc, > >they both have empty security labels. > >As a root (root:system_r:unconfined_t), I cannot manually create > >anything under those two directories. > > > >What should I do in order to make /net and /proc writtable? > > > >Thanks, > > > >James > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > Could you supply the avc messages from /var/log/audit/audit.log or > /var/log/messages. > > -- > > > From jorton at redhat.com Tue Aug 16 11:39:44 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 16 Aug 2005 12:39:44 +0100 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <4300BBF8.8050104@redhat.com> References: <20050803121112.GB18144@redhat.com> <42F0C997.5090907@redhat.com> <20050803134507.GC18144@redhat.com> <42F3B4C1.1040000@redhat.com> <20050808154042.GA22758@redhat.com> <20050810202148.GA28397@redhat.com> <4300B30F.9010704@redhat.com> <20050815152804.GA30450@redhat.com> <4300BBF8.8050104@redhat.com> Message-ID: <20050816113944.GB23052@redhat.com> On Mon, Aug 15, 2005 at 11:59:52AM -0400, Daniel J Walsh wrote: > can_network(httpd_t) > can_kerberos(httpd_t) > can_resolve(httpd_t) > can_ypbind(httpd_t) > can_ldap(httpd_t) > allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind; > # allow httpd to connect to mysql/posgresql > allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; > # allow httpd to work as a relay > allow httpd_t { gopher_port_t ftp_port_t http_port_t http_cache_port_t > }:tcp_socket name_connect; So this would allow connections to ports 80, 8080, etc etc? Yes, that looks sufficient, but it does seem to defeat the point of having the boolean in the first place :) joe From paul at city-fan.org Tue Aug 16 11:43:56 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 Aug 2005 12:43:56 +0100 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <20050816113944.GB23052@redhat.com> References: <20050803121112.GB18144@redhat.com> <42F0C997.5090907@redhat.com> <20050803134507.GC18144@redhat.com> <42F3B4C1.1040000@redhat.com> <20050808154042.GA22758@redhat.com> <20050810202148.GA28397@redhat.com> <4300B30F.9010704@redhat.com> <20050815152804.GA30450@redhat.com> <4300BBF8.8050104@redhat.com> <20050816113944.GB23052@redhat.com> Message-ID: <4301D17C.4060809@city-fan.org> Joe Orton wrote: > On Mon, Aug 15, 2005 at 11:59:52AM -0400, Daniel J Walsh wrote: > >>can_network(httpd_t) >>can_kerberos(httpd_t) >>can_resolve(httpd_t) >>can_ypbind(httpd_t) >>can_ldap(httpd_t) >>allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind; >># allow httpd to connect to mysql/posgresql >>allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; >># allow httpd to work as a relay >>allow httpd_t { gopher_port_t ftp_port_t http_port_t http_cache_port_t >>}:tcp_socket name_connect; > > > So this would allow connections to ports 80, 8080, etc etc? > > Yes, that looks sufficient, but it does seem to defeat the point of > having the boolean in the first place :) One example of something that's allowed by setting the boolean but not allowed with the above rules is for httpd_t to connect to an SMTP port. So a compromised httpd can't be used as a spam server. Paul. From jorton at redhat.com Tue Aug 16 12:13:11 2005 From: jorton at redhat.com (Joe Orton) Date: Tue, 16 Aug 2005 13:13:11 +0100 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <4301D17C.4060809@city-fan.org> References: <42F0C997.5090907@redhat.com> <20050803134507.GC18144@redhat.com> <42F3B4C1.1040000@redhat.com> <20050808154042.GA22758@redhat.com> <20050810202148.GA28397@redhat.com> <4300B30F.9010704@redhat.com> <20050815152804.GA30450@redhat.com> <4300BBF8.8050104@redhat.com> <20050816113944.GB23052@redhat.com> <4301D17C.4060809@city-fan.org> Message-ID: <20050816121311.GA26856@redhat.com> On Tue, Aug 16, 2005 at 12:43:56PM +0100, Paul Howarth wrote: > Joe Orton wrote: > >On Mon, Aug 15, 2005 at 11:59:52AM -0400, Daniel J Walsh wrote: > > > >>can_network(httpd_t) > >>can_kerberos(httpd_t) > >>can_resolve(httpd_t) > >>can_ypbind(httpd_t) > >>can_ldap(httpd_t) > >>allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind; > >># allow httpd to connect to mysql/posgresql > >>allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; > >># allow httpd to work as a relay > >>allow httpd_t { gopher_port_t ftp_port_t http_port_t http_cache_port_t > >>}:tcp_socket name_connect; > > > > > >So this would allow connections to ports 80, 8080, etc etc? > > > >Yes, that looks sufficient, but it does seem to defeat the point of > >having the boolean in the first place :) > > One example of something that's allowed by setting the boolean but not > allowed with the above rules is for httpd_t to connect to an SMTP port. > So a compromised httpd can't be used as a spam server. Unless /usr/sbin/sendmail works, which it should. But I don't think this is the right approach to be taking with this issue. I think it would be really useful to have a boolean which could be turned on which prevents httpd from making any outgoing TCP connections at all [1]. If I'm running a box with web server and database for your average LAMP webapp, that would be a *really* useful security feature: I can turn it on and significantly mitigate the impact of all PHP issues du jour. But with this watered down policy, it's not really useful at all. The PHP exploit can go and wget some local kernel exploit code and we're all doomed again. joe [1] (note that the *connections to local interfaces* are still needed for the parent-connects-to-port-80 thing even with such a policy enforced) From dwalsh at redhat.com Tue Aug 16 17:27:57 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 16 Aug 2005 13:27:57 -0400 Subject: Questions about /net and /proc In-Reply-To: <8a239a5605081514256fcd87f5@mail.gmail.com> References: <8a239a5605080914226519ed08@mail.gmail.com> <4300B603.7040205@redhat.com> <8a239a5605081514256fcd87f5@mail.gmail.com> Message-ID: <4302221D.5030103@redhat.com> James Z. Li wrote: >In the shell script, namely redhat-install.sh >... >REDHAT_AREA=/net/redhat; >SERVER=abc.foo.edu; >if [ ! -d ${REDHAT_AREA}/bin ]; then > mkdir -p ${REDHAT_AREA}/bin; >fi >echo "Copying some files from server" >scp -r ${SERVER}:${REDHAT_AREA}/bin/ ${REDHAT_AREA} >... > >I labeled the redhat-install.sh script as file_t and shell_exec_t, >but they both did not work. There is no security context for /net >and /net is empty on my machine, so when I run this script, the >error messages are: >mkdir: cannot create directory `/net/redhat': Permission denied >Copying some files from server >/net/redhat: Permission denied > > I think this is a DAC error. /net is controled by the automounter. If you setenforce 0 mkdir /net/redhat mkdir: cannot create directory `/net/redhat': Permission denied So I think you either need to turn off automounter or use a different directory. >There is no AVC messages in either /var/log/messages or >/var/log/audit/audit.log. There are these lines in /var/log/messages: >Aug 15 16:51:17 ko automount[3254]: >> /usr/sbin/showmount: can't get >address for redhat >Aug 15 16:51:17 ko automount[3254]: lookup(program): lookup for redhat failed >Aug 15 16:51:17 ko automount[3254]: failed to mount /net/redhat > >Thanks a lot, > >James > >On 8/15/05, Daniel J Walsh wrote: > > >>James Z. Li wrote: >> >> >> >>>Hi all, >>> >>>I have several root shell scripts which need create directories >>>under /net or /proc. They are running well under Fedora Core 2. >>>After I upgrate to FC4 with targeted SELinux policy, those >>>scripts are not running under either enforcing or permissive mode. >>>Error messages like Unable to create directories under /net or /proc. >>>I used "ls -Z" to check security contexts for /net and /proc, >>>they both have empty security labels. >>>As a root (root:system_r:unconfined_t), I cannot manually create >>>anything under those two directories. >>> >>>What should I do in order to make /net and /proc writtable? >>> >>>Thanks, >>> >>>James >>> >>>-- >>>fedora-selinux-list mailing list >>>fedora-selinux-list at redhat.com >>>http://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> >>> >>> >>> >>Could you supply the avc messages from /var/log/audit/audit.log or >>/var/log/messages. >> >>-- >> >> >> >> >> -- From dwalsh at redhat.com Tue Aug 16 17:29:55 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 16 Aug 2005 13:29:55 -0400 Subject: [Bug 164992] New: Mod_proxy does not work with SElinux default policy In-Reply-To: <20050816113944.GB23052@redhat.com> References: <20050803121112.GB18144@redhat.com> <42F0C997.5090907@redhat.com> <20050803134507.GC18144@redhat.com> <42F3B4C1.1040000@redhat.com> <20050808154042.GA22758@redhat.com> <20050810202148.GA28397@redhat.com> <4300B30F.9010704@redhat.com> <20050815152804.GA30450@redhat.com> <4300BBF8.8050104@redhat.com> <20050816113944.GB23052@redhat.com> Message-ID: <43022293.3080200@redhat.com> Joe Orton wrote: >On Mon, Aug 15, 2005 at 11:59:52AM -0400, Daniel J Walsh wrote: > > >>can_network(httpd_t) >>can_kerberos(httpd_t) >>can_resolve(httpd_t) >>can_ypbind(httpd_t) >>can_ldap(httpd_t) >>allow httpd_t { http_port_t http_cache_port_t }:tcp_socket name_bind; >># allow httpd to connect to mysql/posgresql >>allow httpd_t { postgresql_port_t mysqld_port_t }:tcp_socket name_connect; >># allow httpd to work as a relay >>allow httpd_t { gopher_port_t ftp_port_t http_port_t http_cache_port_t >>}:tcp_socket name_connect; >> >> > >So this would allow connections to ports 80, 8080, etc etc? > >Yes, that looks sufficient, but it does seem to defeat the point of >having the boolean in the first place :) > > > Yes and know, Since the main goal is to stop spamming we have prevented this. I could add another boolean on by default that allowed httpd_relay or something. >joe > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From gnu at wraith.sf.ca.us Tue Aug 16 21:33:50 2005 From: gnu at wraith.sf.ca.us (gnu not unix) Date: Tue, 16 Aug 2005 14:33:50 -0700 Subject: fc3 ntpd shm policy rule Message-ID: <200508162133.j7GLXoQ7011516@ring.wraith.sf.ca.us> Hi folks-- I've been running fc3 / ccrma selinux and needed to add a policy to allow ntpd shm access: allow ntpd_t self:shm { associate create read unix_read unix_write write }; allow ntpd_t tmpfs_t:file { read write }; I put this in my domains/misc/local.te and make reload and I was in business. I'm not sure if this would be something you'd want to always enable, as a typical ntpd uses third party clocks, on the internet or corportate wan, etc. Perhaps a ntpd.client policy for generic, default use, and an ntpd.refclock policy for all the device and other access needed to talk to refclocks? ../Steven trying to get a feel for selinux From rhally at mindspring.com Wed Aug 17 06:05:24 2005 From: rhally at mindspring.com (Richard Hally) Date: Wed, 17 Aug 2005 02:05:24 -0400 Subject: s-c-securitylevel and permissive? Message-ID: <4302D3A4.1030806@mindspring.com> running rawhide with the strict policy, when I startup system-config-securitylevel from the menu and simply exit by clicking on OK (without changing anything) the system is switched from enforcing to permissive. Anyone else seeing this? Thanks, Richard Hally From jirkat at atlas.cz Wed Aug 17 12:49:20 2005 From: jirkat at atlas.cz (jirkat at atlas.cz) Date: Wed, 17 Aug 2005 14:49:20 +0200 Subject: dhcpd in FC4 Message-ID: Hi, I've insttalled dhcpd server on FC4, but it could not be started from init (when in 'enforce' mode) It seems that rc script with type initrc_exec_t (running under related domain) cannot exec the dhcpd program with file type dhcpd_exec_t. What confuses me is that I cannot find any AVC messages in syslog, console nor dmesg. How can I enable the avc: messages? What shall I do to get dhcpd working? Thanks Tom From dwalsh at redhat.com Wed Aug 17 13:37:36 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 17 Aug 2005 09:37:36 -0400 Subject: dhcpd in FC4 In-Reply-To: References: Message-ID: <43033DA0.80700@redhat.com> jirkat at atlas.cz wrote: >Hi, > >I've insttalled dhcpd server on FC4, but it could not be started from init >(when in 'enforce' mode) > >It seems that rc script with type initrc_exec_t (running under related domain) >cannot exec the dhcpd program with file type dhcpd_exec_t. > >What confuses me is that I cannot find any AVC messages in syslog, console nor dmesg. > >How can I enable the avc: messages? >What shall I do to get dhcpd working? > >Thanks > >Tom > > > > > Check for avc messages in /var/log/audit/audit.log >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From cs007lj at wowway.com Sat Aug 13 22:55:01 2005 From: cs007lj at wowway.com (Craig) Date: Sat, 13 Aug 2005 18:55:01 -0400 Subject: windbindd.log & snmpd not playing well with selinux Message-ID: <42FE7A45.8060605@wowway.com> The other day I rebooted my pc to check on the new configuration (adding/removing) of services. Although the reboot wasn't _necessary_, I wanted to see what effect the changes in booted services would do to the bootup time. Unfortunately, I forgot about an earlier selinux problem I had that required an ".autolabel" reboot of the system & have had some interesting issues with windbind & snmpd. I am running the following selinux packages: libselinux-1.19.1-8.i386.rpm libselinux-devel-1.19.1-8.i386.rpm selinux-doc-1.14.1-1.noarch.rpm selinux-policy-targeted-1.17.30-3.16.noarch.rpm I have looked at the bugzilla logs and these issues are entirely separate from those mentioned (or at least they seem to be different to me). First, the snmpd service will not start because it is being denied by selinux: Aug 13 07:22:13 wowway kernel: audit(1123932133.514:20): avc: denied { execmem } for pid=8352 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:snmpd_t tclass=process Aug 13 18:18:35 wowway kernel: audit(1123971515.257:21): avc: denied { execmem } for pid=10368 comm="snmpd" scontext=root:system_r:snmpd_t tcontext=root:system_r:snmpd_t tclass=process It was only after the searching the System log for avc denials that I came across the windbind problem which, to my knowledge, has not affected my ability to access shared mounts or the the printer connected to my linux box. Apparently, selinux is not allowing windbind to append or write to the windbindd.log: Aug 12 19:46:12 wowway kernel: audit(1123890372.244:2): avc: denied { execmem } for pid=3873 comm="snmpd" scontext=user_u:system_r:snmpd_t tcontext=user_u:system_r:snmpd_t tclass=process Aug 12 19:46:25 wowway kernel: audit(1123890385.354:3): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.355:4): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.355:5): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.355:6): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.355:7): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.355:8): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.355:9): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.355:10): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.355:11): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.392:12): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.392:13): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.392:14): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.414:15): avc: denied { write } for pid=4120 comm="winbindd" name="secrets.tdb" dev=dm-2 ino=345283 scontext=user_u:system_r:winbind_t tcontext=root:object_r:etc_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.415:16): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.415:17): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.415:18): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file Aug 12 19:46:25 wowway kernel: audit(1123890385.415:19): avc: denied { append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 ino=1641389 scontext=user_u:system_r:winbind_t tcontext=root:object_r:var_log_t tclass=file I admit that I have not had time to delve into selinux context structures and rules, but these denials seem to be different, at least so far as I can tell, from what has been reported. Please let me know if there is any further information that can / need to provide. Craig From Thomas.Binder at tbinder.info Wed Aug 17 15:46:35 2005 From: Thomas.Binder at tbinder.info (Thomas.Binder) Date: Wed, 17 Aug 2005 17:46:35 +0200 (CEST) Subject: FC4, imap, sasl problems ... Message-ID: <56815.212.152.151.132.1124293595.squirrel@mail.tbinder.info> Hi folks! I don't know whether this has already been fixed, but there seems to be a typo in version 1.25.3-12 of selinux-policy-targeted-sources in file /etc/selinux/targeted/src/policy/domains/program/cyrus.te: --- cyrus.te.old 2005-08-17 17:44:01.000000000 +0200 +++ cyrus.te 2005-08-17 17:11:22.000000000 +0200 @@ -42,7 +42,7 @@ create_dir_file(cyrus_t, mail_spool_t) allow cyrus_t var_spool_t:dir search; -ifdef(`saslaudthd.te', ` +ifdef(`saslauthd.te', ` allow cyrus_t saslauthd_var_run_t:dir search; allow cyrus_t saslauthd_var_run_t:sock_file { read write }; allow cyrus_t saslauthd_t:unix_stream_socket { connectto }; best regards, Tom From joshsehn at sane.ca Wed Aug 17 20:24:01 2005 From: joshsehn at sane.ca (Josh Sehn) Date: Wed, 17 Aug 2005 14:24:01 -0600 Subject: httpd avc denied problem Message-ID: Did you guys get this problem sorted out? I am having similar problem and am not as comfortable as you trying out all the different options presented in this thread. https://www.redhat.com/archives/fedora-selinux-list/2004-November/msg001 49.html thanks, Josh Sehn SANE Consulting Inc. Box 20118 Kensington P.O. Medicine Hat, Alberta. T1A 8M4 Joshsehn sane ca Mobile: 403-979-1717 FAX: 403-528-4710 http://www.sane.ca Technical solutions for your business needs. From sonoch at gmail.com Thu Aug 18 01:13:51 2005 From: sonoch at gmail.com (=?ISO-8859-1?Q?S=F8ren_N=F8hr_Christensen?=) Date: Thu, 18 Aug 2005 10:13:51 +0900 Subject: Questions on the targeted policy Message-ID: Hi all! Would it be possible to deny all but one subject access to a certain directory? And can this be done using the targeted policy as a base? I hope for some answers, possibly containing examples. Best regards, Soren Nohr Christensen From eric.tanguy at univ-nantes.fr Thu Aug 18 08:42:05 2005 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Thu, 18 Aug 2005 10:42:05 +0200 Subject: cgiirc Message-ID: <1124354525.3100.13.camel@bureau.maison> I try to make cgiirc working on my system. Apache works fine and selinux Allow HTTPD scripts to connect to the network is enable. So i can cgiirc to connect to an irc server. I can see what is said on the channel but i can't make any action. If i disable selinux all works fine. If i enable selinux i have this in /var/log/audit/audit.log : type=AVC msg=audit(1124298167.251:3778508): avc: denied { read } for pid=3907 comm="irc.cgi" name="formats" dev=dm-0 ino=8323109 scontext=system_u:system_r:httpd_sys_script_t tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir type=SYSCALL msg=audit(1124298167.251:3778508): arch=40000003 syscall=5 success=no exit=-13 a0=94586b8 a1=18800 a2=94586b8 a3=9430fe0 items=1 pid=3907 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="irc.cgi" exe="/usr/bin/perl" type=CWD msg=audit(1124298167.251:3778508): cwd="/var/www/cgi-bin/cgiirc" type=PATH msg=audit(1124298167.251:3778508): item=0 name="formats" flags=103 inode=8323109 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1124298171.144:3812320): avc: denied { connectto } for pid=3922 comm="client-perl.cgi" name="sock" scontext=system_u:system_r:httpd_sys_script_t tcontext=system_u:system_r:httpd_sys_script_t tclass=unix_stream_socket type=SYSCALL msg=audit(1124298171.144:3812320): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfc86690 a2=45b3bc0 a3=6e items=1 pid=3922 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="client-perl.cgi" exe="/usr/bin/perl" type=AVC_PATH msg=audit(1124298171.144:3812320): path="/tmp/cgiirc-0coinr388dt/sock" type=SOCKADDR msg=audit(1124298171.144:3812320): saddr=01002F746D702F6367696972632D30636F696E7233383864742F736F636B0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 But it's very difficult to understand where is the problem. Someone could help me? Thanks -- Eric Tanguy | Nantes, France Key : A4B8368F | Key Server : subkeys.pgp.net Fedora Core release 4 (Stentz) sur athlon kernel 2.6.12-1.1398_FC4 From ankushgrover1711 at gmail.com Thu Aug 18 11:06:41 2005 From: ankushgrover1711 at gmail.com (ankush grover) Date: Thu, 18 Aug 2005 16:36:41 +0530 Subject: viewcvs problem with SELinux Message-ID: hey friends, I have configure cvs and viewcvs on FC3 but I am not able to access viewcvs when SELinux is on. The /var/log/messages contains these entries avc: denied { execute } for pid=5233 exe=/usr/sbin/httpd name=viewcvs.cgi dev=hda5 ino=198687 scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:usr_t tclass=file When I switch off SELinux I am able to access the viewcvs through the browser. ls -lZ /usr/local/viewcvs drwxr-xr-x root root system_u:object_r:usr_t cgi -rwxr-xr-x root root system_u:object_r:usr_t cvsdbadmin -rw-r--r-- root root system_u:object_r:usr_t cvsgraph.conf drwxr-xr-x root root system_u:object_r:usr_t doc drwxr-xr-x root root system_u:object_r:lib_t lib -rwxr-xr-x root root system_u:object_r:usr_t loginfo-handler -rwxr-xr-x root root system_u:object_r:usr_t make-database -rwxr-xr-x root root system_u:object_r:usr_t standalone.py drwxr-xr-x root root system_u:object_r:usr_t templates -rw-r--r-- root root system_u:object_r:usr_t viewcvs.conf I also did this make -C /etc/selinux/targeted/src/policy reload restorecon -R /usr/local/viewcvs But still the problem is persisting. Thanks & Regards Ankush Grover From russell at coker.com.au Fri Aug 19 09:25:50 2005 From: russell at coker.com.au (Russell Coker) Date: Fri, 19 Aug 2005 19:25:50 +1000 Subject: kernel Oops from policy Message-ID: <200508191925.55561.russell@coker.com.au> r_dir_file(insmod_t, debugfs_t) The above needs to be added to the strict policy to prevent a kernel Oops on boot with the usb_uhci driver. Below is the kernel message log from before I added the above to one of my systems. I only really needed to allow search access to the directory, but I decided to allow full read access to the directory and any files under it just in case. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=166327 Above is a bugzilla entry. USB Universal Host Controller Interface driver v2.2 SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts audit(1124441960.362:2): avc: denied { search } for pid=958 comm="modprobe" n ame="/" dev=debugfs ino=3962 scontext=system_u:system_r:insmod_t tcontext=system_u:object_r:debugfs_t tclass=dir Unable to handle kernel NULL pointer dereference at virtual address 00000013 printing eip: c01e1d48 *pde = 00000000 Oops: 0000 [#1] Modules linked in: uhci_hcd i2c_i801 i2c_core snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc e100 mii flo ppy dm_snapshot dm_zero dm_mirror ext3 jbd dm_mod CPU: 0 EIP: 0060:[] Not tainted VLI EFLAGS: 00010286 (2.6.12-1.1398_FC4) EIP is at debugfs_mknod+0x1b/0x47 eax: ffffffef ebx: fffffff3 ecx: 00006468 edx: d72ac578 esi: d591ecb0 edi: d6939f6c ebp: d89e6aca esp: d6939f3c ds: 007b es: 007b ss: 0068 Process modprobe (pid: 958, threadinfo=d6939000 task=d6cf4000) Stack: d72ac71c c01e1d8f 00000000 d72ac71c c01e1ecf 41ed001c 00000000 000041ed 00000000 d89e6aca c01e1f4c d6939f6c fffffff3 ffffffed c0000000 d89e9700 d6939000 c01e1fc4 00000000 00000000 d883603c d89e7108 d6939000 c0000000 Call Trace: [] debugfs_mkdir+0x1b/0x28 [] debugfs_create_by_name+0x91/0xbe [] debugfs_create_file+0x50/0xaa [] debugfs_create_dir+0x1e/0x22 [] uhci_hcd_init+0x3c/0xea [uhci_hcd] [] sys_init_module+0xca/0x1c4 [] syscall_call+0x7/0xb Code: 00 00 60 12 3d c0 89 d8 83 c4 08 5b 5e 5f 5d c3 53 89 d3 89 ca 8b 4c 24 08 8b 80 dc 00 00 00 e8 2f ff ff ff 89 c2 b8 ef ff ff ff <8b> 4b 20 85 c9 74 02 5b c3 b0 ff 85 d2 74 f8 89 d8 e8 a7 84 fb <6>ACPI: Power Button (FF) [PWRF] From sds at tycho.nsa.gov Fri Aug 19 12:47:47 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 19 Aug 2005 08:47:47 -0400 Subject: s-c-securitylevel and permissive? In-Reply-To: <4302D3A4.1030806@mindspring.com> References: <4302D3A4.1030806@mindspring.com> Message-ID: <1124455667.32663.39.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2005-08-17 at 02:05 -0400, Richard Hally wrote: > running rawhide with the strict policy, when I startup > system-config-securitylevel from the menu and simply exit by clicking on > OK (without changing anything) the system is switched from enforcing to > permissive. > Anyone else seeing this? Here is what I see: On every exit from system-config-securitylevel, it attempts to rewrite /etc/selinux/config and reset the kernel enforcing status to whatever is in that file, even if no changes were made. Looks like the dirty flag is being set all the time by enabled_changed due to invocation during initialization, but I haven't looked into why. Dan? -- Stephen Smalley National Security Agency From cpebenito at tresys.com Fri Aug 19 19:48:57 2005 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Fri, 19 Aug 2005 15:48:57 -0400 Subject: object classes and permissions list updated Message-ID: <1124480937.6403.24.camel@sgc.columbia.tresys.com> There were some questions as to the meaning of some of the newer permissions not too long ago. I've updated the overview of SELinux object classes and permissions, available here: http://www.tresys.com/selinux. It contains all of the classes and permissions, including the netlink_kobject_uevent_socket class and execstack and execheap process permissions added in 2.6.12. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From linux_4ever at yahoo.com Fri Aug 19 21:49:23 2005 From: linux_4ever at yahoo.com (Steve G) Date: Fri, 19 Aug 2005 14:49:23 -0700 (PDT) Subject: kernel Oops from policy In-Reply-To: <200508191925.55561.russell@coker.com.au> Message-ID: <20050819214923.9986.qmail@web51502.mail.yahoo.com> >The above needs to be added to the strict policy to prevent a kernel Oops on >boot with the usb_uhci driver. Wait a minute, a kernel Oops should be fixed by correcting the kernel code - not changing SE Linux policy, right? You've just hidden the oops, but its still there. -Steve __________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250 From jmorris at namei.org Sat Aug 20 03:53:57 2005 From: jmorris at namei.org (James Morris) Date: Fri, 19 Aug 2005 23:53:57 -0400 (EDT) Subject: kernel Oops from policy In-Reply-To: <20050819214923.9986.qmail@web51502.mail.yahoo.com> References: <20050819214923.9986.qmail@web51502.mail.yahoo.com> Message-ID: On Fri, 19 Aug 2005, Steve G wrote: > Wait a minute, a kernel Oops should be fixed by correcting the kernel code - not > changing SE Linux policy, right? You've just hidden the oops, but its still > there. Correct. - James -- James Morris From selinux at gmail.com Sat Aug 20 18:35:09 2005 From: selinux at gmail.com (Tom London) Date: Sat, 20 Aug 2005 11:35:09 -0700 Subject: gdm failures? compiler or policy problems? Message-ID: <4c4ba15305082011356cd58b9e@mail.gmail.com> Running strict/enforcing, today's rawhide. gdm fails to start (many initrc_t/xserver_t type failures). I would normally guess a missing transition, but there are some reports of problems with gcc4/-Os. Regardless, gdm starts fine in permissive mode. tom -- Tom London -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at gmail.com Sun Aug 21 21:08:39 2005 From: selinux at gmail.com (Tom London) Date: Sun, 21 Aug 2005 14:08:39 -0700 Subject: gdm failures? compiler or policy problems? In-Reply-To: <4c4ba15305082011356cd58b9e@mail.gmail.com> References: <4c4ba15305082011356cd58b9e@mail.gmail.com> Message-ID: <4c4ba15305082114086130b20e@mail.gmail.com> On 8/20/05, Tom London wrote: > > Running strict/enforcing, today's rawhide. > > gdm fails to start (many initrc_t/xserver_t type failures). > > I would normally guess a missing transition, but there are some reports of > problems with gcc4/-Os. > > Regardless, gdm starts fine in permissive mode. > OK..... 2 small 'fixes' seem to make this work: --- /tmp/xdm.fc 2005-08-21 14:02:59.000000000 -0700 +++ ./xdm.fc 2005-08-21 13:45:22.000000000 -0700 @@ -2,8 +2,8 @@ /usr/bin/[xgkw]dm -- system_u:object_r:xdm_exec_t /usr/X11R6/bin/[xgkw]dm -- system_u:object_r:xdm_exec_t /opt/kde3/bin/kdm -- system_u:object_r:xdm_exec_t -/usr/bin/gpe-dm -- system_u:object_r:xdm_exec_t -/usr/bin/gdm-binary -- system_u:object_r:xdm_exec_t +/usr/(s)?bin/gpe-dm -- system_u:object_r:xdm_exec_t +/usr/(s)?bin/gdm-binary -- system_u:object_r:xdm_exec_t /var/[xgk]dm(/.*)? system_u:object_r:xserver_log_t /usr/var/[xgkw]dm(/.*)? system_u:object_r:xserver_log_t /var/log/[kw]dm\.log -- system_u:object_r:xserver_log_t And, --- /tmp/xdm.te 2005-08-21 14:04:29.000000000 -0700 +++ ./xdm.te 2005-08-21 13:44:13.000000000 -0700 @@ -21,7 +21,7 @@ daemon_domain(xdm, `, privuser, privrole, auth_chkpwd, privowner, privmem, nscd_client_domain') # for running xdm from init -domain_auto_trans(init_t, xdm_exec_t, xdm_t) +domain_auto_trans({ init_t initrc_t }, xdm_exec_t, xdm_t) allow xdm_t xdm_var_run_t:dir setattr; tom -- Tom London -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at gmail.com Mon Aug 22 01:00:33 2005 From: selinux at gmail.com (Tom London) Date: Sun, 21 Aug 2005 18:00:33 -0700 Subject: gdm failures? compiler or policy problems? In-Reply-To: <4c4ba15305082114086130b20e@mail.gmail.com> References: <4c4ba15305082011356cd58b9e@mail.gmail.com> <4c4ba15305082114086130b20e@mail.gmail.com> Message-ID: <4c4ba15305082118007978f554@mail.gmail.com> On 8/21/05, Tom London wrote: > > On 8/20/05, Tom London wrote: > > > > Running strict/enforcing, today's rawhide. > > > > gdm fails to start (many initrc_t/xserver_t type failures). > > > > I would normally guess a missing transition, but there are some reports > > of problems with gcc4/-Os. > > > > Regardless, gdm starts fine in permissive mode. > > > > OK..... 2 small 'fixes' seem to make this work: > > --- /tmp/xdm.fc 2005-08-21 14:02:59.000000000 -0700 > +++ ./xdm.fc 2005-08-21 13:45:22.000000000 -0700 > @@ -2,8 +2,8 @@ > /usr/bin/[xgkw]dm -- system_u:object_r:xdm_exec_t > /usr/X11R6/bin/[xgkw]dm -- system_u:object_r:xdm_exec_t > /opt/kde3/bin/kdm -- system_u:object_r:xdm_exec_t > -/usr/bin/gpe-dm -- system_u:object_r:xdm_exec_t > -/usr/bin/gdm-binary -- system_u:object_r:xdm_exec_t > +/usr/(s)?bin/gpe-dm -- system_u:object_r:xdm_exec_t > +/usr/(s)?bin/gdm-binary -- system_u:object_r:xdm_exec_t Oops.... the entry for /usr/bin/gpe-dm shouldn't have been changed. A little 'typing enthusiasm' on my part. tom -- Tom London -------------- next part -------------- An HTML attachment was scrubbed... URL: From iocc at fedora-selinux.lists.flashdance.cx Mon Aug 22 02:23:30 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Mon, 22 Aug 2005 04:23:30 +0200 (CEST) Subject: cant create dirs from vsftpd Message-ID: selinux-policy-targeted-1.25.3-9 in FC4 surely isnt perfect. Cant create dirs when I login over ftp: type=CWD msg=audit(1123375603.524:11258814): cwd="/home/iocc" type=PATH msg=audit(1123375603.524:11258814): item=0 name="mp3" flags=10 inode=5046274 dev=03:01 mode=040755 ouid=636 ogid=636 rdev=00:00 type=AVC msg=audit(1123375603.539:11258878): avc: denied { getattr } for pid=10556 comm="vsftpd" name="/" dev=0:10 ino=49161 scontext=root:system_r:ftpd_t tcontext=system_u:object_r:nfs_t tclass=dir type=SYSCALL msg=audit(1123375603.539:11258878): arch=40000003 syscall=196 success=no exit=-13 a0=9527930 a1=9523328 a2=3a3ff4 a3=797eec items=1 pid=10556 auid=636 uid=636 gid=636 euid=636 suid=636 fsuid=636 egid=636 sgid=636 fsgid=636 comm="vsftpd" exe="/usr/sbin/vsftpd" Cant find what I should turn off in /etc/selinux/targeted/booleans to make it work. So I need a little help. Later, I want to upload files in that dir also. Also, Im not so sure that I like that I cant see alot of dirs when Im logged in at the ftp. From Valdis.Kletnieks at vt.edu Mon Aug 22 03:10:19 2005 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 21 Aug 2005 23:10:19 -0400 Subject: cant create dirs from vsftpd In-Reply-To: Your message of "Mon, 22 Aug 2005 04:23:30 +0200." References: Message-ID: <200508220310.j7M3AKPs015070@turing-police.cc.vt.edu> On Mon, 22 Aug 2005 04:23:30 +0200, Peter Magnusson said: > Also, Im not so sure that I like that I cant see alot of dirs when Im > logged in at the ftp. Give specific examples, and why you think FTP should be able to see that dir? Most security people would consider this behavior in general a feature rather than a bug - but if there's a *specific* corner case that needs different treatment, we probably can fix it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From zhangyanxv at 163.com Sat Aug 20 11:57:25 2005 From: zhangyanxv at 163.com (zhangyanxv) Date: Sat, 20 Aug 2005 19:57:25 +0800 Subject: "setenforce 0",seytem complain command not found Message-ID: <1124539046.5695.5.camel@localhost.localdomain> Hello, I want to run matlab704 on my FC4 box,and I know before running I should disable the SElinux with "setenforce 0",and it does works some times,but not always and hints that command not found! Very weird and the system seemed not reasonable.Please help me. Thanks a lot! Aladin From paul at city-fan.org Mon Aug 22 09:51:30 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 22 Aug 2005 10:51:30 +0100 Subject: "setenforce 0",seytem complain command not found In-Reply-To: <1124539046.5695.5.camel@localhost.localdomain> References: <1124539046.5695.5.camel@localhost.localdomain> Message-ID: <4309A022.8030000@city-fan.org> zhangyanxv wrote: > Hello, > I want to run matlab704 on my FC4 box,and I know before running I > should disable the SElinux with "setenforce 0",and it does works some > times,but not always and hints that command not found! Very weird and > the system seemed not reasonable.Please help me. > Thanks a lot! You are probably using just "su" and not "su -" to switch to root before running setenforce. As a result of this, you aren't getting root's environment set up, specifically the inclusion of directory /usr/sbin in your PATH, and hence you get "command not found" when trying to run setenforce. Paul. From dwalsh at redhat.com Mon Aug 22 14:43:36 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 22 Aug 2005 10:43:36 -0400 Subject: windbindd.log & snmpd not playing well with selinux In-Reply-To: <42FE7A45.8060605@wowway.com> References: <42FE7A45.8060605@wowway.com> Message-ID: <4309E498.9000209@redhat.com> Craig wrote: >The other day I rebooted my pc to check on the new configuration >(adding/removing) of services. Although the reboot wasn't _necessary_, I >wanted to see what effect the changes in booted services would do to the >bootup time. Unfortunately, I forgot about an earlier selinux problem I >had that required an ".autolabel" reboot of the system & have had some >interesting issues with windbind & snmpd. I am running the following >selinux packages: > >libselinux-1.19.1-8.i386.rpm >libselinux-devel-1.19.1-8.i386.rpm >selinux-doc-1.14.1-1.noarch.rpm >selinux-policy-targeted-1.17.30-3.16.noarch.rpm > >I have looked at the bugzilla logs and these issues are entirely >separate from those mentioned (or at least they seem to be different to >me). First, the snmpd service will not start because it is being denied >by selinux: > >Aug 13 07:22:13 wowway kernel: audit(1123932133.514:20): avc: denied { >execmem } for pid=8352 comm="snmpd" scontext=root:system_r:snmpd_t >tcontext=root:system_r:snmpd_t tclass=process >Aug 13 18:18:35 wowway kernel: audit(1123971515.257:21): avc: denied { >execmem } for pid=10368 comm="snmpd" scontext=root:system_r:snmpd_t >tcontext=root:system_r:snmpd_t tclass=process > >It was only after the searching the System log for avc denials that I >came across the windbind problem which, to my knowledge, has not >affected my ability to access shared mounts or the the printer connected >to my linux box. Apparently, selinux is not allowing windbind to append >or write to the windbindd.log: > >Aug 12 19:46:12 wowway kernel: audit(1123890372.244:2): avc: denied { >execmem } for pid=3873 comm="snmpd" scontext=user_u:system_r:snmpd_t >tcontext=user_u:system_r:snmpd_t tclass=process >Aug 12 19:46:25 wowway kernel: audit(1123890385.354:3): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.355:4): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.355:5): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.355:6): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.355:7): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.355:8): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.355:9): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.355:10): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.355:11): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.392:12): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.392:13): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.392:14): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.414:15): avc: denied { >write } for pid=4120 comm="winbindd" name="secrets.tdb" dev=dm-2 >ino=345283 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:etc_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.415:16): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.415:17): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.415:18): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file >Aug 12 19:46:25 wowway kernel: audit(1123890385.415:19): avc: denied { >append } for pid=4120 comm="winbindd" name="winbindd.log" dev=dm-2 >ino=1641389 scontext=user_u:system_r:winbind_t >tcontext=root:object_r:var_log_t tclass=file > >I admit that I have not had time to delve into selinux context >structures and rules, but these denials seem to be different, at least >so far as I can tell, from what has been reported. Please let me know if >there is any further information that can / need to provide. > >Craig > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > restorecon -v /var/log/windbindd.log restorecon -v /etc/samba/secrets.tdb Not sure what is causing the execmem for snmpd though. -- From dwalsh at redhat.com Mon Aug 22 14:46:50 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 22 Aug 2005 10:46:50 -0400 Subject: Questions on the targeted policy In-Reply-To: References: Message-ID: <4309E55A.5020902@redhat.com> S?ren N?hr Christensen wrote: >Hi all! > >Would it be possible to deny all but one subject access to a certain >directory? > Yes. >And can this be done using the targeted policy as a base? > > You would have to modify unconfined_domain to remove access to this directory. Not sure if you want to though. What exactly are you trying to protect? In targeted policy, if a user can become root as unconfined_t, they can gain access to this directory, either by turning off selinux or by modifying policy. >I hope for some answers, possibly containing examples. > > >Best regards, > > >Soren Nohr Christensen > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From sonoch at gmail.com Tue Aug 23 01:26:35 2005 From: sonoch at gmail.com (=?ISO-8859-1?Q?S=F8ren_N=F8hr_Christensen?=) Date: Tue, 23 Aug 2005 10:26:35 +0900 Subject: Questions on the targeted policy In-Reply-To: <4309E55A.5020902@redhat.com> References: <4309E55A.5020902@redhat.com> Message-ID: Hi Daniel! I agree that the targeted policy is not the way to go, just had to figure it out ;-) I am trying to control access to a directory, so that a single program is the single point of entry to the directory. Thank you for your answer, Soren On 8/22/05, Daniel J Walsh wrote: > S?ren N?hr Christensen wrote: > > >Hi all! > > > >Would it be possible to deny all but one subject access to a certain > >directory? > > > Yes. > > >And can this be done using the targeted policy as a base? > > > > > You would have to modify unconfined_domain to remove access to this > directory. > Not sure if you want to though. What exactly are you trying to > protect? In targeted > policy, if a user can become root as unconfined_t, they can gain access > to this directory, > either by turning off selinux or by modifying policy. > > >I hope for some answers, possibly containing examples. > > > > > >Best regards, > > > > > >Soren Nohr Christensen > > > >-- > >fedora-selinux-list mailing list > >fedora-selinux-list at redhat.com > >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > > > -- > > > From walters at redhat.com Tue Aug 23 13:57:48 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 23 Aug 2005 09:57:48 -0400 Subject: cant create dirs from vsftpd In-Reply-To: <200508220310.j7M3AKPs015070@turing-police.cc.vt.edu> References: <200508220310.j7M3AKPs015070@turing-police.cc.vt.edu> Message-ID: <1124805469.26651.23.camel@nexus.verbum.private> On Sun, 2005-08-21 at 23:10 -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 22 Aug 2005 04:23:30 +0200, Peter Magnusson said: > > > Also, Im not so sure that I like that I cant see alot of dirs when Im > > logged in at the ftp. > > Give specific examples, and why you think FTP should be able to see that dir? > Most security people would consider this behavior in general a feature rather > than a bug - but if there's a *specific* corner case that needs different > treatment, we probably can fix it. Ah...isn't that his home directory? Seems like a reasonable use of FTP... Maybe he needs the ftp_home_dir boolean enabled, although that looks like the default. From walters at redhat.com Tue Aug 23 13:57:48 2005 From: walters at redhat.com (Colin Walters) Date: Tue, 23 Aug 2005 09:57:48 -0400 Subject: cant create dirs from vsftpd In-Reply-To: <200508220310.j7M3AKPs015070@turing-police.cc.vt.edu> References: <200508220310.j7M3AKPs015070@turing-police.cc.vt.edu> Message-ID: <1124805469.26651.23.camel@nexus.verbum.private> On Sun, 2005-08-21 at 23:10 -0400, Valdis.Kletnieks at vt.edu wrote: > On Mon, 22 Aug 2005 04:23:30 +0200, Peter Magnusson said: > > > Also, Im not so sure that I like that I cant see alot of dirs when Im > > logged in at the ftp. > > Give specific examples, and why you think FTP should be able to see that dir? > Most security people would consider this behavior in general a feature rather > than a bug - but if there's a *specific* corner case that needs different > treatment, we probably can fix it. Ah...isn't that his home directory? Seems like a reasonable use of FTP... Maybe he needs the ftp_home_dir boolean enabled, although that looks like the default. From dwalsh at redhat.com Tue Aug 23 14:22:47 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 23 Aug 2005 10:22:47 -0400 Subject: cant create dirs from vsftpd In-Reply-To: References: Message-ID: <430B3137.3040903@redhat.com> Peter Magnusson wrote: > selinux-policy-targeted-1.25.3-9 in FC4 surely isnt perfect. Cant create > dirs when I login over ftp: > > type=CWD msg=audit(1123375603.524:11258814): cwd="/home/iocc" > type=PATH msg=audit(1123375603.524:11258814): item=0 name="mp3" flags=10 > inode=5046274 dev=03:01 mode=040755 ouid=636 ogid=636 rdev=00:00 > type=AVC msg=audit(1123375603.539:11258878): avc: denied { getattr } for > pid=10556 comm="vsftpd" name="/" dev=0:10 ino=49161 > scontext=root:system_r:ftpd_t tcontext=system_u:object_r:nfs_t tclass=dir > type=SYSCALL msg=audit(1123375603.539:11258878): arch=40000003 > syscall=196 > success=no exit=-13 a0=9527930 a1=9523328 a2=3a3ff4 a3=797eec items=1 > pid=10556 auid=636 uid=636 gid=636 euid=636 suid=636 fsuid=636 egid=636 > sgid=636 fsgid=636 comm="vsftpd" exe="/usr/sbin/vsftpd" > > Cant find what I should turn off in /etc/selinux/targeted/booleans to > make > it work. So I need a little help. Later, I want to upload files in > that dir > also. > > Also, Im not so sure that I like that I cant see alot of dirs when Im > logged in at the ftp. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list Is use_nfs_home_dirs boolean active? getsebool use_nfs_home_dirs use_nfs_home_dirs --> inactive -- From selinux at gmail.com Wed Aug 24 14:18:56 2005 From: selinux at gmail.com (Tom London) Date: Wed, 24 Aug 2005 07:18:56 -0700 Subject: NetworkManager: minor nit Message-ID: <4c4ba153050824071812a8accd@mail.gmail.com> Running targeted/enforcing, latest rawhide. I get the following AVC during boot: type=AVC msg=audit(1124890934.835:9): avc: denied { read } for pid=2734 comm="dhcdbd" name="dhclient-eth0.conf" dev=dm-0 ino=1276472 scontext=system_u:system_r:NetworkManager_t tcontext=system_u:object_r:dhcp_etc_t tclass=file type=SYSCALL msg=audit(1124890934.835:9): arch=40000003 syscall=33 success=no exit=-13 a0=bf9c1d48 a1=4 a2=bf9c21c8 a3=bf9c1d48 items=1 pid=2734 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="dhcdbd" exe="/sbin/dhcdbd" type=CWD msg=audit(1124890934.835:9): cwd="/" type=PATH msg=audit(1124890934.835:9): item=0 name="/etc/dhclient-eth0.conf" flags=401 inode=1276472 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 I have 2 files in /etc: /etc/dhclient-eth[01].conf, both are zero length, and both are labeled dhcp_etc_t. Changing the label for /sbin/dhcdbd from sbin_t -> dhcpc_exec_t makes this AVC vanish. Would it be 'better' to just add: allow NetworkManager_t dhcp_etc_t:file read; ? tom -- Tom London -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Wed Aug 24 15:31:31 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 24 Aug 2005 11:31:31 -0400 Subject: NetworkManager: minor nit In-Reply-To: <4c4ba153050824071812a8accd@mail.gmail.com> References: <4c4ba153050824071812a8accd@mail.gmail.com> Message-ID: <430C92D3.8080000@redhat.com> Tom London wrote: > Running targeted/enforcing, latest rawhide. > > I get the following AVC during boot: > > type=AVC msg=audit(1124890934.835:9): avc: denied { read } for > pid=2734 comm="dhcdbd" name="dhclient-eth0.conf " dev=dm-0 ino=1276472 > scontext=system_u:system_r:NetworkManager_t > tcontext=system_u:object_r:dhcp_etc_t tclass=file > type=SYSCALL msg=audit(1124890934.835:9): arch=40000003 syscall=33 > success=no exit=-13 a0=bf9c1d48 a1=4 a2=bf9c21c8 a3=bf9c1d48 items=1 > pid=2734 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="dhcdbd" exe="/sbin/dhcdbd" > type=CWD msg=audit(1124890934.835:9): cwd="/" > type=PATH msg=audit(1124890934.835:9): item=0 > name="/etc/dhclient-eth0.conf" flags=401 inode=1276472 dev=fd:00 > mode=0100644 ouid=0 ogid=0 rdev=00:00 > > I have 2 files in /etc: /etc/dhclient-eth[01].conf, both are zero > length, and both are labeled dhcp_etc_t. > > Changing the label for /sbin/dhcdbd from sbin_t -> dhcpc_exec_t makes > this AVC vanish. > This is the correct change. > Would it be 'better' to just add: > allow NetworkManager_t dhcp_etc_t:file read; > ? > > tom > -- > Tom London > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From catus.tw at yahoo.com.tw Fri Aug 26 08:41:31 2005 From: catus.tw at yahoo.com.tw (=?big5?q?=ACI=A4=E5=B4I?=) Date: Fri, 26 Aug 2005 16:41:31 +0800 (CST) Subject: how to make sure that selinux work properly?? Message-ID: <20050826084132.81254.qmail@web17701.mail.tpe.yahoo.com> dear all: I have install the SELinux on Fedora Core 4 But I seems can't feel any changes? if I have booleans: httpd_disable_trans=0 and I exec "service httpd restart" by root if the SELinuxi work well,will it be denied? and how could sure that the SELinux is working? thx. __________________________________________________ ?????????? ????Yahoo!?????? http://messenger.yahoo.com.tw/ From selinux at gmail.com Sat Aug 27 18:57:17 2005 From: selinux at gmail.com (Tom London) Date: Sat, 27 Aug 2005 11:57:17 -0700 Subject: targeted boot AVC: dbus ... Message-ID: <4c4ba1530508271157363d5ef8@mail.gmail.com> Running targeted/enforcing, latest rawhide: I get the following AVC on boot up: type=AVC msg=audit(1125167566.309:8): avc: denied { create } for pid=2538 comm="dbus-daemon" scontext=system_u:system_r:system_dbusd_t tcontext=system_u:system_r:system_dbusd_t tclass=netlink_audit_socket type=SYSCALL msg=audit(1125167566.309:8): arch=40000003 syscall=102 success=no exit=-13 a0=1 a1=bfa37400 a2=e770f8 a3=86b7698 items=0 pid=2538 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="dbus-daemon" exe="/usr/bin/dbus-daemon" type=SOCKETCALL msg=audit(1125167566.309:8): nargs=3 a0=10 a1=3 a2=9 Make sense to add allow system_dbusd_t self:netlink_audit_socket create_socket_perms; tom -- Tom London -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at gmail.com Sat Aug 27 19:00:01 2005 From: selinux at gmail.com (Tom London) Date: Sat, 27 Aug 2005 12:00:01 -0700 Subject: targeted boot AVC: ntpd Message-ID: <4c4ba1530508271200322f3bc@mail.gmail.com> Running targeted/enforcing, latest rawhide: On boot, ntpd produces the following: type=AVC msg=audit(1125168808.672:7): avc: denied { sys_resource } for pid=2431 comm="ntpd" capability=24 scontext=system_u:system_r:ntpd_t tcontext=system_u:system_r:ntpd_t tclass=capability type=SYSCALL msg=audit(1125168808.672:7): arch=40000003 syscall=75 success=no exit=-1 a0=8 a1=bfab4b18 a2=25cff4 a3=bfab4b18 items=0 pid=2431 auid=4294967295 uid=0 gid=0 euid=0 I can't figure if this should be an 'allow' or 'dontallow'. Help? tom [Otherwise, targeted boot on my system is completely clean.] -- Tom London -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at gmail.com Sat Aug 27 19:58:49 2005 From: selinux at gmail.com (Tom London) Date: Sat, 27 Aug 2005 12:58:49 -0700 Subject: differences between setfiles and restorecon? repeat of old thread? Message-ID: <4c4ba153050827125863378994@mail.gmail.com> Running targeted/enforcing, latest rawhide. I created a 'backup' of my root lvm2 partition, mounted the new partition as /mnt, and copied the files via 'cp -dpR / /mnt'. The copied files were all incorrectly labeled. (same result with cp --preserve=all'). I tried 'chroot /mnt; restorcon -v -R /', but it had no effect (returned immediately), as did any other resorecon attempted in the chroot'ed shell. 'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did the right thing. [Its almost as if restorecon is using the 'real' full pathname (with leading /mnt), and setfiles is using the 'chroot'ed' pathname (without the leading /mnt).] First, should the 'preserve' on cp have failed to copy the contexts? Second, why the difference in behavior between setfiles and restorecon in this context? Still curious, tom -- Tom London -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragoran at feuerpokemon.de Sun Aug 28 11:15:50 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 28 Aug 2005 13:15:50 +0200 Subject: ifconfig/pipefs avc messages. Message-ID: <43119CE6.8010208@feuerpokemon.de> I have found this messages in /var/log/audit/audit.log: > type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > for pid=3342 comm="ifconfig" name=[11205] dev=pipefs ino=11205 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371250.432:658540): avc: denied { read } for > pid=3342 comm="ifconfig" name=[11205] dev=pipefs ino=11205 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > for pid=3342 comm="ifconfig" name=[11203] dev=pipefs ino=11203 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371250.432:658540): avc: denied { read } for > pid=3342 comm="ifconfig" name=[11203] dev=pipefs ino=11203 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > for pid=3342 comm="ifconfig" name=[11202] dev=pipefs ino=11202 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371250.432:658540): avc: denied { read } for > pid=3342 comm="ifconfig" name=[11202] dev=pipefs ino=11202 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > for pid=3342 comm="ifconfig" name=[11201] dev=pipefs ino=11201 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371250.432:658540): avc: denied { read } for > pid=3342 comm="ifconfig" name=[11201] dev=pipefs ino=11201 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > for pid=3342 comm="ifconfig" name=[11687] dev=pipefs ino=11687 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > for pid=3342 comm="ifconfig" name=[11687] dev=pipefs ino=11687 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=PATH msg=audit(1120371251.502:661490): item=1 inode=2127845 > dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=PATH msg=audit(1120371251.502:661490): item=0 > name="/sbin/ifconfig" inode=9297060 dev=08:05 mode=0100755 ouid=0 > ogid=0 rdev=00:00 > type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11687]" > type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11687]" > type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11201]" > type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11201]" > type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11202]" > type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11202]" > type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11203]" > type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11203]" > type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11205]" > type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11205]" > type=SYSCALL msg=audit(1120371251.502:661490): arch=c000003e > syscall=59 success=yes exit=0 a0=627990 a1=627cb0 a2=608440 > a3=2aaaaaac5000 items=2 pid=3370 auid=4294967295 uid=0 gid=0 euid=0 > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifconfig" exe="/sbin/ifconfig" > type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > for pid=3370 comm="ifconfig" name=[11205] dev=pipefs ino=11205 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371251.502:661490): avc: denied { read } for > pid=3370 comm="ifconfig" name=[11205] dev=pipefs ino=11205 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > for pid=3370 comm="ifconfig" name=[11203] dev=pipefs ino=11203 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371251.502:661490): avc: denied { read } for > pid=3370 comm="ifconfig" name=[11203] dev=pipefs ino=11203 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > for pid=3370 comm="ifconfig" name=[11202] dev=pipefs ino=11202 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371251.502:661490): avc: denied { read } for > pid=3370 comm="ifconfig" name=[11202] dev=pipefs ino=11202 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > for pid=3370 comm="ifconfig" name=[11201] dev=pipefs ino=11201 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371251.502:661490): avc: denied { read } for > pid=3370 comm="ifconfig" name=[11201] dev=pipefs ino=11201 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > for pid=3370 comm="ifconfig" name=[11687] dev=pipefs ino=11687 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > for pid=3370 comm="ifconfig" name=[11687] dev=pipefs ino=11687 > scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > tclass=fifo_file > type=PATH msg=audit(1120371251.510:662032): item=1 inode=2127845 > dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=PATH msg=audit(1120371251.510:662032): item=0 name="/sbin/ip" > inode=9297052 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 I did fixfiles relabel but it have'nt fixed them. Whats the problem? bug in the policy? (using fc4 and selinux-policy-targeted-1.25.3-12) From gajownik at fedora.pl Sun Aug 28 16:09:46 2005 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sun, 28 Aug 2005 18:09:46 +0200 Subject: vsftpd and ~/public_html Message-ID: <4311E1CA.8070908@fedora.pl> Hi! I have silly problem: I'm not able to enter ~/public_html directory using ftp client. I found this AVC messages in /var/log/audit/audit.log: type=AVC msg=audit(1125243640.479:279): avc: denied { search } for pid=10731 comm="vsftpd" name="public_html" dev=hda6 ino=229557 scontext=root:system_r:ftpd_t tcontext=system_u:object_r:httpd_sys_content_t tclass=dir type=SYSCALL msg=audit(1125243640.479:279): arch=40000003 syscall=12 success=no exit=-13 a0=8927908 a1=0 a2=fd2524 a3=bfbfa5bc items=1 pid=10731 auid=4294967295 uid=500 gid=100 euid=500 suid=500 fsuid=500 egid=100 sgid=100 fsgid=100 comm="vsftpd" exe="/usr/sbin/vsftpd" type=CWD msg=audit(1125243640.479:279): cwd="/home/y4kk0" type=PATH msg=audit(1125243640.479:279): item=0 name="public_html" flags=3 inode=229557 dev=03:06 mode=040777 ouid=500 ogid=100 rdev=00:00 [y4kk0 at X ~]$ ls -Zd public_html/ drwxrwxrwx y4kk0 users system_u:object_r:httpd_user_content_t public_html/ [y4kk0 at X ~]$ selinux-policy-targeted-1.25.4-10 system: Fedora Core 4 Maybe default policy should allow ftp server to enter this directory so users would be able to upload their WWW stuff via ftp? Regards, Dawid Gajownik -- ^_* From eric.tanguy at univ-nantes.fr Sun Aug 28 20:43:48 2005 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Sun, 28 Aug 2005 22:43:48 +0200 Subject: cgiirc In-Reply-To: <1124354525.3100.13.camel@bureau.maison> References: <1124354525.3100.13.camel@bureau.maison> Message-ID: <1125261829.3097.1.camel@bureau.maison> Le jeudi 18 ao?t 2005 ? 10:42 +0200, Eric Tanguy a ?crit : > I try to make cgiirc working on my system. Apache works fine and selinux > Allow HTTPD scripts to connect to the network is enable. So i can cgiirc > to connect to an irc server. I can see what is said on the channel but i > can't make any action. If i disable selinux all works fine. If i enable > selinux i have this in /var/log/audit/audit.log : > type=AVC msg=audit(1124298167.251:3778508): avc: denied { read } for > pid=3907 comm="irc.cgi" name="formats" dev=dm-0 ino=8323109 > scontext=system_u:system_r:httpd_sys_script_t > tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir > type=SYSCALL msg=audit(1124298167.251:3778508): arch=40000003 syscall=5 > success=no exit=-13 a0=94586b8 a1=18800 a2=94586b8 a3=9430fe0 items=1 > pid=3907 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 > sgid=48 fsgid=48 comm="irc.cgi" exe="/usr/bin/perl" > type=CWD msg=audit(1124298167.251:3778508): > cwd="/var/www/cgi-bin/cgiirc" > type=PATH msg=audit(1124298167.251:3778508): item=0 name="formats" > flags=103 inode=8323109 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1124298171.144:3812320): avc: denied { connectto } > for pid=3922 comm="client-perl.cgi" name="sock" > scontext=system_u:system_r:httpd_sys_script_t > tcontext=system_u:system_r:httpd_sys_script_t tclass=unix_stream_socket > type=SYSCALL msg=audit(1124298171.144:3812320): arch=40000003 > syscall=102 success=no exit=-13 a0=3 a1=bfc86690 a2=45b3bc0 a3=6e > items=1 pid=3922 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 > egid=48 sgid=48 fsgid=48 comm="client-perl.cgi" exe="/usr/bin/perl" > type=AVC_PATH msg=audit(1124298171.144:3812320): > path="/tmp/cgiirc-0coinr388dt/sock" > type=SOCKADDR msg=audit(1124298171.144:3812320): > saddr=01002F746D702F6367696972632D30636F696E7233383864742F736F636B0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > > But it's very difficult to understand where is the problem. > Someone could help me? > Thanks > Noone could help me with this problem ? -- Eric Tanguy | Nantes, France Key : A4B8368F | Key Server : subkeys.pgp.net Fedora Core release 4 (Stentz) sur athlon kernel 2.6.12-1.1398_FC4 From iocc at fedora-selinux.lists.flashdance.cx Mon Aug 29 00:18:45 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Mon, 29 Aug 2005 02:18:45 +0200 (CEST) Subject: cant create dirs from vsftpd In-Reply-To: <200508220310.j7M3AKPs015070@turing-police.cc.vt.edu> References: <200508220310.j7M3AKPs015070@turing-police.cc.vt.edu> Message-ID: On Sun, 21 Aug 2005, Valdis.Kletnieks at vt.edu wrote: > On Mon, 22 Aug 2005 04:23:30 +0200, Peter Magnusson said: > >> Also, Im not so sure that I like that I cant see alot of dirs when Im >> logged in at the ftp. > > Give specific examples, and why you think FTP should be able to see that system dirs, like /bin in the root and a few dirs and files in my homedir. > dir? Most security people would consider this behavior in general a > feature rather than a bug - but if there's a *specific* corner case that > needs different treatment, we probably can fix it. I expect to see the same files as when I login over ssh or sits in front of the computer. I dont see why vsftpd should be special in any way so I dont see some dirs or files. From iocc at fedora-selinux.lists.flashdance.cx Mon Aug 29 00:22:29 2005 From: iocc at fedora-selinux.lists.flashdance.cx (Peter Magnusson) Date: Mon, 29 Aug 2005 02:22:29 +0200 (CEST) Subject: cant create dirs from vsftpd In-Reply-To: <430B3137.3040903@redhat.com> References: <430B3137.3040903@redhat.com> Message-ID: On Tue, 23 Aug 2005, Daniel J Walsh wrote: >> selinux-policy-targeted-1.25.3-9 in FC4 surely isnt perfect. Cant create >> dirs when I login over ftp: <...> >> Cant find what I should turn off in /etc/selinux/targeted/booleans to make >> it work. So I need a little help. Later, I want to upload files in that dir >> also. >> Also, Im not so sure that I like that I cant see alot of dirs when Im >> logged in at the ftp. > Is use_nfs_home_dirs boolean active? > getsebool use_nfs_home_dirs > use_nfs_home_dirs --> inactive I disabled selinux to make it work so I cant use getsebool but in /etc/selinux/targeted/booleans it says use_nfs_home_dirs=0 so I guess its inactive? My homedir isnt shared over NFS but sometimes I mount NFS shares in some dirs in it. From dragoran at feuerpokemon.de Mon Aug 29 06:22:50 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 29 Aug 2005 08:22:50 +0200 Subject: ifconfig/pipefs avc messages. In-Reply-To: <43119CE6.8010208@feuerpokemon.de> References: <43119CE6.8010208@feuerpokemon.de> Message-ID: <4312A9BA.6090200@feuerpokemon.de> dragoran wrote: > I have found this messages in /var/log/audit/audit.log: > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> for pid=3342 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >> for pid=3342 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> for pid=3342 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >> for pid=3342 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> for pid=3342 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >> for pid=3342 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> for pid=3342 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >> for pid=3342 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> for pid=3342 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> for pid=3342 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=PATH msg=audit(1120371251.502:661490): item=1 inode=2127845 >> dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 >> type=PATH msg=audit(1120371251.502:661490): item=0 >> name="/sbin/ifconfig" inode=9297060 dev=08:05 mode=0100755 ouid=0 >> ogid=0 rdev=00:00 >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11687]" >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11687]" >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11201]" >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11201]" >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11202]" >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11202]" >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11203]" >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11203]" >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11205]" >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11205]" >> type=SYSCALL msg=audit(1120371251.502:661490): arch=c000003e >> syscall=59 success=yes exit=0 a0=627990 a1=627cb0 a2=608440 >> a3=2aaaaaac5000 items=2 pid=3370 auid=4294967295 uid=0 gid=0 euid=0 >> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifconfig" >> exe="/sbin/ifconfig" >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> for pid=3370 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >> for pid=3370 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> for pid=3370 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >> for pid=3370 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> for pid=3370 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >> for pid=3370 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> for pid=3370 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >> for pid=3370 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> for pid=3370 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> for pid=3370 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> tclass=fifo_file >> type=PATH msg=audit(1120371251.510:662032): item=1 inode=2127845 >> dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 >> type=PATH msg=audit(1120371251.510:662032): item=0 name="/sbin/ip" >> inode=9297052 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 > > > I did fixfiles relabel but it have'nt fixed them. > Whats the problem? > bug in the policy? (using fc4 and selinux-policy-targeted-1.25.3-12) > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > found out that iplugd from fc extras was causing this. its labeled as: > ls -Z /usr/sbin/ifplugd > -rwxr-xr-x root root system_u:object_r:sbin_t > /usr/sbin/ifplugd From jmblin at comcast.net Mon Aug 29 07:24:51 2005 From: jmblin at comcast.net (John Bray) Date: Mon, 29 Aug 2005 02:24:51 -0500 Subject: seaudit working? Message-ID: <1125300291.13745.4.camel@junior> i'd thought that seaudit was currently working again. but when i just ran it, it coredumped. this seaudit: setools-gui-2.1.1-2 so, do we think it's working now? or was i just imagining things? john thus: [root at junior ~]# seaudit *** glibc detected *** seaudit: realloc(): invalid next size: 0x0ca74d50 *** ======= Backtrace: ========= /lib/libc.so.6[0x166045] /lib/libc.so.6(__libc_realloc+0x101)[0x166a30] seaudit(add_cond_expr_item+0x5e)[0x8072bfe] seaudit[0x808449d] seaudit(ap_read_binpol_file+0xdd0)[0x8086b9c] seaudit(open_partial_policy+0x1b1)[0x80753e1] seaudit(seaudit_open_policy+0x13e)[0x80572d2] seaudit(delayed_main+0x53)[0x805773f] /usr/lib/libglib-2.0.so.0[0x4c5650] /usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x1dc)[0x4c33ee] /usr/lib/libglib-2.0.so.0[0x4c63f6] /usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1a1)[0x4c66e3] /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb4)[0x24691b5] seaudit(main+0x2fc)[0x8057af4] /lib/libc.so.6(__libc_start_main+0xdf)[0x115d5f] seaudit[0x8052f15] ======= Memory map: ======== 00101000-00224000 r-xp 00000000 fd:00 41846498 /lib/libc-2.3.5.so 00224000-00226000 r-xp 00123000 fd:00 41846498 /lib/libc-2.3.5.so 00226000-00228000 rwxp 00125000 fd:00 41846498 /lib/libc-2.3.5.so 00228000-0022a000 rwxp 00228000 00:00 0 0022c000-002fc000 r-xp 00000000 fd:00 20600920 /usr/X11R6/lib/libX11.so.6.2 002fc000-00300000 rwxp 000cf000 fd:00 20600920 /usr/X11R6/lib/libX11.so.6.2 00302000-00363000 r-xp 00000000 fd:00 20602246 /usr/lib/libfreetype.so.6.3.7 00363000-0036a000 rwxp 00061000 fd:00 20602246 /usr/lib/libfreetype.so.6.3.7 0036c000-00392000 r-xp 00000000 fd:00 20602248 /usr/lib/libfontconfig.so.1.0.400392000-00395000 rwxp 00026000 fd:00 20602248 /usr/lib/libfontconfig.so.1.0.400395000-00396000 rwxp 00395000 00:00 0 00398000-003aa000 r-xp 00000000 fd:00 20602249 /usr/X11R6/lib/libXft.so.2.1.2 003aa000-003ab000 rwxp 00012000 fd:00 20602249 /usr/X11R6/lib/libXft.so.2.1.2 003ad000-003b0000 r-xp 00000000 fd:00 20601972 /usr/X11R6/lib/libXrandr.so.2.0003b0000-003b1000 rwxp 00002000 fd:00 20601972 /usr/X11R6/lib/libXrandr.so.2.0003b1000-003ba000 r-xp 00000000 fd:00 41844788 /lib/libnss_files-2.3.5.so 003ba000-003bb000 r-xp 00008000 fd:00 41844788 /lib/libnss_files-2.3.5.so 003bb000-003bc000 rwxp 00009000 fd:00 41844788 /lib/libnss_files-2.3.5.so 003bc000-003bf000 r-xp 00000000 fd:00 20975411 /usr/lib/libglade/2.0/libbonobo.so 003bf000-003c0000 rwxp 00002000 fd:00 20975411 /usr/lib/libglade/2.0/libbonobo.so 003c0000-003d0000 r-xp 00000000 fd:00 20810680 /usr/lib/gtk-2.0/2.4.0/engines/libclearlooks.so 003d0000-003d1000 rwxp 0000f000 fd:00 20810680 /usr/lib/gtk-2.0/2.4.0/engines/libclearlooks.so 003d1000-003d3000 r-xp 00000000 fd:00 20809948 /usr/lib/pango/1.4.0/modules/pango-basic-fc.so 003d3000-003d4000 rwxp 00001000 fd:00 20809948 /usr/lib/pango/1.4.0/modules/pango-basic-fc.so 003d4000-003d8000 r-xp 00000000 fd:00 20810008 /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so 003d8000-003d9000 rwxp 00003000 fd:00 20810008 /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so 004a0000-00524000 r-xp 00000000 fd:00 20598948 /usr/lib/libglib-2.0.so.0.600.400524000-00529000 rwxp 00084000 fd:00 20598948 /usr/lib/libglib-2.0.so.0.600.40052b000-0052e000 r-xp 00000000 fd:00 20600450 /usr/lib/libgmodule-2.0.so.0.600.4 0052e000-0052f000 rwxp 00002000 fd:00 20600450 /usr/lib/libgmodule-2.0.so.0.600.4 00532000-0054c000 r-xp 00000000 fd:00 41844829 /lib/ld-2.3.5.so 0054c000-0054d000 r-xp 00019000 fd:00 41844829 /lib/ld-2.3.5.so 0054d000-0054e000 rwxp 0001a000 fd:00 41844829 /lib/ld-2.3.5.so 00550000-00552000 r-xp 00000000 fd:00 41846519 /lib/libcom_err.so.2.1 00552000-00553000 rwxp 00001000 fd:00 41846519 /lib/libcom_err.so.2.1 00555000-0064d000 r-xp 00000000 fd:00 41846520 /lib/libcrypto.so.0.9.7f 0064d000-0065f000 rwxp 000f8000 fd:00 41846520 /lib/libcrypto.so.0.9.7f 0065f000-00662000 rwxp 0065f000 00:00 0 00664000-00666000 r-xp 00000000 fd:00 20588090 /usr/lib/libkrb5support.so.0.0 00666000-00667000 rwxp 00001000 fd:00 20588090 /usr/lib/libkrb5support.so.0.0 00669000-0068c000 r-xp 00000000 fd:00 20602270 /usr/lib/libk5crypto.so.3.0 0068c000-0068d000 rwxp 00023000 fd:00 20602270 /usr/lib/libk5crypto.so.3.0 0068f000-006fe000 r-xp 00000000 fd:00 20602271 /usr/lib/libkrb5.so.3.2 006fe000-00701000 rwxp 0006e000 fd:00 20602271 /usr/lib/libkrb5.so.3.2 00703000-0071a000 r-xp 00000000 fd:00 20602272 /usr/lib/libgssapi_krb5.so.2.2 0071a000-0071b000 rwxp 00017000 fd:00 20602272 /usr/lib/libgssapi_krb5.so.2.2 0071d000-00752000 r-xp 00000000 fd:00 41846521 /lib/libssl.so.0.9.7f 00752000-00755000 rwxp 00035000 fd:00 41846521 /lib/libssl.so.0.9.7f 00757000-0075e000 r-xp 00000000 fd:00 20602287 /usr/lib/libpopt.so.0.0.0 0075e000-0075f000 rwxp 00006000 fd:00 20602287 /usr/lib/libpopt.so.0.0.0 00761000-00874000 r-xp 00000000 fd:00 20602344 /usr/lib/libxml2.so.2.6.20 00874000-0087c000 rwxp Aborted [root at junior ~]# From dwalsh at redhat.com Mon Aug 29 12:58:46 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 29 Aug 2005 08:58:46 -0400 Subject: targeted boot AVC: dbus ... In-Reply-To: <4c4ba1530508271157363d5ef8@mail.gmail.com> References: <4c4ba1530508271157363d5ef8@mail.gmail.com> Message-ID: <43130686.5000903@redhat.com> Tom London wrote: > Running targeted/enforcing, latest rawhide: > > I get the following AVC on boot up: > > type=AVC msg=audit(1125167566.309:8): avc: denied { create } for > pid=2538 comm="dbus-daemon" scontext=system_u:system_r:system_dbusd_t > tcontext=system_u:system_r:system_dbusd_t tclass=netlink_audit_socket > type=SYSCALL msg=audit(1125167566.309:8): arch=40000003 syscall=102 > success=no exit=-13 a0=1 a1=bfa37400 a2=e770f8 a3=86b7698 items=0 > pid=2538 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 > sgid=0 fsgid=0 comm="dbus-daemon" exe="/usr/bin/dbus-daemon" > type=SOCKETCALL msg=audit(1125167566.309:8): nargs=3 a0=10 a1=3 a2=9 > > Make sense to add > allow system_dbusd_t self:netlink_audit_socket create_socket_perms; > In *selinux-policy-targeted-1.25.4-10* > tom > -- > Tom London > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From sds at tycho.nsa.gov Mon Aug 29 13:33:18 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 29 Aug 2005 09:33:18 -0400 Subject: differences between setfiles and restorecon? repeat of old thread? In-Reply-To: <4c4ba153050827125863378994@mail.gmail.com> References: <4c4ba153050827125863378994@mail.gmail.com> Message-ID: <1125322398.2179.48.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2005-08-27 at 12:58 -0700, Tom London wrote: > Running targeted/enforcing, latest rawhide. > > I created a 'backup' of my root lvm2 partition, mounted the new > partition as /mnt, and copied the files via 'cp -dpR / /mnt'. > > The copied files were all incorrectly labeled. (same result with cp > --preserve=all'). > > I tried 'chroot /mnt; restorcon -v -R /', but it had no effect > (returned immediately), as did any other resorecon attempted in the > chroot'ed shell. > > 'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did > the right thing. > > [Its almost as if restorecon is using the 'real' full pathname (with > leading /mnt), and setfiles is using the 'chroot'ed' pathname (without > the leading /mnt).] > > First, should the 'preserve' on cp have failed to copy the contexts? > Second, why the difference in behavior between setfiles and restorecon > in this context? Good questions. I know that at one time, there was debate over whether cp should ever preserve security contexts without use of an explicit option to that effect, as it might otherwise break existing users (because a process that may be able to preserve all of the DAC attributes might not be able to preserve the MAC label). However, it does seem unfortunate that a --preserve=all doesn't give you the intuitive result. I'm not sure what the right answer is there. With regard to restorecon, a long time ago, Dan added a test on entry to it to immediately exit if SELinux wasn't enabled so that it could be safely called from the rc scripts regardless of whether SELinux was enabled or disabled. Since you are running it in a chroot environment, is_selinux_enabled will always fail because it cannot check /proc/filesystems for selinuxfs, so restorecon thinks that SELinux is disabled and exits silently. Possibly that should be removed or at least display a warning. setfiles runs regardless of whether SELinux is enabled or disabled. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon Aug 29 13:42:14 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 29 Aug 2005 09:42:14 -0400 Subject: differences between setfiles and restorecon? repeat of old thread? In-Reply-To: <4c4ba153050827125863378994@mail.gmail.com> References: <4c4ba153050827125863378994@mail.gmail.com> Message-ID: <1125322934.2179.52.camel@moss-spartans.epoch.ncsc.mil> On Sat, 2005-08-27 at 12:58 -0700, Tom London wrote: > 'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did > the right thing. > > [Its almost as if restorecon is using the 'real' full pathname (with > leading /mnt), and setfiles is using the 'chroot'ed' pathname (without > the leading /mnt).] BTW, I'm not sure what you mean by the above. setfiles does accept a -r option to specify an alternate root path, so you can apply it to a chroot setup without running it chroot'd itself. But without that option, I wouldn't have expected it to touch /mnt at all, especially as file_contexts marks it <>. -- Stephen Smalley National Security Agency From selinux at gmail.com Mon Aug 29 13:57:01 2005 From: selinux at gmail.com (Tom London) Date: Mon, 29 Aug 2005 06:57:01 -0700 Subject: differences between setfiles and restorecon? repeat of old thread? In-Reply-To: <1125322934.2179.52.camel@moss-spartans.epoch.ncsc.mil> References: <4c4ba153050827125863378994@mail.gmail.com> <1125322934.2179.52.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4c4ba153050829065725541737@mail.gmail.com> On 8/29/05, Stephen Smalley wrote: > > On Sat, 2005-08-27 at 12:58 -0700, Tom London wrote: > > 'setfiles -v /etc/selinux/targeted/contexts/files/file_contexts /' did > > the right thing. > > > > [Its almost as if restorecon is using the 'real' full pathname (with > > leading /mnt), and setfiles is using the 'chroot'ed' pathname (without > > the leading /mnt).] > > BTW, I'm not sure what you mean by the above. setfiles does accept a -r > option to specify an alternate root path, so you can apply it to a > chroot setup without running it chroot'd itself. But without that > option, I wouldn't have expected it to touch /mnt at all, especially as > file_contexts marks it <>. First, thanks for the explanation. My comment regarding 'real' vs. 'chroot-ed' pathnames was just my feeble poke at explaning what was going on. I had noticed the entry for /mnt in file_contexts, and concluded that 1+1=3. ;) Regarding setfiles, thanks for the info regarding '-r' option. Its not in the man page nor in 'setfiles --help', so I did the 'chroot' balancing act. 'setfiles -r' produces 'usage: setfiles -r rootpath' though. tom -- Tom London -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcarr at tresys.com Mon Aug 29 14:41:26 2005 From: kcarr at tresys.com (Kevin Carr) Date: Mon, 29 Aug 2005 10:41:26 -0400 Subject: seaudit working? In-Reply-To: <1125300291.13745.4.camel@junior> Message-ID: <200508291441.j7TEfWss030677@gotham.columbia.tresys.com> > i'd thought that seaudit was currently working again. but when i just > ran it, it coredumped. It appears you have come across a different bug than was previously posted. > this seaudit: setools-gui-2.1.1-2 > > so, do we think it's working now? or was i just imagining things? I apologize for the confusion. Setools-2.1.1 fixed a similar problem to the one you are experiencing. We actually found your bug and fixed it last week and we are very close to releasing setools-2.1.2. This release will contain the fix to your problem. The release will also add support for parsing avc messages in auditd log files, something I had inadvertently and mistakenly said was supported in setools-2.1.1. > john > > Kevin Carr Tresys Technology From lamont at gurulabs.com Mon Aug 29 16:25:16 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Mon, 29 Aug 2005 10:25:16 -0600 Subject: cant create dirs from vsftpd In-Reply-To: References: <200508220310.j7M3AKPs015070@turing-police.cc.vt.edu> Message-ID: <200508291025.21447.lamont@gurulabs.com> On Sunday 28 August 2005 06:18pm, Peter Magnusson wrote: > On Sun, 21 Aug 2005, Valdis.Kletnieks at vt.edu wrote: > > On Mon, 22 Aug 2005 04:23:30 +0200, Peter Magnusson said: > >> Also, Im not so sure that I like that I cant see alot of dirs when Im > >> logged in at the ftp. > > > > Give specific examples, and why you think FTP should be able to see that > > system dirs, like /bin in the root and a few dirs and files in my homedir. > > > dir? Most security people would consider this behavior in general a > > feature rather than a bug - but if there's a *specific* corner case that > > needs different treatment, we probably can fix it. > > I expect to see the same files as when I login over ssh or sits in front of > the computer. I dont see why vsftpd should be special in any way so I dont > see some dirs or files. Perhaps, I'm just a little bit confused. Are you wanting your FTP server to provide access to the entire filesystem space? It seems like that is what you are asking for and that is not how FTP works. FTP like HTTP serves up files only from a subset of the filesystem space. You wouldn't want your web server providing access to the entire filesystem, would you? The same is true of FTP. Please, if I am misunderstanding what you are trying to accomplish here, feel free to explain it. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dwalsh at redhat.com Mon Aug 29 17:00:13 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 29 Aug 2005 13:00:13 -0400 Subject: ifconfig/pipefs avc messages. In-Reply-To: <4312A9BA.6090200@feuerpokemon.de> References: <43119CE6.8010208@feuerpokemon.de> <4312A9BA.6090200@feuerpokemon.de> Message-ID: <43133F1D.5030209@redhat.com> dragoran wrote: > dragoran wrote: > > > I have found this messages in /var/log/audit/audit.log: > > > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > >> for pid=3342 comm="ifconfig" name=[11205] dev=pipefs ino=11205 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } > >> for pid=3342 comm="ifconfig" name=[11205] dev=pipefs ino=11205 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > >> for pid=3342 comm="ifconfig" name=[11203] dev=pipefs ino=11203 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } > >> for pid=3342 comm="ifconfig" name=[11203] dev=pipefs ino=11203 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > >> for pid=3342 comm="ifconfig" name=[11202] dev=pipefs ino=11202 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } > >> for pid=3342 comm="ifconfig" name=[11202] dev=pipefs ino=11202 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > >> for pid=3342 comm="ifconfig" name=[11201] dev=pipefs ino=11201 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } > >> for pid=3342 comm="ifconfig" name=[11201] dev=pipefs ino=11201 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > >> for pid=3342 comm="ifconfig" name=[11687] dev=pipefs ino=11687 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } > >> for pid=3342 comm="ifconfig" name=[11687] dev=pipefs ino=11687 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=PATH msg=audit(1120371251.502:661490): item=1 inode=2127845 > >> dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 > >> type=PATH msg=audit(1120371251.502:661490): item=0 > >> name="/sbin/ifconfig" inode=9297060 dev=08:05 mode=0100755 ouid=0 > >> ogid=0 rdev=00:00 > >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11687]" > >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11687]" > >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11201]" > >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11201]" > >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11202]" > >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11202]" > >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11203]" > >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11203]" > >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11205]" > >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11205]" > >> type=SYSCALL msg=audit(1120371251.502:661490): arch=c000003e > >> syscall=59 success=yes exit=0 a0=627990 a1=627cb0 a2=608440 > >> a3=2aaaaaac5000 items=2 pid=3370 auid=4294967295 uid=0 gid=0 euid=0 > >> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifconfig" > >> exe="/sbin/ifconfig" > >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > >> for pid=3370 comm="ifconfig" name=[11205] dev=pipefs ino=11205 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } > >> for pid=3370 comm="ifconfig" name=[11205] dev=pipefs ino=11205 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > >> for pid=3370 comm="ifconfig" name=[11203] dev=pipefs ino=11203 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } > >> for pid=3370 comm="ifconfig" name=[11203] dev=pipefs ino=11203 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > >> for pid=3370 comm="ifconfig" name=[11202] dev=pipefs ino=11202 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } > >> for pid=3370 comm="ifconfig" name=[11202] dev=pipefs ino=11202 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > >> for pid=3370 comm="ifconfig" name=[11201] dev=pipefs ino=11201 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } > >> for pid=3370 comm="ifconfig" name=[11201] dev=pipefs ino=11201 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > >> for pid=3370 comm="ifconfig" name=[11687] dev=pipefs ino=11687 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } > >> for pid=3370 comm="ifconfig" name=[11687] dev=pipefs ino=11687 > >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t > >> tclass=fifo_file > >> type=PATH msg=audit(1120371251.510:662032): item=1 inode=2127845 > >> dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 > >> type=PATH msg=audit(1120371251.510:662032): item=0 name="/sbin/ip" > >> inode=9297052 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 > > > > > > I did fixfiles relabel but it have'nt fixed them. > > Whats the problem? > > bug in the policy? (using fc4 and selinux-policy-targeted-1.25.3-12) > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > found out that iplugd from fc extras was causing this. > its labeled as: > > > ls -Z /usr/sbin/ifplugd > > -rwxr-xr-x root root system_u:object_r:sbin_t > > /usr/sbin/ifplugd > Could you label this NetworkManager_exec_t? And do a restart? Do the messages go away? > > > > -- > 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 Aug 29 17:04:42 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 29 Aug 2005 13:04:42 -0400 Subject: vsftpd and ~/public_html In-Reply-To: <4311E1CA.8070908@fedora.pl> References: <4311E1CA.8070908@fedora.pl> Message-ID: <4313402A.6010202@redhat.com> Dawid Gajownik wrote: > Hi! > > I have silly problem: I'm not able to enter ~/public_html > directory using ftp client. I found this AVC messages in > /var/log/audit/audit.log: > > type=AVC msg=audit(1125243640.479:279): avc: denied { search } for > pid=10731 comm="vsftpd" name="public_html" dev=hda6 ino=229557 > scontext=root:system_r:ftpd_t > tcontext=system_u:object_r:httpd_sys_content_t tclass=dir > type=SYSCALL msg=audit(1125243640.479:279): arch=40000003 syscall=12 > success=no exit=-13 a0=8927908 a1=0 a2=fd2524 a3=bfbfa5bc items=1 > pid=10731 auid=4294967295 uid=500 gid=100 euid=500 suid=500 fsuid=500 > egid=100 sgid=100 fsgid=100 comm="vsftpd" exe="/usr/sbin/vsftpd" > type=CWD msg=audit(1125243640.479:279): cwd="/home/y4kk0" > type=PATH msg=audit(1125243640.479:279): item=0 name="public_html" > flags=3 inode=229557 dev=03:06 mode=040777 ouid=500 ogid=100 rdev=00:00 > > [y4kk0 at X ~]$ ls -Zd public_html/ > drwxrwxrwx y4kk0 users system_u:object_r:httpd_user_content_t > public_html/ > [y4kk0 at X ~]$ > > selinux-policy-targeted-1.25.4-10 > system: Fedora Core 4 > > Maybe default policy should allow ftp server to enter this directory > so users would be able to upload their WWW stuff via ftp? > > Regards, > Dawid Gajownik > Sounds reasonable, I will add it. -- From dwalsh at redhat.com Mon Aug 29 17:09:33 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 29 Aug 2005 13:09:33 -0400 Subject: cgiirc In-Reply-To: <1125261829.3097.1.camel@bureau.maison> References: <1124354525.3100.13.camel@bureau.maison> <1125261829.3097.1.camel@bureau.maison> Message-ID: <4313414D.2000901@redhat.com> Eric Tanguy wrote: >Le jeudi 18 ao?t 2005 ? 10:42 +0200, Eric Tanguy a ?crit : > > >>I try to make cgiirc working on my system. Apache works fine and selinux >>Allow HTTPD scripts to connect to the network is enable. So i can cgiirc >>to connect to an irc server. I can see what is said on the channel but i >>can't make any action. If i disable selinux all works fine. If i enable >>selinux i have this in /var/log/audit/audit.log : >>type=AVC msg=audit(1124298167.251:3778508): avc: denied { read } for >>pid=3907 comm="irc.cgi" name="formats" dev=dm-0 ino=8323109 >>scontext=system_u:system_r:httpd_sys_script_t >>tcontext=system_u:object_r:httpd_sys_script_exec_t tclass=dir >>type=SYSCALL msg=audit(1124298167.251:3778508): arch=40000003 syscall=5 >>success=no exit=-13 a0=94586b8 a1=18800 a2=94586b8 a3=9430fe0 items=1 >>pid=3907 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 >>sgid=48 fsgid=48 comm="irc.cgi" exe="/usr/bin/perl" >>type=CWD msg=audit(1124298167.251:3778508): >>cwd="/var/www/cgi-bin/cgiirc" >>type=PATH msg=audit(1124298167.251:3778508): item=0 name="formats" >>flags=103 inode=8323109 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 >>type=AVC msg=audit(1124298171.144:3812320): avc: denied { connectto } >>for pid=3922 comm="client-perl.cgi" name="sock" >>scontext=system_u:system_r:httpd_sys_script_t >>tcontext=system_u:system_r:httpd_sys_script_t tclass=unix_stream_socket >>type=SYSCALL msg=audit(1124298171.144:3812320): arch=40000003 >>syscall=102 success=no exit=-13 a0=3 a1=bfc86690 a2=45b3bc0 a3=6e >>items=1 pid=3922 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 >>egid=48 sgid=48 fsgid=48 comm="client-perl.cgi" exe="/usr/bin/perl" >>type=AVC_PATH msg=audit(1124298171.144:3812320): >>path="/tmp/cgiirc-0coinr388dt/sock" >>type=SOCKADDR msg=audit(1124298171.144:3812320): >>saddr=01002F746D702F6367696972632D30636F696E7233383864742F736F636B0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 >> >>But it's very difficult to understand where is the problem. >>Someone could help me? >>Thanks >> >> >> > >Noone could help me with this problem ? > > > Are you running the latest policy. Both of these problems are fixed in it. >-- >Eric Tanguy | Nantes, France > >Key : A4B8368F | Key Server : subkeys.pgp.net >Fedora Core release 4 (Stentz) sur athlon kernel 2.6.12-1.1398_FC4 > > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > -- From gnu at wraith.sf.ca.us Mon Aug 29 18:14:22 2005 From: gnu at wraith.sf.ca.us (gnu not unix) Date: Mon, 29 Aug 2005 11:14:22 -0700 Subject: ftp upload, was Re: vsftpd and ~/public_html In-Reply-To: Your message of "Mon, 29 Aug 2005 13:04:42 EDT." <4313402A.6010202@redhat.com> Message-ID: <200508291814.j7TIEMeh031119@ring.wraith.sf.ca.us> >> [y4kk0 at X ~]$ ls -Zd public_html/ >> drwxrwxrwx y4kk0 users system_u:object_r:httpd_user_content_t >> public_html/ >> [y4kk0 at X ~]$ >> selinux-policy-targeted-1.25.4-10 >> system: Fedora Core 4 >> Maybe default policy should allow ftp server to enter this directory >> so users would be able to upload their WWW stuff via ftp? >Sounds reasonable, I will add it. Ouch, this seems like opening up an attack vector to me. Shouldn't ftp *upload* be to a write-only "holding cell" at least? ../Steven From dwalsh at redhat.com Mon Aug 29 19:42:02 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 29 Aug 2005 15:42:02 -0400 Subject: ftp upload, was Re: vsftpd and ~/public_html In-Reply-To: <200508291814.j7TIEMeh031119@ring.wraith.sf.ca.us> References: <200508291814.j7TIEMeh031119@ring.wraith.sf.ca.us> Message-ID: <4313650A.3000609@redhat.com> gnu not unix wrote: >>>[y4kk0 at X ~]$ ls -Zd public_html/ >>>drwxrwxrwx y4kk0 users system_u:object_r:httpd_user_content_t >>>public_html/ >>>[y4kk0 at X ~]$ >>> >>> > > > >>>selinux-policy-targeted-1.25.4-10 >>>system: Fedora Core 4 >>> >>> > > > >>>Maybe default policy should allow ftp server to enter this directory >>>so users would be able to upload their WWW stuff via ftp? >>> >>> > > > >>Sounds reasonable, I will add it. >> >> > >Ouch, this seems like opening up an attack vector to me. >Shouldn't ftp *upload* be to a write-only "holding cell" >at least? > >../Steven > This is only for ftp being allowed to modify users homedirs. If the user sets boolean ftp_home_dir then the user can modify and read most contents of the users home dir. This just adds public_html. If you want to protect the users home dir from ftp, I would not turn on that boolean. Without this change a hacker could put something in the .bashrc or other startup files and next time the real user logs in it would manipulate the public_html directory. -- From fedora at grifent.com Mon Aug 29 19:48:54 2005 From: fedora at grifent.com (John Griffiths) Date: Mon, 29 Aug 2005 15:48:54 -0400 Subject: selinux-policy-targeted 1.25.4-10 In-Reply-To: <20050829160038.E10BF735EF@hormel.redhat.com> References: <20050829160038.E10BF735EF@hormel.redhat.com> Message-ID: <431366A6.60601@grifent.com> An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Mon Aug 29 19:52:56 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 29 Aug 2005 15:52:56 -0400 Subject: selinux-policy-targeted 1.25.4-10 In-Reply-To: <431366A6.60601@grifent.com> References: <20050829160038.E10BF735EF@hormel.redhat.com> <431366A6.60601@grifent.com> Message-ID: <43136798.3060803@redhat.com> John Griffiths wrote: > Got this when I used yum to update selinux-policy-targeted to 1.25.4-10. > > sepol_genbools_array: unknown boolean i18n_input_disable_trans > /usr/sbin/load_policy: Warning! Unable to reset all booleans > /sbin/restorecon reset /usr/bin/syslinux context > system_u:object_r:bin_t->system_u:object_r:fsadm_exec_t > > Problem? > > Regards, > John Nope expected. i18n_input has been removed from targeted policy, so the boolean has been removed also. > >------------------------------------------------------------------------ > >-- >fedora-selinux-list mailing list >fedora-selinux-list at redhat.com >http://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- From fedora at grifent.com Mon Aug 29 20:33:04 2005 From: fedora at grifent.com (John Griffiths) Date: Mon, 29 Aug 2005 16:33:04 -0400 Subject: selinux-policy-targeted 1.25.4-10 In-Reply-To: <43136798.3060803@redhat.com> References: <20050829160038.E10BF735EF@hormel.redhat.com> <431366A6.60601@grifent.com> <43136798.3060803@redhat.com> Message-ID: <43137100.7020305@grifent.com> Thanks. That makes perfect sense. If the removal was discussed on the list, I missed it. John Daniel J Walsh wrote: > > Nope expected. i18n_input has been removed from targeted policy, so > the boolean has been removed also. > > From tcwan at cs.usm.my Tue Aug 30 03:11:22 2005 From: tcwan at cs.usm.my (TC Wan) Date: Tue, 30 Aug 2005 11:11:22 +0800 (MYT) Subject: rsync and nscd broken in selinux-policy-targeted-1.25.3-12 Message-ID: <47030.161.142.8.174.1125371482.squirrel@nrg.cs.usm.my> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm kindof new to SELinux, but have read enough info from the various FAQs etc to try and follow what is going on. I recently upgrade to selinux-policy-targeted-1.25.3-12 on my server (and rebooted), and discovered subsequently that it broke nscd and rsyncd. I'm not sure what is the exact problem nscd is having. rsyncd requires chroot rights. $ rsync rsync://localhost/Mirror/ @ERROR: chroot failed rsync: connection unexpectedly closed (0 bytes received so far) [receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(420) Output from sestatus: - --------------------- SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 19 Policy from config file: targeted dmesg|fgrep audit (edited): - ----------------- audit(1125305372.102:2): avc: denied { create } for pid=1400 comm="nscd" scontext=system_u:system_r:nscd_t tcontext=system_u:system_r:nscd_t tclass=netlink_audit_socket audit(1125371048.190:11): avc: denied { sys_chroot } for pid=2479 comm="rsync" capability=18 scontext=system_u:system_r:rsync_t tcontext=system_u:system_r:rsync_t tclass=capability dmesg|audit2allow: - ----------------- allow nscd_t self:netlink_audit_socket create; allow rsync_t self:capability sys_chroot; Should I wait for a new targeted policy release to address these problems (if so, how soon?), or should I try to create a custom policy? T.C. - -- Wan Tat Chee (Senior Lecturer) School of Computer Sciences, Univ. of Science Malaysia, 11800 USM, Penang, Malaysia. Rm.625 Ofc Ph: +604 653-3888 x 3617 NRG Lab Admin: +604 659-4757 Rm.601-F Ofc Ph: +604 653-4396 Internet: tcwan at cs.usm.my Web: http://nrg.cs.usm.my/~tcwan GPG Key : http://nrg.cs.usm.my/~tcwan/tcwan-nrg-20040805.asc F'print : 4B2E F0BF AAD7 2F51 CB41 4386 F72B 7859 8278 BDC4 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFDE85a9yt4WYJ4vcQRAm8TAJ0bnj1uY6bUbGqkrTitHDgfacuBrwCfUmEk isxxEsd2oG+7QAh4LTtZegU= =UQM2 -----END PGP SIGNATURE----- From catus.tw at yahoo.com.tw Tue Aug 30 08:50:26 2005 From: catus.tw at yahoo.com.tw (Wen-Fu Shih) Date: Tue, 30 Aug 2005 16:50:26 +0800 (CST) Subject: policy version problem Message-ID: <20050830085026.86727.qmail@web17709.mail.tpe.yahoo.com> I use yum install File: selinux-policy-targeted-sources-1.25.4-11.noarch.rpm and I enable SELinux on FC4 with kernel 2.6.13-1 the original policyvers is 19 after install the policy-soucres and make policy, relabel,reboot the policyver is still 19(use 'sestatus') but the directory /etc/selinux/targeted/policy has both policy.19 and policy.20 I'm confused about the policyvers could I change the policyvers? or have I did it? ~ thanks a lot __________________________________________________ ?????????? ????Yahoo!?????? http://messenger.yahoo.com.tw/ From dragoran at feuerpokemon.de Tue Aug 30 13:02:22 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Tue, 30 Aug 2005 15:02:22 +0200 Subject: ifconfig/pipefs avc messages. In-Reply-To: <43133F1D.5030209@redhat.com> References: <43119CE6.8010208@feuerpokemon.de> <4312A9BA.6090200@feuerpokemon.de> <43133F1D.5030209@redhat.com> Message-ID: <431458DE.3080307@feuerpokemon.de> Daniel J Walsh wrote: > dragoran wrote: > >> dragoran wrote: >> >> > I have found this messages in /var/log/audit/audit.log: >> > >> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> >> for pid=3342 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >> >> for pid=3342 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> >> for pid=3342 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >> >> for pid=3342 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> >> for pid=3342 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >> >> for pid=3342 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> >> for pid=3342 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >> >> for pid=3342 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> >> for pid=3342 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >> >> for pid=3342 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=PATH msg=audit(1120371251.502:661490): item=1 inode=2127845 >> >> dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 >> >> type=PATH msg=audit(1120371251.502:661490): item=0 >> >> name="/sbin/ifconfig" inode=9297060 dev=08:05 mode=0100755 ouid=0 >> >> ogid=0 rdev=00:00 >> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11687]" >> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11687]" >> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11201]" >> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11201]" >> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11202]" >> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11202]" >> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11203]" >> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11203]" >> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11205]" >> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11205]" >> >> type=SYSCALL msg=audit(1120371251.502:661490): arch=c000003e >> >> syscall=59 success=yes exit=0 a0=627990 a1=627cb0 a2=608440 >> >> a3=2aaaaaac5000 items=2 pid=3370 auid=4294967295 uid=0 gid=0 euid=0 >> >> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifconfig" >> >> exe="/sbin/ifconfig" >> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> >> for pid=3370 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >> >> for pid=3370 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> >> for pid=3370 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >> >> for pid=3370 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> >> for pid=3370 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >> >> for pid=3370 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> >> for pid=3370 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >> >> for pid=3370 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> >> for pid=3370 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >> >> for pid=3370 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >> >> scontext=root:system_r:ifconfig_t tcontext=root:system_r:unconfined_t >> >> tclass=fifo_file >> >> type=PATH msg=audit(1120371251.510:662032): item=1 inode=2127845 >> >> dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 >> >> type=PATH msg=audit(1120371251.510:662032): item=0 name="/sbin/ip" >> >> inode=9297052 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 >> > >> > >> > I did fixfiles relabel but it have'nt fixed them. >> > Whats the problem? >> > bug in the policy? (using fc4 and selinux-policy-targeted-1.25.3-12) >> > >> > -- >> > fedora-selinux-list mailing list >> > fedora-selinux-list at redhat.com >> > http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > >> > >> found out that iplugd from fc extras was causing this. >> its labeled as: >> >> > ls -Z /usr/sbin/ifplugd >> > -rwxr-xr-x root root system_u:object_r:sbin_t > >> /usr/sbin/ifplugd >> > Could you label this NetworkManager_exec_t? And do a restart? > Do the messages go away? > >> >> >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> http://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > now I get: type=SYSCALL msg=audit(1125406870.081:3285657): arch=c000003e syscall=59 success=yes exit=0 a0=6c5320 a1=6c5360 a2=6c1e50 a3=7fffffd67208 items=2 pid=3240 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifplugd" exe="/usr/sbin/ifplugd" type=AVC_PATH msg=audit(1125406870.081:3285657): path="pipe:[15843]" type=CWD msg=audit(1125406870.081:3285657): cwd="/" type=PATH msg=audit(1125406870.081:3285657): item=0 name="/usr/sbin/ifplugd" flags=101 inode=14024587 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1125406870.081:3285657): item=1 flags=101 inode=2128071 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=USER_END msg=audit(1125406872.563:3293540): user pid=3137 uid=500 auid=4294967295 msg='PAM session close: user=root exe="/usr/sbin/userhelper" (hostname=?, addr=?, terminal=? result=Success)' type=AVC msg=audit(1125406889.406:3343428): avc: denied { execute } for pid=3261 comm="ifplugd" name="ifplugd.action" dev=sda5 ino=1705807 scontext=root:system_r:NetworkManager_t tcontext=system_u:object_r:etc_t tclass=file type=SYSCALL msg=audit(1125406889.406:3343428): arch=c000003e syscall=59 success=no exit=-13 a0=40450c a1=7fffffa549f0 a2=609300 a3=2aaaaaad89b0 items=1 pid=3261 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifplugd" exe="/usr/sbin/ifplugd" type=CWD msg=audit(1125406889.406:3343428): cwd="/" type=PATH msg=audit(1125406889.406:3343428): item=0 name="/etc/ifplugd/ifplugd.action" flags=101 inode=1705807 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 From sds at tycho.nsa.gov Tue Aug 30 13:26:35 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 30 Aug 2005 09:26:35 -0400 Subject: policy version problem In-Reply-To: <20050830085026.86727.qmail@web17709.mail.tpe.yahoo.com> References: <20050830085026.86727.qmail@web17709.mail.tpe.yahoo.com> Message-ID: <1125408395.18888.48.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2005-08-30 at 16:50 +0800, Wen-Fu Shih wrote: > I use yum install File: > selinux-policy-targeted-sources-1.25.4-11.noarch.rpm > and I enable SELinux on FC4 with kernel 2.6.13-1 > the original policyvers is 19 > after install the policy-soucres and make policy, > relabel,reboot > the policyver is still 19(use 'sestatus') > but the directory /etc/selinux/targeted/policy has > both policy.19 and policy.20 > I'm confused about the policyvers > could I change the policyvers? > or have I did it? This just means that you have a newer version of checkpolicy (the policy compiler), so it is generating both the next policy version (20, which will be used by kernel 2.6.14) and the current one. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Aug 30 14:10:15 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 30 Aug 2005 10:10:15 -0400 Subject: ifconfig/pipefs avc messages. In-Reply-To: <431458DE.3080307@feuerpokemon.de> References: <43119CE6.8010208@feuerpokemon.de> <4312A9BA.6090200@feuerpokemon.de> <43133F1D.5030209@redhat.com> <431458DE.3080307@feuerpokemon.de> Message-ID: <431468C7.1090704@redhat.com> dragoran wrote: > Daniel J Walsh wrote: > >> dragoran wrote: >> >>> dragoran wrote: >>> >>> > I have found this messages in /var/log/audit/audit.log: >>> > >>> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >>> >> for pid=3342 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >>> >> for pid=3342 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >>> >> for pid=3342 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >>> >> for pid=3342 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >>> >> for pid=3342 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >>> >> for pid=3342 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >>> >> for pid=3342 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { read } >>> >> for pid=3342 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >>> >> for pid=3342 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371250.432:658540): avc: denied { write } >>> >> for pid=3342 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=PATH msg=audit(1120371251.502:661490): item=1 inode=2127845 >>> >> dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 >>> >> type=PATH msg=audit(1120371251.502:661490): item=0 >>> >> name="/sbin/ifconfig" inode=9297060 dev=08:05 mode=0100755 ouid=0 >>> >> ogid=0 rdev=00:00 >>> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11687]" >>> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11687]" >>> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11201]" >>> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11201]" >>> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11202]" >>> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11202]" >>> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11203]" >>> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11203]" >>> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11205]" >>> >> type=AVC_PATH msg=audit(1120371251.502:661490): path="pipe:[11205]" >>> >> type=SYSCALL msg=audit(1120371251.502:661490): arch=c000003e >>> >> syscall=59 success=yes exit=0 a0=627990 a1=627cb0 a2=608440 >>> >> a3=2aaaaaac5000 items=2 pid=3370 auid=4294967295 uid=0 gid=0 euid=0 >>> >> suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifconfig" >>> >> exe="/sbin/ifconfig" >>> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >>> >> for pid=3370 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >>> >> for pid=3370 comm="ifconfig" name=[11205] dev=pipefs ino=11205 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >>> >> for pid=3370 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >>> >> for pid=3370 comm="ifconfig" name=[11203] dev=pipefs ino=11203 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >>> >> for pid=3370 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >>> >> for pid=3370 comm="ifconfig" name=[11202] dev=pipefs ino=11202 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >>> >> for pid=3370 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { read } >>> >> for pid=3370 comm="ifconfig" name=[11201] dev=pipefs ino=11201 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >>> >> for pid=3370 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=AVC msg=audit(1120371251.502:661490): avc: denied { write } >>> >> for pid=3370 comm="ifconfig" name=[11687] dev=pipefs ino=11687 >>> >> scontext=root:system_r:ifconfig_t >>> tcontext=root:system_r:unconfined_t >>> >> tclass=fifo_file >>> >> type=PATH msg=audit(1120371251.510:662032): item=1 inode=2127845 >>> >> dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 >>> >> type=PATH msg=audit(1120371251.510:662032): item=0 name="/sbin/ip" >>> >> inode=9297052 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 >>> > >>> > >>> > I did fixfiles relabel but it have'nt fixed them. >>> > Whats the problem? >>> > bug in the policy? (using fc4 and selinux-policy-targeted-1.25.3-12) >>> > >>> > -- >>> > fedora-selinux-list mailing list >>> > fedora-selinux-list at redhat.com >>> > http://www.redhat.com/mailman/listinfo/fedora-selinux-list >>> > >>> > >>> found out that iplugd from fc extras was causing this. >>> its labeled as: >>> >>> > ls -Z /usr/sbin/ifplugd >>> > -rwxr-xr-x root root system_u:object_r:sbin_t > >>> /usr/sbin/ifplugd >>> >> Could you label this NetworkManager_exec_t? And do a restart? >> Do the messages go away? >> >>> >>> >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> http://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> >> >> >> > now I get: > type=SYSCALL msg=audit(1125406870.081:3285657): arch=c000003e > syscall=59 success=yes exit=0 a0=6c5320 a1=6c5360 a2=6c1e50 > a3=7fffffd67208 items=2 pid=3240 auid=4294967295 uid=0 gid=0 euid=0 > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifplugd" > exe="/usr/sbin/ifplugd" > type=AVC_PATH msg=audit(1125406870.081:3285657): path="pipe:[15843]" > type=CWD msg=audit(1125406870.081:3285657): cwd="/" > type=PATH msg=audit(1125406870.081:3285657): item=0 > name="/usr/sbin/ifplugd" flags=101 inode=14024587 dev=08:05 > mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=PATH msg=audit(1125406870.081:3285657): item=1 flags=101 > inode=2128071 dev=08:05 mode=0100755 ouid=0 ogid=0 rdev=00:00 > type=USER_END msg=audit(1125406872.563:3293540): user pid=3137 uid=500 > auid=4294967295 msg='PAM session close: user=root > exe="/usr/sbin/userhelper" (hostname=?, addr=?, terminal=? > result=Success)' > type=AVC msg=audit(1125406889.406:3343428): avc: denied { execute } > for pid=3261 comm="ifplugd" name="ifplugd.action" dev=sda5 > ino=1705807 scontext=root:system_r:NetworkManager_t > tcontext=system_u:object_r:etc_t tclass=file > type=SYSCALL msg=audit(1125406889.406:3343428): arch=c000003e > syscall=59 success=no exit=-13 a0=40450c a1=7fffffa549f0 a2=609300 > a3=2aaaaaad89b0 items=1 pid=3261 auid=4294967295 uid=0 gid=0 euid=0 > suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="ifplugd" > exe="/usr/sbin/ifplugd" > type=CWD msg=audit(1125406889.406:3343428): cwd="/" > type=PATH msg=audit(1125406889.406:3343428): item=0 > name="/etc/ifplugd/ifplugd.action" flags=101 inode=1705807 dev=08:05 > mode=0100755 ouid=0 ogid=0 rdev=00:00 > chcon -t bin_t /etc/ifplugd/ifplugd.action You might want to do this for executables/scripts in this directory. -- From paul at city-fan.org Tue Aug 30 15:02:11 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 30 Aug 2005 16:02:11 +0100 Subject: selinux-policy-targeted 1.25.4-10 and dovecot Message-ID: <431474F3.9030101@city-fan.org> I notice in the changelog that a recent change was: * Wed Aug 17 2005 Dan Walsh 1.25.4-4 - Add more access for amanda - Allow dovecot to create files in mail_spool_t Having installed the updated policy this morning, I found I had to add a local rule: allow dovecot_t mail_spool_t:file write; This is needed to allow dovecot to delete mail from the mail spool file (I use dovecot in pop3 mode). I'm surprised this wasn't the default - is there a good reason why it isn't? Cheers, Paul. P.S. there is still a problem with pptp - in pppd.fc # Fix pptp sockets /var/run/pptp(/.*)? -- system_u:object_r:pptp_var_run_t should read: # Fix pptp sockets /var/run/pptp(/.*)? system_u:object_r:pptp_var_run_t because /var/run/pptp is a directory and the items in that directory should be sockets, not regular files. From kcarr at tresys.com Wed Aug 31 22:00:34 2005 From: kcarr at tresys.com (Kevin Carr) Date: Wed, 31 Aug 2005 18:00:34 -0400 Subject: ANN: New Release of Setools Message-ID: <200508312200.j7VM0Yss032092@gotham.columbia.tresys.com> Tresys is proud to announce the release of Setools-2.1.2. This minor release provides support for loading the new version 20 binary policy format. We have provided updated permission maps for version 19 and 20 as well. Also included in this release is the ability for seaudit to parse avc messages in logs generated by auditd. You can download this new release from the Tresys website by clicking the link on our main page - http://www.tresys.com Kevin Carr Tresys Technology 410.290.1411 x137 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinkw at ncic.ac.cn Thu Aug 25 09:09:31 2005 From: kevinkw at ncic.ac.cn (KevinKW) Date: Thu, 25 Aug 2005 17:09:31 +0800 Subject: NeedHelp: Issue on change apache DocumentRoot location on FC3 Message-ID: <430D8ACB.70009@ncic.ac.cn> Hi, I've changed the DocumentRoot directory of httpd 2.0.52 server from /var/www/html to /data/www/html, which is mounted from the disk /dev/hda8. But when I try to start httpd service, it reports warning "Warning: DocumentRoot [/data/www/html/] does not exist". I've changed its the security context by command "chcon -R -t httpd_user_content_t /data/www" but it still didnot work. The follows are the output by command "ls -Z /data/www" ============= drwxr-xr-x kevinkw kevinkw user_u:object_r:httpd_user_content_t cgi-bin drwxr-xr-x kevinkw kevinkw user_u:object_r:httpd_user_content_t error drwxr-xr-x kevinkw kevinkw user_u:object_r:httpd_user_content_t html drwxr-xr-x kevinkw kevinkw user_u:object_r:httpd_user_content_t icons ============= How can I solve this problem? Any more information needed, please let me know. Thanks very much! Best wishes, Kevin