From dwalsh at redhat.com Fri May 2 15:54:36 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 02 May 2008 11:54:36 -0400 Subject: postfix with maildir delivery In-Reply-To: References: Message-ID: <481B393C.6060904@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 freeslkr wrote: > freeslkr mailnull.com> writes: > >> Hello, >> >> I'm trying out SELinux on Fedora 8 in permissive mode. I get AVCs >> everytime postfix delivers mail to the maildir directories. It looks >> like postfix doesn't have permission to create files. For example, >> >> from /var/log/messages: >> >> SELinux is preventing local (postfix_local_t) "link" to >> ./1208923427.P3686.myhost (mail_spool_t) >> >> from /var/log/audit/audit.log: >> >> type=AVC msg=audit(1208923427.350:95): avc: denied { link } for >> pid=3686 comm="local" name="1208923427.P3686.myhost" dev=dm-3 >> ino=819271 scontext=system_u:system_r:postfix_local_t:s0 >> tcontext=system_u:object_r:mail_spool_t:s0 tclass=file >> >> type=SYSCALL msg=audit(1208923427.350:95): arch=c000003e >> syscall=86 success=yes exit=0 a0=2aaaaad599c0 a1=2aaaaad59ba0 >> a2=0 a3=0 items=0 ppid=2371 pid=3686 auid=4294967295 uid=0 gid=0 >> euid=1000 suid=0 fsuid=1000 egid=1000 sgid=0 fsgid=1000 tty=(none) >> comm="local" exe="/usr/libexec/postfix/local" >> subj=system_u:system_r:postfix_local_t:s0 key=(null) >> >> Is my interpretation correct. If so, is it likely that this could be >> corrected in a future policy version? >> >> Thank you for you help > > I'll first note that reverting to mbox files in /var/spool/mail works > just fine. > > Blundering along here ... > > file:///usr/share/doc/selinux-policy-3.0.8/html/services_postfix.html > says > > allow_postfix_local_write_mail_spool > Default value: false > Description: Allow postfix_local domain full write access to mail_spool > directories > > This sounds like what I need. But, it seems that it's already set. > > $ getsebool allow_postfix_local_write_mail_spool > allow_postfix_local_write_mail_spool --> on > > $ cd /var/spool > $ ls -Zd mail > drwxrwxr-x root mail system_u:object_r:mail_spool_t:s0 mail > > $ ls -Zd mail/* > drwxrwx--- XXXX mail system_u:object_r:mail_spool_t:s0 mail/XXXX > > $ ls -Zd mail/*/* > drwxrwx--- XXXX mail system_u:object_r:mail_spool_t:s0 mail/XXXX/cur > drwxrwx--- XXXX mail system_u:object_r:mail_spool_t:s0 mail/XXXX/new > drwxrwx--- XXXX mail system_u:object_r:mail_spool_t:s0 mail/XXXX/tmp > > $ ls -Z mail/*/*/new > -rw------- XXXX XXXX system_u:object_r:mail_spool_t:s0 > 1209227463.Vfd03Ic8046M24695.myhost > > To me, it _looks_ postfix should be able to create new files in > /var/spool/mail/*/*, but this is being denied. > > In the selinux-policy source rpm, there are three files that seem to be > related to postfix: postfix.{fc,if,te}. Obviously, I don't understand how > all of this works, but there are no direct references to mail_spool_t or > /var/spool/mail or /var/mail in these files. > > /var/spool/postfix has type postfix_spool_t, so naively I try > > $ chcon --recursive --type postfix_spool_t /var/spool/mail > > but that causes numerous AVC denied messages. > > Using audit2allow: > > $ grep -e postfix -e mail /var/log/audit/audit.log | audit2allow > #============= postfix_local_t ============== > allow postfix_local_t mail_spool_t:file link; > > Now, if I can just figure out what to do with this .... Thanks to anyone > that shares some insight here. > a > $ # grep -e postfix -e mail /var/log/audit/audit.log | audit2allow -m mypostfix # semodule -i mypostfix.pp Will update your policy with this. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgbOTsACgkQrlYvE4MpobObJwCdH5lGclRBxi0JvKseEma00R5+ KukAniB1hkfywjtJNAyAsttFpb7UzTaH =5yJY -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri May 2 15:57:04 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 02 May 2008 11:57:04 -0400 Subject: postfix with maildir delivery In-Reply-To: References: Message-ID: <481B39D0.40603@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 freeslkr wrote: > freeslkr mailnull.com> writes: > >> Hello, >> >> I'm trying out SELinux on Fedora 8 in permissive mode. I get AVCs >> everytime postfix delivers mail to the maildir directories. It looks >> like postfix doesn't have permission to create files. For example, >> >> from /var/log/messages: >> >> SELinux is preventing local (postfix_local_t) "link" to >> ./1208923427.P3686.myhost (mail_spool_t) >> >> from /var/log/audit/audit.log: >> >> type=AVC msg=audit(1208923427.350:95): avc: denied { link } for >> pid=3686 comm="local" name="1208923427.P3686.myhost" dev=dm-3 >> ino=819271 scontext=system_u:system_r:postfix_local_t:s0 >> tcontext=system_u:object_r:mail_spool_t:s0 tclass=file >> >> type=SYSCALL msg=audit(1208923427.350:95): arch=c000003e >> syscall=86 success=yes exit=0 a0=2aaaaad599c0 a1=2aaaaad59ba0 >> a2=0 a3=0 items=0 ppid=2371 pid=3686 auid=4294967295 uid=0 gid=0 >> euid=1000 suid=0 fsuid=1000 egid=1000 sgid=0 fsgid=1000 tty=(none) >> comm="local" exe="/usr/libexec/postfix/local" >> subj=system_u:system_r:postfix_local_t:s0 key=(null) >> >> Is my interpretation correct. If so, is it likely that this could be >> corrected in a future policy version? >> >> Thank you for you help > > I'll first note that reverting to mbox files in /var/spool/mail works > just fine. > > Blundering along here ... > > file:///usr/share/doc/selinux-policy-3.0.8/html/services_postfix.html > says > > allow_postfix_local_write_mail_spool > Default value: false > Description: Allow postfix_local domain full write access to mail_spool > directories > > This sounds like what I need. But, it seems that it's already set. > > $ getsebool allow_postfix_local_write_mail_spool > allow_postfix_local_write_mail_spool --> on > > $ cd /var/spool > $ ls -Zd mail > drwxrwxr-x root mail system_u:object_r:mail_spool_t:s0 mail > > $ ls -Zd mail/* > drwxrwx--- XXXX mail system_u:object_r:mail_spool_t:s0 mail/XXXX > > $ ls -Zd mail/*/* > drwxrwx--- XXXX mail system_u:object_r:mail_spool_t:s0 mail/XXXX/cur > drwxrwx--- XXXX mail system_u:object_r:mail_spool_t:s0 mail/XXXX/new > drwxrwx--- XXXX mail system_u:object_r:mail_spool_t:s0 mail/XXXX/tmp > > $ ls -Z mail/*/*/new > -rw------- XXXX XXXX system_u:object_r:mail_spool_t:s0 > 1209227463.Vfd03Ic8046M24695.myhost > > To me, it _looks_ postfix should be able to create new files in > /var/spool/mail/*/*, but this is being denied. > > In the selinux-policy source rpm, there are three files that seem to be > related to postfix: postfix.{fc,if,te}. Obviously, I don't understand how > all of this works, but there are no direct references to mail_spool_t or > /var/spool/mail or /var/mail in these files. > > /var/spool/postfix has type postfix_spool_t, so naively I try > > $ chcon --recursive --type postfix_spool_t /var/spool/mail > > but that causes numerous AVC denied messages. > > Using audit2allow: > > $ grep -e postfix -e mail /var/log/audit/audit.log | audit2allow > #============= postfix_local_t ============== > allow postfix_local_t mail_spool_t:file link; > > Now, if I can just figure out what to do with this .... Thanks to anyone > that shares some insight here. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Also I believe this is fixed in selinux-policy-3.0.8-108 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgbOdAACgkQrlYvE4MpobOIkwCeNK1SzOCrp1n/31AGZfD41XZp UqYAn3sGQ5q8xGczPp30kjdXWhBSee2l =pdc7 -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Fri May 2 17:20:15 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 02 May 2008 13:20:15 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote: > On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote: > > On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote: > > > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote: > > > > James Morris (jmorris at namei.org) said: > > > > > > You cannot create files in a chroot of a context not known by the > > > > > > host policy. This means that if your host is running RHEL 5, you are > > > > > > unable to compose any trees/images/livecds with SELinux enabled for > > > > > > later releases. > > > > > > > > > > Ok, that's what I suspected. > > > > > > > > > > One of the possible plans for this is to allow a process to run in a > > > > > separate policy namespace, and probably also utilize namespace support in > > > > > general. > > > > > > > > > > This is non-trivial and needs more analysis. > > > > > > > > Incidentally, this is also one of the blockers for policy-in-packages, > > > > rather than a monolithic one. > > > > > > I assume you mean setting down unknown file labels rather than > > > per-namespace or per-chroot policy support. I think they are related > > > but different. The former is required if you always plan to install the > > > files _before_ loading the policy. The latter is required primarily for > > > getting any scriptlets to run in the right security contexts so that any > > > files they create are labeled appropriately within the chroot. > > > > BTW, for reference, a patch to support setting down unknown file labels > > was posted here a couple of years ago: > > http://marc.info/?l=selinux&m=114771094617968&w=2 > > And the last version of that patch was: > http://marc.info/?l=selinux&m=114840466518263&w=2 > Not that it applies cleanly anymore, of course. An updated patch and discussion has started over on selinux list, see: http://marc.info/?t=120958955400002&r=1&w=2 One question that has come up is whether the patch to support setting unknown file labels is sufficient to support the buildsys needs, or whether something more is required. My impression is that all we truly need is: 1) support for setting unknown file labels for use by rpm, and 2) bind mount /dev/null over selinux/load within the chroot so that policy loads within the chroot do nothing rather than changing the build host's policy, and 3) bind mount a regular empty file over selinux/context within the chroot so that attempts to validate/canonicalize contexts by rpm will always return the original value w/o trying to validate against the build host's policy. Plus the associated policy changes to permit the above to take place. Does that sufficient? The per-chroot/namespace policy idea sounds nice and elegant, but is a lot more complicated, so if the above is workable, it provides a much shorter term path for solving the buildsys problem. -- Stephen Smalley National Security Agency From cmadams at hiwaay.net Fri May 2 18:50:17 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 2 May 2008 13:50:17 -0500 Subject: Odd problem with dovecot Message-ID: <20080502185017.GA1545656@hiwaay.net> I'm trying to set up dovecot for IMAP. I'm using an external auth program and a static userdb setting to define the home directories (all owned by the same UID/GID). I set the whole directory tree to mail_spool_t (thinking I'd avoid any SELinux access issues that way). What is odd is that it fails when SELinux is in enforcing mode, but not in permissive, BUT I don't get any errors when it fails (e.g. no "denied" messages in the kernel or audit logs). I've straced the daemon, and it fails at a chdir(). I know the permissions are okay (it works when the system is in permissive mode), so I figured it has to be related to SELinux, but I can't figure out how. Suggestions? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From freeslkr.wl6x at mailnull.com Fri May 2 23:13:37 2008 From: freeslkr.wl6x at mailnull.com (freeslkr) Date: Fri, 2 May 2008 23:13:37 +0000 (UTC) Subject: postfix with maildir delivery References: <481B393C.6060904@redhat.com> Message-ID: Daniel J Walsh redhat.com> writes: > # grep -e postfix -e mail /var/log/audit/audit.log | audit2allow -m > mypostfix > # semodule -i mypostfix.pp > > Will update your policy with this. Thank you. This works as expected. From arequipeno at gmail.com Sun May 4 13:52:08 2008 From: arequipeno at gmail.com (Ian Pilcher) Date: Sun, 04 May 2008 08:52:08 -0500 Subject: Starting stunnel from xinetd In-Reply-To: <47EE72B1.7040304@redhat.com> References: <47E00ACD.6010707@redhat.com> <47EE72B1.7040304@redhat.com> Message-ID: Daniel J Walsh wrote: > Ian Pilcher wrote: >> >> host=f8.example.com type=AVC msg=audit(1206311825.570:66): avc: denied >> { read write } for pid=2962 comm="rsync" name="[11108]" dev=sockfs >> ino=11108 scontext=system_u:system_r:rsync_t:s0-s0:c0.c1023 >> tcontext=system_u:system_r:stunnel_t:s0-s0:c0.c1023 tclass=tcp_socket > > Added in selinux-policy-3.0.8-97. Finally had a chance to test this. Working now. Thanks! -- ======================================================================== Ian Pilcher arequipeno at gmail.com ======================================================================== From sds at tycho.nsa.gov Mon May 5 13:35:07 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 05 May 2008 09:35:07 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1209994507.25678.639.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote: > > On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote: > > > On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote: > > > > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote: > > > > > James Morris (jmorris at namei.org) said: > > > > > > > You cannot create files in a chroot of a context not known by the > > > > > > > host policy. This means that if your host is running RHEL 5, you are > > > > > > > unable to compose any trees/images/livecds with SELinux enabled for > > > > > > > later releases. > > > > > > > > > > > > Ok, that's what I suspected. > > > > > > > > > > > > One of the possible plans for this is to allow a process to run in a > > > > > > separate policy namespace, and probably also utilize namespace support in > > > > > > general. > > > > > > > > > > > > This is non-trivial and needs more analysis. > > > > > > > > > > Incidentally, this is also one of the blockers for policy-in-packages, > > > > > rather than a monolithic one. > > > > > > > > I assume you mean setting down unknown file labels rather than > > > > per-namespace or per-chroot policy support. I think they are related > > > > but different. The former is required if you always plan to install the > > > > files _before_ loading the policy. The latter is required primarily for > > > > getting any scriptlets to run in the right security contexts so that any > > > > files they create are labeled appropriately within the chroot. > > > > > > BTW, for reference, a patch to support setting down unknown file labels > > > was posted here a couple of years ago: > > > http://marc.info/?l=selinux&m=114771094617968&w=2 > > > > And the last version of that patch was: > > http://marc.info/?l=selinux&m=114840466518263&w=2 > > Not that it applies cleanly anymore, of course. > > An updated patch and discussion has started over on selinux list, see: > http://marc.info/?t=120958955400002&r=1&w=2 > > One question that has come up is whether the patch to support setting > unknown file labels is sufficient to support the buildsys needs, or > whether something more is required. My impression is that all we truly > need is: > 1) support for setting unknown file labels for use by rpm, and > 2) bind mount /dev/null over selinux/load within the chroot so that > policy loads within the chroot do nothing rather than changing the build > host's policy, and > 3) bind mount a regular empty file over selinux/context within the > chroot so that attempts to validate/canonicalize contexts by rpm will > always return the original value w/o trying to validate against the > build host's policy. We need to better understand the sequence of actions performed by rpm, both from outside the chroot and from within the chroot, to know precisely what is needed here. It would be cleaner if we could just disable policy reload altogether. libsemanage will skip policy reload if: 1) the caller asked to skip reload (e.g. semodule with the -n option) or 2) the caller asked to operate on a policy store other than the active policy store (e.g. semodule with the -s option), or 3) SELinux appears to be disabled. We can fake the last one, but I think that will confuse rpm with respect to other actions we still want it to take, like labeling the files, transitioning to a scriptlet domain, etc. On the context validation/canonicalization, it would be cleaner if we could have rpm validate and canonicalize against the target image's policy rather than the build host's policy. This is likely doable, as setfiles has to do something like this for its -c option when validating a file contexts configuration against a policy at policy build time. Requires calling a libselinux interface to register an alternative validate callback. > Plus the associated policy changes to permit the above to take place. > Does that sufficient? > > The per-chroot/namespace policy idea sounds nice and elegant, but is a > lot more complicated, so if the above is workable, it provides a much > shorter term path for solving the buildsys problem. -- Stephen Smalley National Security Agency From eparis at redhat.com Mon May 5 14:07:11 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 05 May 2008 10:07:11 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1209994507.25678.639.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1209994507.25678.639.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1209996431.2982.71.camel@localhost.localdomain> On Mon, 2008-05-05 at 09:35 -0400, Stephen Smalley wrote: > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > > On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote: > > > On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote: > > > > On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote: > > > > > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote: > > > > > > James Morris (jmorris at namei.org) said: > > > > > > > > You cannot create files in a chroot of a context not known by the > > > > > > > > host policy. This means that if your host is running RHEL 5, you are > > > > > > > > unable to compose any trees/images/livecds with SELinux enabled for > > > > > > > > later releases. > > > > > > > > > > > > > > Ok, that's what I suspected. > > > > > > > > > > > > > > One of the possible plans for this is to allow a process to run in a > > > > > > > separate policy namespace, and probably also utilize namespace support in > > > > > > > general. > > > > > > > > > > > > > > This is non-trivial and needs more analysis. > > > > > > > > > > > > Incidentally, this is also one of the blockers for policy-in-packages, > > > > > > rather than a monolithic one. > > > > > > > > > > I assume you mean setting down unknown file labels rather than > > > > > per-namespace or per-chroot policy support. I think they are related > > > > > but different. The former is required if you always plan to install the > > > > > files _before_ loading the policy. The latter is required primarily for > > > > > getting any scriptlets to run in the right security contexts so that any > > > > > files they create are labeled appropriately within the chroot. > > > > > > > > BTW, for reference, a patch to support setting down unknown file labels > > > > was posted here a couple of years ago: > > > > http://marc.info/?l=selinux&m=114771094617968&w=2 > > > > > > And the last version of that patch was: > > > http://marc.info/?l=selinux&m=114840466518263&w=2 > > > Not that it applies cleanly anymore, of course. > > > > An updated patch and discussion has started over on selinux list, see: > > http://marc.info/?t=120958955400002&r=1&w=2 > > > > One question that has come up is whether the patch to support setting > > unknown file labels is sufficient to support the buildsys needs, or > > whether something more is required. My impression is that all we truly > > need is: > > 1) support for setting unknown file labels for use by rpm, and > > 2) bind mount /dev/null over selinux/load within the chroot so that > > policy loads within the chroot do nothing rather than changing the build > > host's policy, and > > 3) bind mount a regular empty file over selinux/context within the > > chroot so that attempts to validate/canonicalize contexts by rpm will > > always return the original value w/o trying to validate against the > > build host's policy. > > We need to better understand the sequence of actions performed by rpm, > both from outside the chroot and from within the chroot, to know > precisely what is needed here. > > It would be cleaner if we could just disable policy reload altogether. > libsemanage will skip policy reload if: > 1) the caller asked to skip reload (e.g. semodule with the -n option) or > 2) the caller asked to operate on a policy store other than the active > policy store (e.g. semodule with the -s option), or > 3) SELinux appears to be disabled. > > We can fake the last one, but I think that will confuse rpm with respect > to other actions we still want it to take, like labeling the files, > transitioning to a scriptlet domain, etc. In this case is scriptlet transition really important? What is to be gained? Its not like we are getting file transitions... > > On the context validation/canonicalization, it would be cleaner if we > could have rpm validate and canonicalize against the target image's > policy rather than the build host's policy. This is likely doable, as > setfiles has to do something like this for its -c option when validating > a file contexts configuration against a policy at policy build time. > Requires calling a libselinux interface to register an alternative > validate callback. This sounds like a great idea, but is clearly going to take work from the RPM people.... From sds at tycho.nsa.gov Mon May 5 14:24:21 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 05 May 2008 10:24:21 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1209996431.2982.71.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1209994507.25678.639.camel@moss-spartans.epoch.ncsc.mil> <1209996431.2982.71.camel@localhost.localdomain> Message-ID: <1209997461.25678.666.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-05-05 at 10:07 -0400, Eric Paris wrote: > On Mon, 2008-05-05 at 09:35 -0400, Stephen Smalley wrote: > > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > > > On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote: > > > > On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote: > > > > > On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote: > > > > > > On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote: > > > > > > > James Morris (jmorris at namei.org) said: > > > > > > > > > You cannot create files in a chroot of a context not known by the > > > > > > > > > host policy. This means that if your host is running RHEL 5, you are > > > > > > > > > unable to compose any trees/images/livecds with SELinux enabled for > > > > > > > > > later releases. > > > > > > > > > > > > > > > > Ok, that's what I suspected. > > > > > > > > > > > > > > > > One of the possible plans for this is to allow a process to run in a > > > > > > > > separate policy namespace, and probably also utilize namespace support in > > > > > > > > general. > > > > > > > > > > > > > > > > This is non-trivial and needs more analysis. > > > > > > > > > > > > > > Incidentally, this is also one of the blockers for policy-in-packages, > > > > > > > rather than a monolithic one. > > > > > > > > > > > > I assume you mean setting down unknown file labels rather than > > > > > > per-namespace or per-chroot policy support. I think they are related > > > > > > but different. The former is required if you always plan to install the > > > > > > files _before_ loading the policy. The latter is required primarily for > > > > > > getting any scriptlets to run in the right security contexts so that any > > > > > > files they create are labeled appropriately within the chroot. > > > > > > > > > > BTW, for reference, a patch to support setting down unknown file labels > > > > > was posted here a couple of years ago: > > > > > http://marc.info/?l=selinux&m=114771094617968&w=2 > > > > > > > > And the last version of that patch was: > > > > http://marc.info/?l=selinux&m=114840466518263&w=2 > > > > Not that it applies cleanly anymore, of course. > > > > > > An updated patch and discussion has started over on selinux list, see: > > > http://marc.info/?t=120958955400002&r=1&w=2 > > > > > > One question that has come up is whether the patch to support setting > > > unknown file labels is sufficient to support the buildsys needs, or > > > whether something more is required. My impression is that all we truly > > > need is: > > > 1) support for setting unknown file labels for use by rpm, and > > > 2) bind mount /dev/null over selinux/load within the chroot so that > > > policy loads within the chroot do nothing rather than changing the build > > > host's policy, and > > > 3) bind mount a regular empty file over selinux/context within the > > > chroot so that attempts to validate/canonicalize contexts by rpm will > > > always return the original value w/o trying to validate against the > > > build host's policy. > > > > We need to better understand the sequence of actions performed by rpm, > > both from outside the chroot and from within the chroot, to know > > precisely what is needed here. > > > > It would be cleaner if we could just disable policy reload altogether. > > libsemanage will skip policy reload if: > > 1) the caller asked to skip reload (e.g. semodule with the -n option) or > > 2) the caller asked to operate on a policy store other than the active > > policy store (e.g. semodule with the -s option), or > > 3) SELinux appears to be disabled. > > > > We can fake the last one, but I think that will confuse rpm with respect > > to other actions we still want it to take, like labeling the files, > > transitioning to a scriptlet domain, etc. > > In this case is scriptlet transition really important? What is to be > gained? Its not like we are getting file transitions... IIRC, failure to transition to rpm_script_t has caused problems in the past, either with denials or subsequent domain transitions or subsequent file transitions. If we could ensure that rpm and forked children prior to exec continue to see SELinux as enabled while faking selinux-disabled status when running semodule and semanage, then that might work. As a reminder, is_selinux_enabled() returns 1 if: 1) selinuxfs was found mounted on /selinux at startup, or 2) selinuxfs was found in /proc/mounts (mounted elsewhere) at startup, or 3) selinuxfs is found in /proc/filesystems, Thus, merely failing to mount selinuxfs within the chroot does not yield selinux-disabled status. You'd have to also not mount /proc. Or override is_selinux_enabled() in your own shared object. > > > > On the context validation/canonicalization, it would be cleaner if we > > could have rpm validate and canonicalize against the target image's > > policy rather than the build host's policy. This is likely doable, as > > setfiles has to do something like this for its -c option when validating > > a file contexts configuration against a policy at policy build time. > > Requires calling a libselinux interface to register an alternative > > validate callback. > > This sounds like a great idea, but is clearly going to take work from > the RPM people.... -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue May 6 17:56:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 May 2008 13:56:54 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1209997461.25678.666.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1209994507.25678.639.camel@moss-spartans.epoch.ncsc.mil> <1209996431.2982.71.camel@localhost.localdomain> <1209997461.25678.666.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <48209BE6.6000706@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Smalley wrote: > On Mon, 2008-05-05 at 10:07 -0400, Eric Paris wrote: >> On Mon, 2008-05-05 at 09:35 -0400, Stephen Smalley wrote: >>> On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: >>>> On Tue, 2008-04-22 at 12:38 -0400, Stephen Smalley wrote: >>>>> On Tue, 2008-04-22 at 11:55 -0400, Stephen Smalley wrote: >>>>>> On Thu, 2008-04-17 at 09:12 -0400, Stephen Smalley wrote: >>>>>>> On Wed, 2008-04-16 at 23:23 -0400, Bill Nottingham wrote: >>>>>>>> James Morris (jmorris at namei.org) said: >>>>>>>>>> You cannot create files in a chroot of a context not known by the >>>>>>>>>> host policy. This means that if your host is running RHEL 5, you are >>>>>>>>>> unable to compose any trees/images/livecds with SELinux enabled for >>>>>>>>>> later releases. >>>>>>>>> Ok, that's what I suspected. >>>>>>>>> >>>>>>>>> One of the possible plans for this is to allow a process to run in a >>>>>>>>> separate policy namespace, and probably also utilize namespace support in >>>>>>>>> general. >>>>>>>>> >>>>>>>>> This is non-trivial and needs more analysis. >>>>>>>> Incidentally, this is also one of the blockers for policy-in-packages, >>>>>>>> rather than a monolithic one. >>>>>>> I assume you mean setting down unknown file labels rather than >>>>>>> per-namespace or per-chroot policy support. I think they are related >>>>>>> but different. The former is required if you always plan to install the >>>>>>> files _before_ loading the policy. The latter is required primarily for >>>>>>> getting any scriptlets to run in the right security contexts so that any >>>>>>> files they create are labeled appropriately within the chroot. >>>>>> BTW, for reference, a patch to support setting down unknown file labels >>>>>> was posted here a couple of years ago: >>>>>> http://marc.info/?l=selinux&m=114771094617968&w=2 >>>>> And the last version of that patch was: >>>>> http://marc.info/?l=selinux&m=114840466518263&w=2 >>>>> Not that it applies cleanly anymore, of course. >>>> An updated patch and discussion has started over on selinux list, see: >>>> http://marc.info/?t=120958955400002&r=1&w=2 >>>> >>>> One question that has come up is whether the patch to support setting >>>> unknown file labels is sufficient to support the buildsys needs, or >>>> whether something more is required. My impression is that all we truly >>>> need is: >>>> 1) support for setting unknown file labels for use by rpm, and >>>> 2) bind mount /dev/null over selinux/load within the chroot so that >>>> policy loads within the chroot do nothing rather than changing the build >>>> host's policy, and >>>> 3) bind mount a regular empty file over selinux/context within the >>>> chroot so that attempts to validate/canonicalize contexts by rpm will >>>> always return the original value w/o trying to validate against the >>>> build host's policy. >>> We need to better understand the sequence of actions performed by rpm, >>> both from outside the chroot and from within the chroot, to know >>> precisely what is needed here. >>> >>> It would be cleaner if we could just disable policy reload altogether. >>> libsemanage will skip policy reload if: >>> 1) the caller asked to skip reload (e.g. semodule with the -n option) or >>> 2) the caller asked to operate on a policy store other than the active >>> policy store (e.g. semodule with the -s option), or >>> 3) SELinux appears to be disabled. >>> >>> We can fake the last one, but I think that will confuse rpm with respect >>> to other actions we still want it to take, like labeling the files, >>> transitioning to a scriptlet domain, etc. >> In this case is scriptlet transition really important? What is to be >> gained? Its not like we are getting file transitions... > > IIRC, failure to transition to rpm_script_t has caused problems in the > past, either with denials or subsequent domain transitions or subsequent > file transitions. > > If we could ensure that rpm and forked children prior to exec continue > to see SELinux as enabled while faking selinux-disabled status when > running semodule and semanage, then that might work. > > As a reminder, is_selinux_enabled() returns 1 if: > 1) selinuxfs was found mounted on /selinux at startup, or > 2) selinuxfs was found in /proc/mounts (mounted elsewhere) at startup, > or > 3) selinuxfs is found in /proc/filesystems, > > Thus, merely failing to mount selinuxfs within the chroot does not yield > selinux-disabled status. You'd have to also not mount /proc. Or > override is_selinux_enabled() in your own shared object. > >>> On the context validation/canonicalization, it would be cleaner if we >>> could have rpm validate and canonicalize against the target image's >>> policy rather than the build host's policy. This is likely doable, as >>> setfiles has to do something like this for its -c option when validating >>> a file contexts configuration against a policy at policy build time. >>> Requires calling a libselinux interface to register an alternative >>> validate callback. >> This sounds like a great idea, but is clearly going to take work from >> the RPM people.... I think a lot of this is experimental. The easiest thing would to first get livecd creation to work. Once we have a workable solution there we could probably extend it to Mock and other parts of the Fedora Infrastructure. Offhand we need to handle calls made by semodule, restorecon/setfiles, potential problems with udev, rpmscript execution. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkggm+YACgkQrlYvE4MpobN25wCeITCT9Kj4QlgIk/mVKEaH7eAD ahIAn2iwFNxqQdOp56M8c1dQcPASuSj2 =IJzJ -----END PGP SIGNATURE----- From dwalsh at redhat.com Tue May 6 17:58:54 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 06 May 2008 13:58:54 -0400 Subject: Odd problem with dovecot In-Reply-To: <20080502185017.GA1545656@hiwaay.net> References: <20080502185017.GA1545656@hiwaay.net> Message-ID: <48209C5E.9030007@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Adams wrote: > I'm trying to set up dovecot for IMAP. I'm using an external auth > program and a static userdb setting to define the home directories (all > owned by the same UID/GID). I set the whole directory tree to > mail_spool_t (thinking I'd avoid any SELinux access issues that way). > > What is odd is that it fails when SELinux is in enforcing mode, but not > in permissive, BUT I don't get any errors when it fails (e.g. no > "denied" messages in the kernel or audit logs). > > I've straced the daemon, and it fails at a chdir(). I know the > permissions are okay (it works when the system is in permissive mode), > so I figured it has to be related to SELinux, but I can't figure out > how. > > Suggestions? semodule -DB will turn on all dontaudit rules. Try your test. semodule -B will turn rules back on. Check for AVC messages. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkggnF0ACgkQrlYvE4MpobPbbACfVCswQcrmWou9ukmJLwAtQQr4 TukAoNis0d5u6YyiX6TzJDCZqNxuI1lf =HFTt -----END PGP SIGNATURE----- From cmadams at hiwaay.net Tue May 6 18:15:12 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Tue, 6 May 2008 13:15:12 -0500 Subject: Odd problem with dovecot In-Reply-To: <48209C5E.9030007@redhat.com> References: <20080502185017.GA1545656@hiwaay.net> <48209C5E.9030007@redhat.com> Message-ID: <20080506181512.GD1369436@hiwaay.net> Once upon a time, Daniel J Walsh said: > Chris Adams wrote: > > What is odd is that it fails when SELinux is in enforcing mode, but not > > in permissive, BUT I don't get any errors when it fails (e.g. no > > "denied" messages in the kernel or audit logs). > semodule -DB > > will turn on all dontaudit rules. Sorry, I should have been more specific: this is on RHEL 5, which does not appear to have the -D option. However, looking at the dontaudit rules with sesearch (I wasn't aware of either dontaudit rules or the sesearch command before), I found the problem. The top-level directory was still default_t, and there's a "dontaudit dovecot_t default_t : dir { ioctl read gettr lock search };" rule. I changed that top-level directory and all is well. Thanks. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From bruno at wolff.to Wed May 7 15:55:43 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 7 May 2008 10:55:43 -0500 Subject: selinux config - no warning during upgrades Message-ID: <20080507155543.GA5033@wolff.to> I recently did a yum upgrade from Fedora Core 5 to Rawhide and afterwards I eventually noticed that I was getting warnings about a NULL security context. I then tracked this down to not having a proper selinux user configuration. Since I was using the default, I expected things would work or at least that there would be *.rpmnew files that acted as a hint that something needed to be looked at. Also, in order to find out what the default was I ended up looking at some other machines that had more recent installs, because there didn't seem to be any obvious place to look on the affected machine for what reasonable default values were. From sds at tycho.nsa.gov Wed May 7 17:31:38 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 07 May 2008 13:31:38 -0400 Subject: selinux config - no warning during upgrades In-Reply-To: <20080507155543.GA5033@wolff.to> References: <20080507155543.GA5033@wolff.to> Message-ID: <1210181498.6434.103.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-05-07 at 10:55 -0500, Bruno Wolff III wrote: > I recently did a yum upgrade from Fedora Core 5 to Rawhide and afterwards > I eventually noticed that I was getting warnings about a NULL security > context. I then tracked this down to not having a proper selinux user > configuration. > > Since I was using the default, I expected things would work or at least that > there would be *.rpmnew files that acted as a hint that something needed > to be looked at. Also, in order to find out what the default was I ended up > looking at some other machines that had more recent installs, because there > didn't seem to be any obvious place to look on the affected machine for > what reasonable default values were. Can you provide more details, please? -- Stephen Smalley National Security Agency From bruno at wolff.to Wed May 7 18:47:58 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 7 May 2008 13:47:58 -0500 Subject: selinux config - no warning during upgrades In-Reply-To: <1210181498.6434.103.camel@moss-spartans.epoch.ncsc.mil> References: <20080507155543.GA5033@wolff.to> <1210181498.6434.103.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080507184758.GA21231@wolff.to> On Wed, May 07, 2008 at 13:31:38 -0400, Stephen Smalley wrote: > > On Wed, 2008-05-07 at 10:55 -0500, Bruno Wolff III wrote: > > I recently did a yum upgrade from Fedora Core 5 to Rawhide and afterwards > > I eventually noticed that I was getting warnings about a NULL security > > context. I then tracked this down to not having a proper selinux user > > configuration. > > > > Since I was using the default, I expected things would work or at least that > > there would be *.rpmnew files that acted as a hint that something needed > > to be looked at. Also, in order to find out what the default was I ended up > > looking at some other machines that had more recent installs, because there > > didn't seem to be any obvious place to look on the affected machine for > > what reasonable default values were. > > Can you provide more details, please? Here is a sample log messages: May 4 05:00:01 wolff crond[16709]: (bruno) NULL security context for user, but SELinux in permissive mode, continuing () I didn't save the original selinux attached to __default__. It might have been user_u; it definitely wasn't unconfined_u which is what I got with a fresh install on another machine. Besides fixing up the login user mapping, I also fixed up the user mapping to prefix, mls level, range and roles. There were several new selinux users that weren't in the list I got after the upgrade. Once I have everything matching that of the fresh install, I stopped seeing the NULL security context messages. I can't say I expected that the upgrade would work without manual intervention when going from FC5 to F9. But I would have liked to have gotten some hint that I should look at things. And if I hadn't had another machine with a fresh install to compare against, having some way to do that on a machine would be nice. Normally things stick *.rpmnew files in /etc, but I suspect that would encourange people to copy it over rather than using semanage to update things, so that may not be a good solution for selinux. From dwalsh at redhat.com Wed May 7 19:36:40 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 07 May 2008 15:36:40 -0400 Subject: selinux config - no warning during upgrades In-Reply-To: <20080507184758.GA21231@wolff.to> References: <20080507155543.GA5033@wolff.to> <1210181498.6434.103.camel@moss-spartans.epoch.ncsc.mil> <20080507184758.GA21231@wolff.to> Message-ID: <482204C8.4010700@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bruno Wolff III wrote: > On Wed, May 07, 2008 at 13:31:38 -0400, > Stephen Smalley wrote: >> On Wed, 2008-05-07 at 10:55 -0500, Bruno Wolff III wrote: >>> I recently did a yum upgrade from Fedora Core 5 to Rawhide and afterwards >>> I eventually noticed that I was getting warnings about a NULL security >>> context. I then tracked this down to not having a proper selinux user >>> configuration. >>> >>> Since I was using the default, I expected things would work or at least that >>> there would be *.rpmnew files that acted as a hint that something needed >>> to be looked at. Also, in order to find out what the default was I ended up >>> looking at some other machines that had more recent installs, because there >>> didn't seem to be any obvious place to look on the affected machine for >>> what reasonable default values were. >> Can you provide more details, please? > > Here is a sample log messages: > May 4 05:00:01 wolff crond[16709]: (bruno) NULL security context for user, but SELinux in permissive mode, continuing () > > I didn't save the original selinux attached to __default__. It might have been > user_u; it definitely wasn't unconfined_u which is what I got with a fresh > install on another machine. Besides fixing up the login user mapping, I also > fixed up the user mapping to prefix, mls level, range and roles. There were > several new selinux users that weren't in the list I got after the upgrade. > Once I have everything matching that of the fresh install, I stopped seeing > the NULL security context messages. > > I can't say I expected that the upgrade would work without manual intervention > when going from FC5 to F9. But I would have liked to have gotten some hint > that I should look at things. And if I hadn't had another machine with a fresh > install to compare against, having some way to do that on a machine would be > nice. Normally things stick *.rpmnew files in /etc, but I suspect that would > encourange people to copy it over rather than using semanage to update things, > so that may not be a good solution for selinux. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I would advise you to do a full relabel. Upgrades are shakey when going from one release to the next, but going from Fedora 5 to Rawhide, is really a major change. touch /.autorelabel reboot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgiBMgACgkQrlYvE4MpobNGkwCgsunCL0uItsqFSdEvaubSAmoa mokAoJFVQgDdoa7xHoFb+OVUGl+L2jL8 =N58L -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Wed May 7 19:46:10 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 07 May 2008 15:46:10 -0400 Subject: selinux config - no warning during upgrades In-Reply-To: <20080507184758.GA21231@wolff.to> References: <20080507155543.GA5033@wolff.to> <1210181498.6434.103.camel@moss-spartans.epoch.ncsc.mil> <20080507184758.GA21231@wolff.to> Message-ID: <1210189570.6434.125.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-05-07 at 13:47 -0500, Bruno Wolff III wrote: > On Wed, May 07, 2008 at 13:31:38 -0400, > Stephen Smalley wrote: > > > > On Wed, 2008-05-07 at 10:55 -0500, Bruno Wolff III wrote: > > > I recently did a yum upgrade from Fedora Core 5 to Rawhide and afterwards > > > I eventually noticed that I was getting warnings about a NULL security > > > context. I then tracked this down to not having a proper selinux user > > > configuration. > > > > > > Since I was using the default, I expected things would work or at least that > > > there would be *.rpmnew files that acted as a hint that something needed > > > to be looked at. Also, in order to find out what the default was I ended up > > > looking at some other machines that had more recent installs, because there > > > didn't seem to be any obvious place to look on the affected machine for > > > what reasonable default values were. > > > > Can you provide more details, please? > > Here is a sample log messages: > May 4 05:00:01 wolff crond[16709]: (bruno) NULL security context for user, but SELinux in permissive mode, continuing () > > I didn't save the original selinux attached to __default__. It might have been > user_u; it definitely wasn't unconfined_u which is what I got with a fresh > install on another machine. Besides fixing up the login user mapping, I also > fixed up the user mapping to prefix, mls level, range and roles. There were > several new selinux users that weren't in the list I got after the upgrade. > Once I have everything matching that of the fresh install, I stopped seeing > the NULL security context messages. > > I can't say I expected that the upgrade would work without manual intervention > when going from FC5 to F9. But I would have liked to have gotten some hint > that I should look at things. And if I hadn't had another machine with a fresh > install to compare against, having some way to do that on a machine would be > nice. Normally things stick *.rpmnew files in /etc, but I suspect that would > encourange people to copy it over rather than using semanage to update things, > so that may not be a good solution for selinux. Ok, that's a known deficiency of how seusers is managed; it isn't managed by rpm and there isn't a clean split between base policy definitions and user customizations there. The switch to unconfined_u came with the merging of strict and targeted policies into one policy, and that happened in F8. I suspect that there was some hackery in the F8 policy package to allow upgrades from F7 to work, but jumping straight from F5 to F9 wouldn't have done the same. -- Stephen Smalley National Security Agency From bruno at wolff.to Wed May 7 20:08:22 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 7 May 2008 15:08:22 -0500 Subject: selinux config - no warning during upgrades In-Reply-To: <1210189570.6434.125.camel@moss-spartans.epoch.ncsc.mil> References: <20080507155543.GA5033@wolff.to> <1210181498.6434.103.camel@moss-spartans.epoch.ncsc.mil> <20080507184758.GA21231@wolff.to> <1210189570.6434.125.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20080507200822.GA30658@wolff.to> On Wed, May 07, 2008 at 15:46:10 -0400, Stephen Smalley wrote: > > Ok, that's a known deficiency of how seusers is managed; it isn't > managed by rpm and there isn't a clean split between base policy > definitions and user customizations there. > > The switch to unconfined_u came with the merging of strict and targeted > policies into one policy, and that happened in F8. I suspect that there > was some hackery in the F8 policy package to allow upgrades from F7 to > work, but jumping straight from F5 to F9 wouldn't have done the same. Thanks for the explanation. From bruno at wolff.to Wed May 7 20:53:27 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 7 May 2008 15:53:27 -0500 Subject: selinux config - no warning during upgrades In-Reply-To: <482204C8.4010700@redhat.com> References: <20080507155543.GA5033@wolff.to> <1210181498.6434.103.camel@moss-spartans.epoch.ncsc.mil> <20080507184758.GA21231@wolff.to> <482204C8.4010700@redhat.com> Message-ID: <20080507205327.GA26855@wolff.to> On Wed, May 07, 2008 at 15:36:40 -0400, Daniel J Walsh wrote: > I would advise you to do a full relabel. Upgrades are shakey when going > from one release to the next, but going from Fedora 5 to Rawhide, is > really a major change. > > touch /.autorelabel > reboot I was aware of that. Because I have several million (tiny) files on that box I opted for doing a restorecon instead. The vast majority of the files are on their own file system and I skipped them when doing the restorecon. In the long run I want to store that data differently and will do a full relabel then. I also need to check to see how selinux is interacting with my qmail setup so I can go back to enforcing mode. Dealing with the NULL security log messages was the first step in that process. From Katrina.Scally at gdc4s.com Wed May 7 21:29:37 2008 From: Katrina.Scally at gdc4s.com (Scally, Katrina-P54861) Date: Wed, 7 May 2008 14:29:37 -0700 Subject: Pam upgrade problem Message-ID: <2B0195B08BA41748A38C4D58ADF44F2C02654370@AZ25EXM01.gddsi.com> My original problem was With the default pam options, pam_selinux is unable to get the user context, during login it would default to system_u:system_r:local_login_t context. I got around this problem for some time by changing /etc/pam.d/login line to Session required pam_selinux.so open verbose select_context. I found on http://www.nsa.gov/selinux/list-archive/0706/21321.cfm that this was a bug in pam and by upgrading from pam-0.1.77-66.23.i386.rpm (or earlier versions) to pam-0.1.99.6.2-3.26.el5.i386.rpm would get rid of the problem. This upgrade has actually caused more problems. I can no longer even log into my virtual machine with my install in enforcing, in permissive mode it is fine. Unfortunately there are no AVC denials when. My Virtual Machine is running RHEL5, libselinux-1.1.33.4-4.el5.i386.rpm, and reference policy that came with the Bedrock tool from Tresys refpolicy-20070417.tar.bz2 Possibly I missed something while upgrading pam? I have looked through all of the files the pam-0.1.99.6.2-3.26.el5.i386.rpm has installed and they all seem correct. Thanks in advance, -K > This email message is for the sole use of the intended recipient(s) > and may contain GDC4S confidential or privileged information. Any > unauthorized review, use, disclosure or distribution is prohibited. If > you are not an intended recipient, please contact the sender by reply > email and destroy all copies of the original message. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpebenito at tresys.com Thu May 8 14:13:28 2008 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Thu, 08 May 2008 10:13:28 -0400 Subject: Pam upgrade problem In-Reply-To: <2B0195B08BA41748A38C4D58ADF44F2C02654370@AZ25EXM01.gddsi.com> References: <2B0195B08BA41748A38C4D58ADF44F2C02654370@AZ25EXM01.gddsi.com> Message-ID: <1210256008.8778.30.camel@gorn> On Wed, 2008-05-07 at 14:29 -0700, Scally, Katrina-P54861 wrote: > My original problem was With the default pam options, pam_selinux is > unable to get the user context, during login it would default to > system_u:system_r:local_login_t context. I got around this problem for > some time by changing /etc/pam.d/login line to > > Session required pam_selinux.so open verbose select_context. > I found on http://www.nsa.gov/selinux/list-archive/0706/21321.cfm that > this was a bug in pam and by upgrading from pam-0.1.77-66.23.i386.rpm > (or earlier versions) to pam-0.1.99.6.2-3.26.el5.i386.rpm would get > rid of the problem. This upgrade has actually caused more problems. I > can no longer even log into my virtual machine with my install in > enforcing, in permissive mode it is fine. Unfortunately there are no > AVC denials when. > > My Virtual Machine is running RHEL5, > libselinux-1.1.33.4-4.el5.i386.rpm, and reference policy that came > with the Bedrock tool from Tresys refpolicy-20070417.tar.bz2 > > Possibly I missed something while upgrading pam? I have looked through > all of the files the pam-0.1.99.6.2-3.26.el5.i386.rpm has installed > and they all seem correct. Can you provide more information? Are you logging in at the console, ssh, or gdm? I can't find much difference between the RHEL5 policy and refpolicy for local logins. Have you tried the stock RHEL5 policy to see if it stil fails? -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From selinux at hilbig.name Thu May 8 17:14:12 2008 From: selinux at hilbig.name (D. Hilbig) Date: Thu, 8 May 2008 10:14:12 -0700 Subject: SELinux, apache/php and qmail's sendmail Message-ID: <3A90BB5DD96B4F8EA8CFAB64807C85E0@LAP21> I use qmail instead of sendmail on RHEL v5 and I could use some advice on setting contexts for qmail's sendmail so that apache/php can use it. Below are the files and directories involved with qmail's sendmail (and delivery to queue) allow apache/php to invoke qmail's sendmail program: /var/qmail/bin/sendmail allow qmail's sendmail to invoke qmail-inject program: /var/qmail/bin/qmail-inject allow qmail-inject to list the contents of the config files directory: /var/qmail/control allow qmail-inject to read the config files it uses: /var/qmail/control/defaultdomain /var/qmail/control/deaulthost /var/qmail/control/idhost /var/qmail/control/plusdomain /var/qmail/control/me allow qmail-inject to invoke qmail-queue program: /var/qmail/bin/qmail-queue allow qmail-queue to read the config file used by the 'taps' patch: /var/qmail/control/taps allow qmail-queue to put a message into the queue: (create, edit, delete and link files) /var/qmail/queue/pid (and subdirectories) /var/qmail/queue/mess (and subdirectories) /var/qmail/queue/intd (and subdirectories) /var/qmail/queue/todo (and subdirectories) For testing I specified the context "httpd_sys_content_t" but I know that it isn't the desired context. What context(s) should I specify for the aforementioned programs, directories and configuration files? Are there any other things I should do or consider besides setting the context(s)? Your guidance is greatly appreciated. From selinux at hilbig.name Thu May 8 17:14:12 2008 From: selinux at hilbig.name (D. Hilbig) Date: Thu, 8 May 2008 10:14:12 -0700 Subject: SELinux, apache/php and qmail's sendmail Message-ID: <3A90BB5DD96B4F8EA8CFAB64807C85E0@LAP21> I use qmail instead of sendmail on RHEL v5 and I could use some advice on setting contexts for qmail's sendmail so that apache/php can use it. Below are the files and directories involved with qmail's sendmail (and delivery to queue) allow apache/php to invoke qmail's sendmail program: /var/qmail/bin/sendmail allow qmail's sendmail to invoke qmail-inject program: /var/qmail/bin/qmail-inject allow qmail-inject to list the contents of the config files directory: /var/qmail/control allow qmail-inject to read the config files it uses: /var/qmail/control/defaultdomain /var/qmail/control/deaulthost /var/qmail/control/idhost /var/qmail/control/plusdomain /var/qmail/control/me allow qmail-inject to invoke qmail-queue program: /var/qmail/bin/qmail-queue allow qmail-queue to read the config file used by the 'taps' patch: /var/qmail/control/taps allow qmail-queue to put a message into the queue: (create, edit, delete and link files) /var/qmail/queue/pid (and subdirectories) /var/qmail/queue/mess (and subdirectories) /var/qmail/queue/intd (and subdirectories) /var/qmail/queue/todo (and subdirectories) For testing I specified the context "httpd_sys_content_t" but I know that it isn't the desired context. What context(s) should I specify for the aforementioned programs, directories and configuration files? Are there any other things I should do or consider besides setting the context(s)? Your guidance is greatly appreciated. From eparis at redhat.com Fri May 9 19:33:10 2008 From: eparis at redhat.com (Eric Paris) Date: Fri, 09 May 2008 15:33:10 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210361590.3057.5.camel@localhost.localdomain> On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > One question that has come up is whether the patch to support setting > unknown file labels is sufficient to support the buildsys needs, or > whether something more is required. My impression is that all we truly > need is: > 1) support for setting unknown file labels for use by rpm, and > 2) bind mount /dev/null over selinux/load within the chroot so that > policy loads within the chroot do nothing rather than changing the build > host's policy, and > 3) bind mount a regular empty file over selinux/context within the > chroot so that attempts to validate/canonicalize contexts by rpm will > always return the original value w/o trying to validate against the > build host's policy. So I ran livecd-creator today with a couple of things inside the chroot /selinux load -> /dev/null null -> /dev/null context = [blank file] mls = 1 enforcing = 1 policyvers = 22 This was attempting to build a F9 livecd on an F9 box, so I wasn't worried about the labeling issues (although the kernel in question is patched to support unknown labels) Things blew up spectacularly :) warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 Installing: libgcc ##################### [ 1/129] error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255 Installing: setup ##################### [ 2/129] error: unpacking of archive failed on file /etc/bashrc: cpio: lsetfilecon Installing: filesystem ##################### [ 3/129] error: unpacking of archive failed on file /: cpio: lsetfilecon Installing: basesystem ##################### [ 4/129] Installing: ncurses-base ##################### [ 5/129] error: unpacking of archive failed on file /etc/terminfo: cpio: lsetfilecon So I took a look at what's in "context" and I see "t:s00s0s0s0s0s0s0s0s0s0:s0" which just seems horrible... I assume this is a libselinux function using this. I wonder if I change that to use O_TRUNC if things would go a bit more smoothly.... -Eric From eparis at redhat.com Fri May 9 20:00:17 2008 From: eparis at redhat.com (Eric Paris) Date: Fri, 09 May 2008 16:00:17 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210361590.3057.5.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> Message-ID: <1210363217.3057.9.camel@localhost.localdomain> On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote: > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > > One question that has come up is whether the patch to support setting > > unknown file labels is sufficient to support the buildsys needs, or > > whether something more is required. My impression is that all we truly > > need is: > > 1) support for setting unknown file labels for use by rpm, and > > 2) bind mount /dev/null over selinux/load within the chroot so that > > policy loads within the chroot do nothing rather than changing the build > > host's policy, and > > 3) bind mount a regular empty file over selinux/context within the > > chroot so that attempts to validate/canonicalize contexts by rpm will > > always return the original value w/o trying to validate against the > > build host's policy. > > So I ran livecd-creator today with a couple of things inside the > chroot /selinux > > load -> /dev/null > null -> /dev/null > context = [blank file] > mls = 1 > enforcing = 1 > policyvers = 22 > > This was attempting to build a F9 livecd on an F9 box, so I wasn't > worried about the labeling issues (although the kernel in question is > patched to support unknown labels) > > Things blew up spectacularly :) So I added O_TRUNC to both of the callers to /selinux/context in libselinux and that took care of the lsetfilecon() crap but I still get tons and tons of "scriptlet failed, exit status 255" Anyone have ideas/suggestions how to debug those more? warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 Installing: libgcc ##################### [ 1/129] error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255 Installing: setup ##################### [ 2/129] Installing: filesystem ##################### [ 3/129] Installing: basesystem ##################### [ 4/129] Installing: ncurses-base ##################### [ 5/129] Installing: tzdata ##################### [ 6/129] Installing: rootfiles ##################### [ 7/129] Installing: glibc ##################### [ 8/129] error: %post(glibc-2.8-3.x86_64) scriptlet failed, exit status 255 Installing: ncurses-libs ##################### [ 9/129] error: %post(ncurses-libs-5.6-16.20080301.fc9.x86_64) scriptlet failed, exit status 255 Installing: popt ##################### [ 10/129] error: %post(popt-1.13-3.fc9.x86_64) scriptlet failed, exit status 255 Installing: zlib ##################### [ 11/129] error: %post(zlib-1.2.3-18.fc9.x86_64) scriptlet failed, exit status 255 From paul at city-fan.org Sat May 10 22:48:44 2008 From: paul at city-fan.org (Paul Howarth) Date: Sat, 10 May 2008 23:48:44 +0100 Subject: Fedora buildsys and SELinux In-Reply-To: <1210363217.3057.9.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> Message-ID: <20080510234844.23ff8872@metropolis.intra.city-fan.org> On Fri, 09 May 2008 16:00:17 -0400 Eric Paris wrote: > On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote: > > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > > > One question that has come up is whether the patch to support > > > setting unknown file labels is sufficient to support the buildsys > > > needs, or whether something more is required. My impression is > > > that all we truly need is: > > > 1) support for setting unknown file labels for use by rpm, and > > > 2) bind mount /dev/null over selinux/load within the chroot so > > > that policy loads within the chroot do nothing rather than > > > changing the build host's policy, and > > > 3) bind mount a regular empty file over selinux/context within the > > > chroot so that attempts to validate/canonicalize contexts by rpm > > > will always return the original value w/o trying to validate > > > against the build host's policy. > > > > So I ran livecd-creator today with a couple of things inside the > > chroot /selinux > > > > load -> /dev/null > > null -> /dev/null > > context = [blank file] > > mls = 1 > > enforcing = 1 > > policyvers = 22 > > > > This was attempting to build a F9 livecd on an F9 box, so I wasn't > > worried about the labeling issues (although the kernel in question > > is patched to support unknown labels) > > > > Things blew up spectacularly :) > > So I added O_TRUNC to both of the callers to /selinux/context in > libselinux and that took care of the lsetfilecon() crap but I still > get tons and tons of "scriptlet failed, exit status 255" > > Anyone have ideas/suggestions how to debug those more? > > warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID > 4f2a6fd2 Installing: libgcc > ##################### [ 1/129] error: %post(libgcc-4.3.0-8.x86_64) > scriptlet failed, exit status 255 Installing: > setup ##################### [ 2/129] > Installing: filesystem ##################### > [ 3/129] Installing: basesystem > ##################### [ 4/129] Installing: > ncurses-base ##################### [ 5/129] > Installing: tzdata ##################### > [ 6/129] Installing: rootfiles > ##################### [ 7/129] Installing: > glibc ##################### [ 8/129] error: > %post(glibc-2.8-3.x86_64) scriptlet failed, exit status 255 > Installing: ncurses-libs ##################### > [ 9/129] error: %post(ncurses-libs-5.6-16.20080301.fc9.x86_64) > scriptlet failed, exit status 255 Installing: > popt ##################### [ 10/129] error: > %post(popt-1.13-3.fc9.x86_64) scriptlet failed, exit status 255 > Installing: zlib ##################### > [ 11/129] error: %post(zlib-1.2.3-18.fc9.x86_64) scriptlet failed, > exit status 255 These all look like library packages so I'd hazard a guess that the thing that's failing is ldconfig. Perhaps you could replace ldconfig with a wrapper than runs it under strace? Paul. From sds at tycho.nsa.gov Mon May 12 12:08:38 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 12 May 2008 08:08:38 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210361590.3057.5.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> Message-ID: <1210594118.6206.1.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote: > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > > One question that has come up is whether the patch to support setting > > unknown file labels is sufficient to support the buildsys needs, or > > whether something more is required. My impression is that all we truly > > need is: > > 1) support for setting unknown file labels for use by rpm, and > > 2) bind mount /dev/null over selinux/load within the chroot so that > > policy loads within the chroot do nothing rather than changing the build > > host's policy, and > > 3) bind mount a regular empty file over selinux/context within the > > chroot so that attempts to validate/canonicalize contexts by rpm will > > always return the original value w/o trying to validate against the > > build host's policy. > > So I ran livecd-creator today with a couple of things inside the > chroot /selinux > > load -> /dev/null > null -> /dev/null > context = [blank file] > mls = 1 > enforcing = 1 > policyvers = 22 > > This was attempting to build a F9 livecd on an F9 box, so I wasn't > worried about the labeling issues (although the kernel in question is > patched to support unknown labels) > > Things blew up spectacularly :) > > warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 > Installing: libgcc ##################### [ 1/129] > error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255 > Installing: setup ##################### [ 2/129] > error: unpacking of archive failed on file /etc/bashrc: cpio: lsetfilecon > Installing: filesystem ##################### [ 3/129] > error: unpacking of archive failed on file /: cpio: lsetfilecon > Installing: basesystem ##################### [ 4/129] > Installing: ncurses-base ##################### [ 5/129] > error: unpacking of archive failed on file /etc/terminfo: cpio: lsetfilecon > > So I took a look at what's in "context" and I see > "t:s00s0s0s0s0s0s0s0s0s0:s0" which just seems horrible... I assume this > is a libselinux function using this. I wonder if I change that to use > O_TRUNC if things would go a bit more smoothly.... I think it would be better to just adjust userspace as we discussed to perform context validation against the target policy rather than the build host policy as is done by setfiles -c. Or disable context validation altogether in userspace in that instance. Or create some kind of "identity" node in the selinuxfs filesystem that is transaction-based like the existing selinuxfs nodes and always returns whatever was written to it, then bind mount that on top of /selinux/context. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Mon May 12 12:17:27 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 12 May 2008 08:17:27 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210363217.3057.9.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> Message-ID: <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-05-09 at 16:00 -0400, Eric Paris wrote: > On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote: > > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > > > One question that has come up is whether the patch to support setting > > > unknown file labels is sufficient to support the buildsys needs, or > > > whether something more is required. My impression is that all we truly > > > need is: > > > 1) support for setting unknown file labels for use by rpm, and > > > 2) bind mount /dev/null over selinux/load within the chroot so that > > > policy loads within the chroot do nothing rather than changing the build > > > host's policy, and > > > 3) bind mount a regular empty file over selinux/context within the > > > chroot so that attempts to validate/canonicalize contexts by rpm will > > > always return the original value w/o trying to validate against the > > > build host's policy. > > > > So I ran livecd-creator today with a couple of things inside the > > chroot /selinux > > > > load -> /dev/null > > null -> /dev/null > > context = [blank file] > > mls = 1 > > enforcing = 1 > > policyvers = 22 > > > > This was attempting to build a F9 livecd on an F9 box, so I wasn't > > worried about the labeling issues (although the kernel in question is > > patched to support unknown labels) > > > > Things blew up spectacularly :) > > So I added O_TRUNC to both of the callers to /selinux/context in > libselinux and that took care of the lsetfilecon() crap but I still get > tons and tons of "scriptlet failed, exit status 255" > > Anyone have ideas/suggestions how to debug those more? Ah, it is likely failing on the rpm_execcon(3) -> security_compute_create(3) call i.e. writing to /selinux/create. Which computes the context in which to run the scriptlet or helper from the policy. If that returns the same as rpm's own context, then we fall back to rpm_script_t. So this affects things like ldconfig. I increasingly suspect we're better off not mounting selinuxfs within the chroot at all and addressing any issues that arise via policy. > warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 > Installing: libgcc ##################### [ 1/129] > error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255 > Installing: setup ##################### [ 2/129] > Installing: filesystem ##################### [ 3/129] > Installing: basesystem ##################### [ 4/129] > Installing: ncurses-base ##################### [ 5/129] > Installing: tzdata ##################### [ 6/129] > Installing: rootfiles ##################### [ 7/129] > Installing: glibc ##################### [ 8/129] > error: %post(glibc-2.8-3.x86_64) scriptlet failed, exit status 255 > Installing: ncurses-libs ##################### [ 9/129] > error: %post(ncurses-libs-5.6-16.20080301.fc9.x86_64) scriptlet failed, exit status 255 > Installing: popt ##################### [ 10/129] > error: %post(popt-1.13-3.fc9.x86_64) scriptlet failed, exit status 255 > Installing: zlib ##################### [ 11/129] > error: %post(zlib-1.2.3-18.fc9.x86_64) scriptlet failed, exit status 255 -- Stephen Smalley National Security Agency From eparis at redhat.com Mon May 12 14:45:32 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 12 May 2008 10:45:32 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210594118.6206.1.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210594118.6206.1.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210603532.3228.16.camel@localhost.localdomain> On Mon, 2008-05-12 at 08:08 -0400, Stephen Smalley wrote: > On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote: > > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > > > One question that has come up is whether the patch to support setting > > > unknown file labels is sufficient to support the buildsys needs, or > > > whether something more is required. My impression is that all we truly > > > need is: > > > 1) support for setting unknown file labels for use by rpm, and > > > 2) bind mount /dev/null over selinux/load within the chroot so that > > > policy loads within the chroot do nothing rather than changing the build > > > host's policy, and > > > 3) bind mount a regular empty file over selinux/context within the > > > chroot so that attempts to validate/canonicalize contexts by rpm will > > > always return the original value w/o trying to validate against the > > > build host's policy. > > > > So I ran livecd-creator today with a couple of things inside the > > chroot /selinux > > > > load -> /dev/null > > null -> /dev/null > > context = [blank file] > > mls = 1 > > enforcing = 1 > > policyvers = 22 > > > > This was attempting to build a F9 livecd on an F9 box, so I wasn't > > worried about the labeling issues (although the kernel in question is > > patched to support unknown labels) > > > > Things blew up spectacularly :) > > > > warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 > > Installing: libgcc ##################### [ 1/129] > > error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255 > > Installing: setup ##################### [ 2/129] > > error: unpacking of archive failed on file /etc/bashrc: cpio: lsetfilecon > > Installing: filesystem ##################### [ 3/129] > > error: unpacking of archive failed on file /: cpio: lsetfilecon > > Installing: basesystem ##################### [ 4/129] > > Installing: ncurses-base ##################### [ 5/129] > > error: unpacking of archive failed on file /etc/terminfo: cpio: lsetfilecon > > > > So I took a look at what's in "context" and I see > > "t:s00s0s0s0s0s0s0s0s0s0:s0" which just seems horrible... I assume this > > is a libselinux function using this. I wonder if I change that to use > > O_TRUNC if things would go a bit more smoothly.... > > I think it would be better to just adjust userspace as we discussed to > perform context validation against the target policy rather than the > build host policy as is done by setfiles -c. On second thought is that even possible? As I recall selinux-policy-targeted rpm is installed about 128/129 packages when I do my livecd create. That means that we didn't even have an 'inside chroot' policy to check against for the vast majority of this operation. I'd assume that building the appropriete mock buildroot would have the same problem. Wonder how people would feel about really hacking up the buildroot creator to force install selinux stuff first and then run the full install transaction set.... > Or disable context validation altogether in userspace in that instance. Anyone have suggestions on how to go about this? > Or create some kind of "identity" node in the selinuxfs filesystem that > is transaction-based like the existing selinuxfs nodes and always > returns whatever was written to it, then bind mount that on top > of /selinux/context. I did get that out of using a plain file and using O_TRUNC in libselinux eventually. From sds at tycho.nsa.gov Mon May 12 14:53:46 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 12 May 2008 10:53:46 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210603532.3228.16.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210594118.6206.1.camel@moss-spartans.epoch.ncsc.mil> <1210603532.3228.16.camel@localhost.localdomain> Message-ID: <1210604026.6206.46.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-05-12 at 10:45 -0400, Eric Paris wrote: > On Mon, 2008-05-12 at 08:08 -0400, Stephen Smalley wrote: > > On Fri, 2008-05-09 at 15:33 -0400, Eric Paris wrote: > > > On Fri, 2008-05-02 at 13:20 -0400, Stephen Smalley wrote: > > > > One question that has come up is whether the patch to support setting > > > > unknown file labels is sufficient to support the buildsys needs, or > > > > whether something more is required. My impression is that all we truly > > > > need is: > > > > 1) support for setting unknown file labels for use by rpm, and > > > > 2) bind mount /dev/null over selinux/load within the chroot so that > > > > policy loads within the chroot do nothing rather than changing the build > > > > host's policy, and > > > > 3) bind mount a regular empty file over selinux/context within the > > > > chroot so that attempts to validate/canonicalize contexts by rpm will > > > > always return the original value w/o trying to validate against the > > > > build host's policy. > > > > > > So I ran livecd-creator today with a couple of things inside the > > > chroot /selinux > > > > > > load -> /dev/null > > > null -> /dev/null > > > context = [blank file] > > > mls = 1 > > > enforcing = 1 > > > policyvers = 22 > > > > > > This was attempting to build a F9 livecd on an F9 box, so I wasn't > > > worried about the labeling issues (although the kernel in question is > > > patched to support unknown labels) > > > > > > Things blew up spectacularly :) > > > > > > warning: libgcc-4.3.0-8: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 > > > Installing: libgcc ##################### [ 1/129] > > > error: %post(libgcc-4.3.0-8.x86_64) scriptlet failed, exit status 255 > > > Installing: setup ##################### [ 2/129] > > > error: unpacking of archive failed on file /etc/bashrc: cpio: lsetfilecon > > > Installing: filesystem ##################### [ 3/129] > > > error: unpacking of archive failed on file /: cpio: lsetfilecon > > > Installing: basesystem ##################### [ 4/129] > > > Installing: ncurses-base ##################### [ 5/129] > > > error: unpacking of archive failed on file /etc/terminfo: cpio: lsetfilecon > > > > > > So I took a look at what's in "context" and I see > > > "t:s00s0s0s0s0s0s0s0s0s0:s0" which just seems horrible... I assume this > > > is a libselinux function using this. I wonder if I change that to use > > > O_TRUNC if things would go a bit more smoothly.... > > > > I think it would be better to just adjust userspace as we discussed to > > perform context validation against the target policy rather than the > > build host policy as is done by setfiles -c. > > On second thought is that even possible? As I recall > selinux-policy-targeted rpm is installed about 128/129 packages when I > do my livecd create. That means that we didn't even have an 'inside > chroot' policy to check against for the vast majority of this operation. > I'd assume that building the appropriete mock buildroot would have the > same problem. Wonder how people would feel about really hacking up the > buildroot creator to force install selinux stuff first and then run the > full install transaction set.... For a normal install, anaconda has to set down an initial file contexts file and load a policy to get things started IIRC - otherwise rpm wouldn't be able to label the files it sets down prior to installing selinux-policy*. > > Or disable context validation altogether in userspace in that instance. > > Anyone have suggestions on how to go about this? Absence of any /selinux/context at all should automatically do that. > > Or create some kind of "identity" node in the selinuxfs filesystem that > > is transaction-based like the existing selinuxfs nodes and always > > returns whatever was written to it, then bind mount that on top > > of /selinux/context. > > I did get that out of using a plain file and using O_TRUNC in libselinux > eventually. Yes, but I don't see how requiring the use of a hacked-up libselinux is any better or more workable. -- Stephen Smalley National Security Agency From notting at redhat.com Mon May 12 15:26:29 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 12 May 2008 11:26:29 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210603532.3228.16.camel@localhost.localdomain> References: <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210594118.6206.1.camel@moss-spartans.epoch.ncsc.mil> <1210603532.3228.16.camel@localhost.localdomain> Message-ID: <20080512152629.GA12091@nostromo.devel.redhat.com> Eric Paris (eparis at redhat.com) said: > same problem. Wonder how people would feel about really hacking up the > buildroot creator to force install selinux stuff first and then run the > full install transaction set.... Due to dependencies, you can never load the policy 'first'. Bill From eparis at redhat.com Mon May 12 19:22:39 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 12 May 2008 15:22:39 -0400 Subject: upcoming selinux ioctl permission changes Message-ID: <1210620159.3228.39.camel@localhost.localdomain> I'm planning on pushing a patch to try to simplify ioctl permission checks in SELinux. This won't be upstreamed until the 2.6.27 merge window and we would like to see some more widespread testing first. So I plan to push this into the rawhide kernel in the next day or two. We certainly don't expect it to cause any problem so I'm really only mentioning it just in case and to put people on the lookout. If you happen to notice strange denials on ioctls please file a bug and cc me or send me an e-mail! http://marc.info/?l=selinux&m=121033736222066&w=2 -Eric From casmls at gmail.com Mon May 12 19:27:54 2008 From: casmls at gmail.com (Christoph A.) Date: Mon, 12 May 2008 21:27:54 +0200 Subject: firefox problems with: browser_confine_unconfined --> on Message-ID: <48289A3A.6060501@gmail.com> Hi, I'm looking forward do confine users (firefox, thunderbird). I played with xguest_u and I liked the behavior of firefox (home not writeable except ~/Downloads, ~/.mozilla), but I need other programms (thunderbird, ssh) to connect to the internet too, so I wanted to try the usual unconfined_u with browser_confine_unconfined set. I didn't find mutch about this boolean but I wanted to see, if with this boolean set, firefox of an unconfined user will behave like firefox of xguest_u. After setting the boolean firefox runs in its own domain (unconfined_mozilla_t) that looks fine. When I tried to save a picture to see if I can write to ~/ (not ~/Download) firefox hangs (immediately after klicking on "Save Image As...") and I had to use kill to terminate it. observing the audit.log file with tail -f shows: type=USER_AVC msg=audit(1210554417.821:80): user pid=1648 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.93 spid=1783 tpid=3412 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_mozilla_t:s0 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' If I set browser_confine_unconfined to 0 this problem doesn't occur. Should firefox (unconfined_mozilla_t) behave like firefox of xguest_u, or is this boolean for something different? thanks, Christoph A. PS: I'm using FC9. From katzj at redhat.com Mon May 12 20:33:10 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 12 May 2008 16:33:10 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <20080512152629.GA12091@nostromo.devel.redhat.com> References: <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210594118.6206.1.camel@moss-spartans.epoch.ncsc.mil> <1210603532.3228.16.camel@localhost.localdomain> <20080512152629.GA12091@nostromo.devel.redhat.com> Message-ID: <1210624390.20164.33.camel@aglarond.local> On Mon, 2008-05-12 at 11:26 -0400, Bill Nottingham wrote: > Eric Paris (eparis at redhat.com) said: > > same problem. Wonder how people would feel about really hacking up the > > buildroot creator to force install selinux stuff first and then run the > > full install transaction set.... > > Due to dependencies, you can never load the policy 'first'. Just to make this a little bit more explicit for others following along, we can't due this because loading the policy requires that the policy be installed on disk as well as things like load_policy being on disk. That depends on having libc, etc in the chroot as well. So ignoring questions of taste, you'd still have the chicken and egg problem. But as far as taste as concerned, hacking up every single thing that ever creates a chroot feels wrong, wrong, wrong, wrong, wrong. Especially because it's not little hacks, it's a big hack involving creating a new micro-transaction with only a subset of the packages. It also becomes "interesting" when you start to think about update operations within a chroot. Jeremy From katzj at redhat.com Mon May 12 20:33:07 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 12 May 2008 16:33:07 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210624387.20164.31.camel@aglarond.local> On Mon, 2008-05-12 at 08:17 -0400, Stephen Smalley wrote: > On Fri, 2008-05-09 at 16:00 -0400, Eric Paris wrote: > > So I added O_TRUNC to both of the callers to /selinux/context in > > libselinux and that took care of the lsetfilecon() crap but I still get > > tons and tons of "scriptlet failed, exit status 255" > > > > Anyone have ideas/suggestions how to debug those more? > > Ah, it is likely failing on the rpm_execcon(3) -> > security_compute_create(3) call i.e. writing to /selinux/create. > Which computes the context in which to run the scriptlet or helper from > the policy. If that returns the same as rpm's own context, then we fall > back to rpm_script_t. So this affects things like ldconfig. > > I increasingly suspect we're better off not mounting selinuxfs within > the chroot at all and addressing any issues that arise via policy. If we don't mount selinuxfs, then anything that attempts to figure out if SELinux is enabled (ie the fact that rpm checks if SELinux is enabled to determine whether or not to set the xattrs) will fail. Also, I don't remember for certain without looking, but even restorecon checks like that from what I remember. So we have to at least have some of /selinux present or we have to do deeper tricks with labeling outside of chroots which ... pain :-/ Jeremy From katzj at redhat.com Mon May 12 20:33:08 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 12 May 2008 16:33:08 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210604026.6206.46.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417002256.GA30919@nostromo.devel.redhat.com> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210594118.6206.1.camel@moss-spartans.epoch.ncsc.mil> <1210603532.3228.16.camel@localhost.localdomain> <1210604026.6206.46.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210624388.20164.32.camel@aglarond.local> On Mon, 2008-05-12 at 10:53 -0400, Stephen Smalley wrote: > > On second thought is that even possible? As I recall > > selinux-policy-targeted rpm is installed about 128/129 packages when I > > do my livecd create. That means that we didn't even have an 'inside > > chroot' policy to check against for the vast majority of this operation. > > I'd assume that building the appropriete mock buildroot would have the > > same problem. Wonder how people would feel about really hacking up the > > buildroot creator to force install selinux stuff first and then run the > > full install transaction set.... > > For a normal install, anaconda has to set down an initial file contexts > file and load a policy to get things started IIRC - otherwise rpm > wouldn't be able to label the files it sets down prior to installing > selinux-policy*. It uses the policy from outside the chroot until things are put into the chroot. This "works" for the anaconda case as we don't really fully[1] support installing a different environment than what your install images are built with Jeremy [1] We've actually done a lot of work to make this more supported, but SELinux is actually now the big blocker that I know of due to this reasoning. At least for things which count as similar, for certain values of that. > > > Or disable context validation altogether in userspace in that instance. > > > > Anyone have suggestions on how to go about this? > > Absence of any /selinux/context at all should automatically do that. > > > > Or create some kind of "identity" node in the selinuxfs filesystem that > > > is transaction-based like the existing selinuxfs nodes and always > > > returns whatever was written to it, then bind mount that on top > > > of /selinux/context. > > > > I did get that out of using a plain file and using O_TRUNC in libselinux > > eventually. > > Yes, but I don't see how requiring the use of a hacked-up libselinux is > any better or more workable. > From stephen.smalley at gmail.com Mon May 12 21:05:35 2008 From: stephen.smalley at gmail.com (Stephen Smalley) Date: Mon, 12 May 2008 17:05:35 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210624387.20164.31.camel@aglarond.local> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> Message-ID: <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz wrote: > On Mon, 2008-05-12 at 08:17 -0400, Stephen Smalley wrote: > > On Fri, 2008-05-09 at 16:00 -0400, Eric Paris wrote: > > > > So I added O_TRUNC to both of the callers to /selinux/context in > > > libselinux and that took care of the lsetfilecon() crap but I still get > > > tons and tons of "scriptlet failed, exit status 255" > > > > > > Anyone have ideas/suggestions how to debug those more? > > > > Ah, it is likely failing on the rpm_execcon(3) -> > > security_compute_create(3) call i.e. writing to /selinux/create. > > Which computes the context in which to run the scriptlet or helper from > > the policy. If that returns the same as rpm's own context, then we fall > > back to rpm_script_t. So this affects things like ldconfig. > > > > I increasingly suspect we're better off not mounting selinuxfs within > > the chroot at all and addressing any issues that arise via policy. > > If we don't mount selinuxfs, then anything that attempts to figure out > if SELinux is enabled (ie the fact that rpm checks if SELinux is enabled > to determine whether or not to set the xattrs) will fail. Also, I don't > remember for certain without looking, but even restorecon checks like > that from what I remember. So we have to at least have some of /selinux > present or we have to do deeper tricks with labeling outside of chroots > which ... pain :-/ That shouldn't actually be true - the fundamental test for whether or not SELinux is enabled is the presence or absence of selinuxfs in /proc/filesystems (i.e. is it registered in the kernel), not whether or not selinuxfs is actually mounted anywhere. The libselinux logic should fall back to that /proc/filesystems test. And looking at the libselinux code, it does appear to handle ENOENT on /selinux/context by skipping the normal context validation, so not having it present at all in /selinux within the chroot should help _unless_ rpm calls matchpathcon() will outside of the chroot (that's what I'm unclear on - when rpm is operating within the chroot and when it is operating outside the chroot). The only problem I see with not having selinuxfs mounted at all within the chroot or even providing fake /selinux nodes is that rpm_execcon() will then see SELinux as disabled and thus not try to run the scriptlet in a different domain; it should just fall back to a normal execve() in that situation. Which could be addressed in policy largely by collapsing rpm_script_t and rpm_t into a single domain. I'm not sure how much we are using the distinction at present - I think they are both effectively unconfined so it would only differ possibly in outbound type transitions. Anyway, I'd be interested in having Eric try the install with no selinuxfs mounted or fake selinux nodes within the chroot and see what happens, both in permissive mode and enforcing mode. From stephen.smalley at gmail.com Mon May 12 21:19:33 2008 From: stephen.smalley at gmail.com (Stephen Smalley) Date: Mon, 12 May 2008 17:19:33 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> References: <1208379430.5019.286.camel@calliope.phig.org> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> Message-ID: <43af0f430805121419p185f3630x4663a98ea1aedfa0@mail.gmail.com> On Mon, May 12, 2008 at 5:05 PM, Stephen Smalley wrote: > > On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz wrote: > > On Mon, 2008-05-12 at 08:17 -0400, Stephen Smalley wrote: > > > On Fri, 2008-05-09 at 16:00 -0400, Eric Paris wrote: > > > > > > So I added O_TRUNC to both of the callers to /selinux/context in > > > > libselinux and that took care of the lsetfilecon() crap but I still get > > > > tons and tons of "scriptlet failed, exit status 255" > > > > > > > > Anyone have ideas/suggestions how to debug those more? > > > > > > Ah, it is likely failing on the rpm_execcon(3) -> > > > security_compute_create(3) call i.e. writing to /selinux/create. > > > Which computes the context in which to run the scriptlet or helper from > > > the policy. If that returns the same as rpm's own context, then we fall > > > back to rpm_script_t. So this affects things like ldconfig. > > > > > > I increasingly suspect we're better off not mounting selinuxfs within > > > the chroot at all and addressing any issues that arise via policy. > > > > If we don't mount selinuxfs, then anything that attempts to figure out > > if SELinux is enabled (ie the fact that rpm checks if SELinux is enabled > > to determine whether or not to set the xattrs) will fail. Also, I don't > > remember for certain without looking, but even restorecon checks like > > that from what I remember. So we have to at least have some of /selinux > > present or we have to do deeper tricks with labeling outside of chroots > > which ... pain :-/ > > That shouldn't actually be true - the fundamental test for whether or > not SELinux is enabled is the presence or absence of selinuxfs in > /proc/filesystems (i.e. is it registered in the kernel), not whether > or not selinuxfs is actually mounted anywhere. The libselinux logic > should fall back to that /proc/filesystems test. > > And looking at the libselinux code, it does appear to handle ENOENT on > /selinux/context by skipping the normal context validation, so not > having it present at all in /selinux within the chroot should help > _unless_ rpm calls matchpathcon() will outside of the chroot (that's > what I'm unclear on - when rpm is operating within the chroot and when > it is operating outside the chroot). > > The only problem I see with not having selinuxfs mounted at all within > the chroot or even providing fake /selinux nodes is that rpm_execcon() > will then see SELinux as disabled and thus not try to run the > scriptlet in a different domain; Ah, sorry - I misspoke above. Since is_selinux_enabled() ultimately comes down to presence/absence of selinuxfs in /proc/filesystems, rpm_execcon() will see SELinux as enabled but the security_compute_create() call will fail and this will cause it to abort rather than execve(). That's the problem Eric presently has. So possibly changing rpm_execcon() to fall back to setting the default domain to rpm_script_t and proceeding if security_compute_create() fails would allow him to proceed. That would still leave us in rpm_script_t rather than ldconfig_t, so we'd have a labeling problem, but that's likely fixable via a selective restorecon after the fact. > it should just fall back to a normal > execve() in that situation. Which could be addressed in policy > largely by collapsing rpm_script_t and rpm_t into a single domain. > I'm not sure how much we are using the distinction at present - I > think they are both effectively unconfined so it would only differ > possibly in outbound type transitions. > > Anyway, I'd be interested in having Eric try the install with no > selinuxfs mounted or fake selinux nodes within the chroot and see what > happens, both in permissive mode and enforcing mode. > From eparis at redhat.com Mon May 12 21:26:24 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 12 May 2008 17:26:24 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> References: <1208379430.5019.286.camel@calliope.phig.org> <20080417032347.GA7021@nostromo.devel.redhat.com> <1208437979.18883.358.camel@moss-spartans.epoch.ncsc.mil> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> Message-ID: <1210627584.3228.54.camel@localhost.localdomain> On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote: > On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz wrote: > The only problem I see with not having selinuxfs mounted at all within > the chroot or even providing fake /selinux nodes is that rpm_execcon() > will then see SELinux as disabled and thus not try to run the > scriptlet in a different domain; How does it do this check? Guess I should pull some rpm sources. My lord I don't wanna.... > Anyway, I'd be interested in having Eric try the install with no > selinuxfs mounted or fake selinux nodes within the chroot and see what > happens, both in permissive mode and enforcing mode. I've got my fake selinux mount inside the chroot much like I previously described. /selinux/create is still getting long strings in it that don't make much sense. I guess something is using it directly and not through the libselinux interface?!?! enforcing=1 /selinux inside the chroot is the little thing that I made up to fake it. Installing: selinux-policy ##################### [128/129] Installing: selinux-policy-targeted ##################### [129/129] libsemanage.dbase_llist_query: could not query record value libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user guest_u libsepol.sepol_user_modify: could not load (null) into policy libsemanage.dbase_policydb_modify: could not modify record value libsemanage.semanage_base_merge_components: could not merge local modifications into policy /usr/sbin/semanage: Could not add SELinux user guest_u libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user xguest_u libsepol.sepol_user_modify: could not load (null) into policy libsemanage.dbase_policydb_modify: could not modify record value libsemanage.semanage_base_merge_components: could not merge local modifications into policy /usr/sbin/semanage: Could not add SELinux user xguest_u ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. /sbin/restorecon reset / context system_u:object_r:file_t:s0->system_u:object_r:root_t:s0 /sbin/restorecon reset /bin context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /bin/rvi context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /bin/touch context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 /sbin/restorecon reset /bin/mountpoint context unconfined_u:object_r:file_t:s0->system_u:object_r:mount_exec_t:s0 /sbin/restorecon reset /bin/arch context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 and restorecon goes on like this, and on, and on, and on, and on other things of note, restorecond goes nuts fixing up /etc/mtab for a while, must be some bad/no transition going on when we call mount? I get no kernel AVC's but I do get: [root at dhcp231-25 ~]# ausearch -m AVC -m USER_AVC ---- time->Mon May 12 17:19:48 2008 type=USER_AVC msg=audit(1210627188.083:329): user pid=1849 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.16 spid=2044 tpid=6840 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' ---- time->Mon May 12 17:20:13 2008 type=USER_AVC msg=audit(1210627213.086:330): user pid=1849 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.16 spid=2044 tpid=6840 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' I've never seen unconfined_notrans_t until I started playing with this stuff. Dan, what is it? /me goes to try to build a livecd image with permissive and then with no /selinux inside the chroot. -Eric From stephen.smalley at gmail.com Tue May 13 12:44:25 2008 From: stephen.smalley at gmail.com (Stephen Smalley) Date: Tue, 13 May 2008 08:44:25 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210627584.3228.54.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> Message-ID: <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> On Mon, May 12, 2008 at 5:26 PM, Eric Paris wrote: > On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote: > > On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz wrote: > > > > The only problem I see with not having selinuxfs mounted at all within > > the chroot or even providing fake /selinux nodes is that rpm_execcon() > > will then see SELinux as disabled and thus not try to run the > > scriptlet in a different domain; > > How does it do this check? Guess I should pull some rpm sources. My > lord I don't wanna.... You don't have to look at rpm for that - rpm_execcon() is a helper function provided by libselinux for use by rpm. I sent you a patch separately for it that should get it past a missing /selinux/create node, so you should be able to completely remove /selinux/context and /selinux/create and still proceed (at least in permissive mode). > > Anyway, I'd be interested in having Eric try the install with no > > selinuxfs mounted or fake selinux nodes within the chroot and see what > > happens, both in permissive mode and enforcing mode. > > I've got my fake selinux mount inside the chroot much like I previously > described. /selinux/create is still getting long strings in it that > don't make much sense. I guess something is using it directly and not > through the libselinux interface?!?! No, it is just that /selinux/create is a transactional interface that takes multiple input arguments and returns a single output argument, so using a regular file for it won't work at all. Just remove it and use the patch I supplied for rpm_execcon. > > enforcing=1 /selinux inside the chroot is the little thing that I made > up to fake it. I'm not sure you need anything there; as I've said, is_selinux_enabled() will just fall back to checking /proc/filesystems for selinuxfs as the authoritative indicator of whether or not SELinux is enabled. > > Installing: selinux-policy ##################### [128/129] > Installing: selinux-policy-targeted ##################### [129/129] > libsemanage.dbase_llist_query: could not query record value > libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user guest_u Hmm...so you are installing a policy with MLS enabled, but tried to add a user without a MLS level. I think this is likely a bug/limitation of semanage, where it tries to deduce whether or not to include the MLS field based on whether the host has MLS enabled. This has come up before on selinux list; we need a libsemanage interface for querying whether MLS is enabled in the policy store vs. on the host. Or you could fake a /selinux/mls node that contains "1". > libsepol.sepol_user_modify: could not load (null) into policy > libsemanage.dbase_policydb_modify: could not modify record value > libsemanage.semanage_base_merge_components: could not merge local modifications into policy > /usr/sbin/semanage: Could not add SELinux user guest_u > libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user xguest_u > libsepol.sepol_user_modify: could not load (null) into policy > libsemanage.dbase_policydb_modify: could not modify record value > libsemanage.semanage_base_merge_components: could not merge local modifications into policy > /usr/sbin/semanage: Could not add SELinux user xguest_u > > ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. > /sbin/restorecon reset / context system_u:object_r:file_t:s0->system_u:object_r:root_t:s0 > /sbin/restorecon reset /bin context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 > /sbin/restorecon reset /bin/rvi context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 > /sbin/restorecon reset /bin/touch context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 > /sbin/restorecon reset /bin/mountpoint context unconfined_u:object_r:file_t:s0->system_u:object_r:mount_exec_t:s0 > /sbin/restorecon reset /bin/arch context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 > > and restorecon goes on like this, and on, and on, and on, and on So no files were labeled properly by rpm? I guess we need someone to explain how rpm decides whether or not to label files then, as I thought it just used is_selinux_enabled() and that should return true as long as /proc/filesystems is available even if selinuxfs is not mounted within the chroot. > > other things of note, restorecond goes nuts fixing up /etc/mtab for a > while, must be some bad/no transition going on when we call mount? Yes, that would make sense. Not sure what you mean by "goes nuts" though or why restorecond would be running or looking within the chroot. > I get no kernel AVC's but I do get: > > [root at dhcp231-25 ~]# ausearch -m AVC -m USER_AVC > ---- > time->Mon May 12 17:19:48 2008 > type=USER_AVC msg=audit(1210627188.083:329): user pid=1849 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.16 spid=2044 tpid=6840 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > ---- > time->Mon May 12 17:20:13 2008 > type=USER_AVC msg=audit(1210627213.086:330): user pid=1849 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.16 spid=2044 tpid=6840 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > > I've never seen unconfined_notrans_t until I started playing with this > stuff. Dan, what is it? > > /me goes to try to build a livecd image with permissive and then with > no /selinux inside the chroot. > > -Eric > > From dwalsh at redhat.com Tue May 13 12:59:59 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 13 May 2008 08:59:59 -0400 Subject: firefox problems with: browser_confine_unconfined --> on In-Reply-To: <48289A3A.6060501@gmail.com> References: <48289A3A.6060501@gmail.com> Message-ID: <482990CF.6000702@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph A. wrote: > Hi, > > I'm looking forward do confine users (firefox, thunderbird). I played > with xguest_u and I liked the behavior of firefox (home not writeable > except ~/Downloads, ~/.mozilla), but I need other programms > (thunderbird, ssh) to connect to the internet too, so I wanted to try > the usual unconfined_u with browser_confine_unconfined set. > > I didn't find mutch about this boolean but I wanted to see, if with this > boolean set, firefox of an unconfined user will behave like firefox of > xguest_u. > > After setting the boolean firefox runs in its own domain > (unconfined_mozilla_t) that looks fine. > > When I tried to save a picture to see if I can write to ~/ (not > ~/Download) firefox hangs (immediately after klicking on "Save Image > As...") and I had to use kill to terminate it. > > observing the audit.log file with tail -f shows: > > type=USER_AVC msg=audit(1210554417.821:80): user pid=1648 uid=81 > auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 > msg='avc: denied { send_msg } for msgtype=method_return dest=:1.93 > spid=1783 tpid=3412 scontext=system_u:system_r:hald_t:s0 > tcontext=unconfined_u:unconfined_r:unconfined_mozilla_t:s0 tclass=dbus : > exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > > If I set browser_confine_unconfined to 0 this problem doesn't occur. > > Should firefox (unconfined_mozilla_t) behave like firefox of xguest_u, > or is this boolean for something different? > > thanks, > Christoph A. > PS: I'm using FC9. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list No this seems like something that should be allowed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgpkM8ACgkQrlYvE4MpobOCiACgk4vyQHqGJvie0vjD4ShjKxxH BbUAoK+az0eEtgbIHgda/kQ+U+uNEkxx =w1OT -----END PGP SIGNATURE----- From eparis at redhat.com Tue May 13 13:03:51 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 13 May 2008 09:03:51 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> Message-ID: <1210683832.3228.63.camel@localhost.localdomain> On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote: > On Mon, May 12, 2008 at 5:26 PM, Eric Paris wrote: > > > > > Installing: selinux-policy ##################### [128/129] > > Installing: selinux-policy-targeted ##################### [129/129] > > libsemanage.dbase_llist_query: could not query record value > > libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user guest_u > > Hmm...so you are installing a policy with MLS enabled, but tried to > add a user without a MLS level. I think this is likely a > bug/limitation of semanage, where it tries to deduce whether or not to > include the MLS field based on whether the host has MLS enabled. > This has come up before on selinux list; we need a libsemanage > interface for querying whether MLS is enabled in the policy store vs. > on the host. Or you could fake a /selinux/mls node that contains "1". I have one that has a 1\n inside the chroot, but I guess that wasn't enough? Yes, I think its a fine idea to create such a store vs. host check, but in either case they both 'should' have returned MLS=on.... > > > libsepol.sepol_user_modify: could not load (null) into policy > > libsemanage.dbase_policydb_modify: could not modify record value > > libsemanage.semanage_base_merge_components: could not merge local modifications into policy > > /usr/sbin/semanage: Could not add SELinux user guest_u > > libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user xguest_u > > libsepol.sepol_user_modify: could not load (null) into policy > > libsemanage.dbase_policydb_modify: could not modify record value > > libsemanage.semanage_base_merge_components: could not merge local modifications into policy > > /usr/sbin/semanage: Could not add SELinux user xguest_u > > > > ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. > > /sbin/restorecon reset / context system_u:object_r:file_t:s0->system_u:object_r:root_t:s0 > > /sbin/restorecon reset /bin context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 > > /sbin/restorecon reset /bin/rvi context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 > > /sbin/restorecon reset /bin/touch context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 > > /sbin/restorecon reset /bin/mountpoint context unconfined_u:object_r:file_t:s0->system_u:object_r:mount_exec_t:s0 > > /sbin/restorecon reset /bin/arch context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 > > > > and restorecon goes on like this, and on, and on, and on, and on > > So no files were labeled properly by rpm? I guess we need someone to > explain how rpm decides whether or not to label files then, as I > thought it just used is_selinux_enabled() and that should return true > as long as /proc/filesystems is available even if selinuxfs is not > mounted within the chroot. I'll get to no /selinux in a second > > other things of note, restorecond goes nuts fixing up /etc/mtab for a > > while, must be some bad/no transition going on when we call mount? > > Yes, that would make sense. Not sure what you mean by "goes nuts" > though or why restorecond would be running or looking within the > chroot. I doubt we do any mounting inside the chroot do we? Missing transition from livecd-creator program ->mount_t when it does its bind mounts inside the chroot would cause this... > > > I get no kernel AVC's but I do get: > > > > [root at dhcp231-25 ~]# ausearch -m AVC -m USER_AVC > > ---- > > time->Mon May 12 17:19:48 2008 > > type=USER_AVC msg=audit(1210627188.083:329): user pid=1849 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.16 spid=2044 tpid=6840 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > > ---- > > time->Mon May 12 17:20:13 2008 > > type=USER_AVC msg=audit(1210627213.086:330): user pid=1849 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.16 spid=2044 tpid=6840 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > > > > I've never seen unconfined_notrans_t until I started playing with this > > stuff. Dan, what is it? > > > > /me goes to try to build a livecd image with permissive and then with > > no /selinux inside the chroot. > > > > -Eric > > > > From dwalsh at redhat.com Tue May 13 13:10:28 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 13 May 2008 09:10:28 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210683832.3228.63.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> <1210683832.3228.63.camel@localhost.localdomain> Message-ID: <48299344.9040507@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Paris wrote: > On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote: >> On Mon, May 12, 2008 at 5:26 PM, Eric Paris wrote: > >>> Installing: selinux-policy ##################### [128/129] >>> Installing: selinux-policy-targeted ##################### [129/129] >>> libsemanage.dbase_llist_query: could not query record value >>> libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user guest_u >> Hmm...so you are installing a policy with MLS enabled, but tried to >> add a user without a MLS level. I think this is likely a >> bug/limitation of semanage, where it tries to deduce whether or not to >> include the MLS field based on whether the host has MLS enabled. >> This has come up before on selinux list; we need a libsemanage >> interface for querying whether MLS is enabled in the policy store vs. >> on the host. Or you could fake a /selinux/mls node that contains "1". > > I have one that has a 1\n inside the chroot, but I guess that wasn't > enough? Yes, I think its a fine idea to create such a store vs. host > check, but in either case they both 'should' have returned MLS=on.... > >>> libsepol.sepol_user_modify: could not load (null) into policy >>> libsemanage.dbase_policydb_modify: could not modify record value >>> libsemanage.semanage_base_merge_components: could not merge local modifications into policy >>> /usr/sbin/semanage: Could not add SELinux user guest_u >>> libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user xguest_u >>> libsepol.sepol_user_modify: could not load (null) into policy >>> libsemanage.dbase_policydb_modify: could not modify record value >>> libsemanage.semanage_base_merge_components: could not merge local modifications into policy >>> /usr/sbin/semanage: Could not add SELinux user xguest_u >>> >>> ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. >>> /sbin/restorecon reset / context system_u:object_r:file_t:s0->system_u:object_r:root_t:s0 >>> /sbin/restorecon reset /bin context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 >>> /sbin/restorecon reset /bin/rvi context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 >>> /sbin/restorecon reset /bin/touch context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 >>> /sbin/restorecon reset /bin/mountpoint context unconfined_u:object_r:file_t:s0->system_u:object_r:mount_exec_t:s0 >>> /sbin/restorecon reset /bin/arch context unconfined_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 >>> >>> and restorecon goes on like this, and on, and on, and on, and on >> So no files were labeled properly by rpm? I guess we need someone to >> explain how rpm decides whether or not to label files then, as I >> thought it just used is_selinux_enabled() and that should return true >> as long as /proc/filesystems is available even if selinuxfs is not >> mounted within the chroot. > > I'll get to no /selinux in a second > >>> other things of note, restorecond goes nuts fixing up /etc/mtab for a >>> while, must be some bad/no transition going on when we call mount? >> Yes, that would make sense. Not sure what you mean by "goes nuts" >> though or why restorecond would be running or looking within the >> chroot. > > I doubt we do any mounting inside the chroot do we? Missing transition > from livecd-creator program ->mount_t when it does its bind mounts > inside the chroot would cause this... > >>> I get no kernel AVC's but I do get: >>> >>> [root at dhcp231-25 ~]# ausearch -m AVC -m USER_AVC >>> ---- >>> time->Mon May 12 17:19:48 2008 >>> type=USER_AVC msg=audit(1210627188.083:329): user pid=1849 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.16 spid=2044 tpid=6840 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' >>> ---- >>> time->Mon May 12 17:20:13 2008 >>> type=USER_AVC msg=audit(1210627213.086:330): user pid=1849 uid=81 auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for msgtype=method_return dest=:1.16 spid=2044 tpid=6840 scontext=system_u:system_r:hald_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_notrans_t:s0-s0:c0.c1023 tclass=dbus : exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' >>> >>> I've never seen unconfined_notrans_t until I started playing with this >>> stuff. Dan, what is it? >>> >>> /me goes to try to build a livecd image with permissive and then with >>> no /selinux inside the chroot. >>> >>> -Eric >>> >>> > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list unconfined_notrans_exec_t was an attempt to remove unconfined transitions from apps like livecd creator, but have failed miserably. So I would just change the context to bin_t and use unconfined_t for running the livecd tools. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgpk0QACgkQrlYvE4MpobPk4ACguXKMnC7uUM9jaqont/bxthSI ZlYAnRvebyTJ54f9RdSEkjHUZ/I/cwPE =LiD+ -----END PGP SIGNATURE----- From casmls at gmail.com Tue May 13 13:13:46 2008 From: casmls at gmail.com (Christoph A.) Date: Tue, 13 May 2008 15:13:46 +0200 Subject: firefox problems with: browser_confine_unconfined --> on In-Reply-To: <482990CF.6000702@redhat.com> References: <48289A3A.6060501@gmail.com> <482990CF.6000702@redhat.com> Message-ID: <4829940A.9060901@gmail.com> Daniel J Walsh wrote: >> type=USER_AVC msg=audit(1210554417.821:80): user pid=1648 uid=81 >> auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 >> msg='avc: denied { send_msg } for msgtype=method_return dest=:1.93 >> spid=1783 tpid=3412 scontext=system_u:system_r:hald_t:s0 >> tcontext=unconfined_u:unconfined_r:unconfined_mozilla_t:s0 tclass=dbus : >> exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > No this seems like something that should be allowed. Thank you for your response. So browser_confine_unconfined=1 is the right way to confine firefox (of unconfined_u) like firefox of guest_u? thanks in advance Christoph A. From sds at tycho.nsa.gov Tue May 13 13:15:25 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 May 2008 09:15:25 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210683832.3228.63.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> <1210683832.3228.63.camel@localhost.localdomain> Message-ID: <1210684525.6206.106.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-13 at 09:03 -0400, Eric Paris wrote: > On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote: > > On Mon, May 12, 2008 at 5:26 PM, Eric Paris wrote: > > > > > > > > > Installing: selinux-policy ##################### [128/129] > > > Installing: selinux-policy-targeted ##################### [129/129] > > > libsemanage.dbase_llist_query: could not query record value > > > libsepol.sepol_user_modify: MLS is enabled, but no MLS default level was defined for user guest_u > > > > Hmm...so you are installing a policy with MLS enabled, but tried to > > add a user without a MLS level. I think this is likely a > > bug/limitation of semanage, where it tries to deduce whether or not to > > include the MLS field based on whether the host has MLS enabled. > > This has come up before on selinux list; we need a libsemanage > > interface for querying whether MLS is enabled in the policy store vs. > > on the host. Or you could fake a /selinux/mls node that contains "1". > > I have one that has a 1\n inside the chroot, but I guess that wasn't > enough? Yes, I think its a fine idea to create such a store vs. host > check, but in either case they both 'should' have returned MLS=on.... The newline is the problem for you; libselinux is_selinux_mls_enabled() looks for an exact match against "1" since that is what the kernel has always returned. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue May 13 13:25:45 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 13 May 2008 09:25:45 -0400 Subject: firefox problems with: browser_confine_unconfined --> on In-Reply-To: <4829940A.9060901@gmail.com> References: <48289A3A.6060501@gmail.com> <482990CF.6000702@redhat.com> <4829940A.9060901@gmail.com> Message-ID: <482996D9.2090702@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph A. wrote: > Daniel J Walsh wrote: > >>> type=USER_AVC msg=audit(1210554417.821:80): user pid=1648 uid=81 >>> auid=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 >>> msg='avc: denied { send_msg } for msgtype=method_return dest=:1.93 >>> spid=1783 tpid=3412 scontext=system_u:system_r:hald_t:s0 >>> tcontext=unconfined_u:unconfined_r:unconfined_mozilla_t:s0 tclass=dbus : >>> exe="/bin/dbus-daemon" (sauid=81, hostname=?, addr=?, terminal=?)' > >> No this seems like something that should be allowed. > > Thank you for your response. > > So browser_confine_unconfined=1 is the right way to confine firefox (of > unconfined_u) like firefox of guest_u? > > thanks in advance > Christoph A. Well I don't really believe in confining firefox in this way, because of the transitions available. You can confine nsplugin though http://danwalsh.livejournal.com/15700.html The problem with confining firefox is somewhat covered in this article, but where it really breaks is in helper applications. unconfined_mozilla_t runs ooffice and office ends up in unconfined_mozilla_t but if thunderbird or you launch ooffice directly it runs unconfined_t and things get confused. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgpltkACgkQrlYvE4MpobPp+wCg6z3HbnsifKE6BJtj4p6qURzF RMwAnR3yG22YbgnCLOMTaOs5WGkFUrPd =9QLW -----END PGP SIGNATURE----- From casmls at gmail.com Tue May 13 14:25:02 2008 From: casmls at gmail.com (Christoph A.) Date: Tue, 13 May 2008 16:25:02 +0200 Subject: firefox problems with: browser_confine_unconfined --> on In-Reply-To: <482996D9.2090702@redhat.com> References: <48289A3A.6060501@gmail.com> <482990CF.6000702@redhat.com> <4829940A.9060901@gmail.com> <482996D9.2090702@redhat.com> Message-ID: <4829A4BE.9050906@gmail.com> Daniel J Walsh wrote: > Well I don't really believe in confining firefox in this way, because of > the transitions available. > > > You can confine nsplugin though > > http://danwalsh.livejournal.com/15700.html > > > The problem with confining firefox is somewhat covered in this article, > but where it really breaks is in helper applications. Yes, I'm a reader of your blog (thanks for posting this interessting informations) > unconfined_mozilla_t runs ooffice and office ends up in > unconfined_mozilla_t but if thunderbird or you launch ooffice directly > it runs unconfined_t and things get confused. For me it would be fine to save a file (pdf, odt, ..) to disk (~/Downloads) prior to open it with the apropriate program (pdf-reader, openoffice, ...) in the unconfined_t domain and not starting these programs directly within firefox. I admit that normal enduser would not like this extra step just to get more security. regards, Christoph A. From eparis at redhat.com Tue May 13 14:36:45 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 13 May 2008 10:36:45 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> Message-ID: <1210689405.3228.73.camel@localhost.localdomain> On Tue, 2008-05-13 at 08:44 -0400, Stephen Smalley wrote: > On Mon, May 12, 2008 at 5:26 PM, Eric Paris wrote: > > On Mon, 2008-05-12 at 17:05 -0400, Stephen Smalley wrote: > > > On Mon, May 12, 2008 at 4:33 PM, Jeremy Katz wrote: > > > > > > > The only problem I see with not having selinuxfs mounted at all within > > > the chroot or even providing fake /selinux nodes is that rpm_execcon() > > > will then see SELinux as disabled and thus not try to run the > > > scriptlet in a different domain; > > > > How does it do this check? Guess I should pull some rpm sources. My > > lord I don't wanna.... > > You don't have to look at rpm for that - rpm_execcon() is a helper > function provided by libselinux for use by rpm. I sent you a patch > separately for it that should get it past a missing /selinux/create > node, so you should be able to completely remove /selinux/context and > /selinux/create and still proceed (at least in permissive mode). Will do..... > I'm not sure you need anything there; as I've said, > is_selinux_enabled() will just fall back to checking /proc/filesystems > for selinuxfs as the authoritative indicator of whether or not SELinux > is enabled. But we have other problems without /selinux mounted inside the chroot (and this is without the rpm_execcon patch which I'm about to put in, does rpm statically or dynamically link?) :( New, Interesting and different at least: Installing: selinux-policy ##################### [128/129] Installing: selinux-policy-targeted ##################### [129/129] libsemanage.dbase_llist_query: could not query record value libsepol.policydb_write: policy version 15 cannot support MLS I assume this is because there isn't an selinux/policyvers? libsepol.policydb_to_image: could not compute policy length libsepol.policydb_to_image: could not create policy image SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.23, searching for an older version. SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.23: No such file or directory /usr/sbin/load_policy: Can't load policy: No such file or directory libsemanage.semanage_reload_policy: load_policy returned error code 2. libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.23. (No such file or directory). semodule: Failed! /usr/sbin/semanage: Invalid prefix user /usr/sbin/semanage: Invalid prefix user ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. /sbin/restorecon reset /dev/stderr context unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0 /sbin/restorecon reset /dev/stdin context unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0 /sbin/restorecon reset /dev/random context unconfined_u:object_r:file_t:s0->system_u:object_r:random_device_t:s0 There were actually a whole lot less when the restorecon ran through (still a bunch but a lot less), so I think that part is better. After the restorecon finished and before the e2fsck I got: Only root can do that. Anyone have ideas what that might have been? From dant at cdkkt.com Tue May 13 14:38:26 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 13 May 2008 07:38:26 -0700 Subject: Samba shares... Message-ID: <021126B987E43D44A860139823C079110E2D65@mail.cdkkt.com> I am not sure what is going on. I am unable to get samba shares to work for an NTFS filesystem. I do have several shares working for ext3 filesystems. Here is what I did: 1) Create an empty directory: /AV 2) chcon -t samba_share_t /AV 3) chmod 775 !$ 4) chgrp avusers !$ 5) Add to fstab /dev/sda1 /AV ntfs defaults 1 2 6) mount -a + ls -ldZ /AV drwxrwxrwx root root system_u:object_r:fusefs_t:s0 AV + chcon -t samba_share_t /AV chcon: failed to change context of /AV to system_u:object_r:samba_share_t:s0: Operation not supported. + umount /AV (no errors) + chcon -t samba_share_t /AV (no errors) + mount /AV (no errors) + ls -ldZ /AV drwxrwxrwx root root system_u:object_r:fusefs_t:s0 AV So... why does the system insists of fusefs_t? Does this mean that ntfs filesystems does not support samba_share_context? HELP!!! Thanks! Dan From sds at tycho.nsa.gov Tue May 13 14:46:42 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 May 2008 10:46:42 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210689405.3228.73.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> <1210689405.3228.73.camel@localhost.localdomain> Message-ID: <1210690002.6206.154.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-13 at 10:36 -0400, Eric Paris wrote: > > I'm not sure you need anything there; as I've said, > > is_selinux_enabled() will just fall back to checking /proc/filesystems > > for selinuxfs as the authoritative indicator of whether or not SELinux > > is enabled. > > But we have other problems without /selinux mounted inside the chroot > (and this is without the rpm_execcon patch which I'm about to put in, > does rpm statically or dynamically link?) :( Looks like rpm and rpmi are dynamically linked. Don't know if there is a static version somewhere for bootstrapping. > New, Interesting and different at least: > > Installing: selinux-policy ##################### [128/129] > Installing: selinux-policy-targeted ##################### [129/129] > libsemanage.dbase_llist_query: could not query record value > libsepol.policydb_write: policy version 15 cannot support MLS > > I assume this is because there isn't an selinux/policyvers? Yes, but all of this flows from the fact that semodule/libsemanage are trying to actually load a new policy. Which they wouldn't if we completely faked that SELinux was disabled within the chroot by making a fake /proc/filesystems. But allegedly that breaks rpm? Which I don't fully understand as it should just check whether SELinux is enabled prior to chroot'ing and keep using that saved enabled status throughout IMHO. Or if you invoked semodule with -n it wouldn't try to reload. If all else fails, I suppose you could create a /selinux/policyvers and /selinux/mls to try to appease it. And maybe still a /dev/null link as /selinux/load to appease policy load. > libsepol.policydb_to_image: could not compute policy length > libsepol.policydb_to_image: could not create policy image > SELinux: Could not downgrade policy file /etc/selinux/targeted/policy/policy.23, searching for an older version. > SELinux: Could not open policy file <= /etc/selinux/targeted/policy/policy.23: No such file or directory > /usr/sbin/load_policy: Can't load policy: No such file or directory Yes, trying to load policy is the root problem here. So ideally we'd just disable that altogether as above or failing that fake it as above. > ERROR:dbus.proxies:Introspect error on :1.3:/org/freedesktop/Hal/Manager: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. That might just be a bug in the host policy, not allowing something that ought to be allowed and that only happens to get triggered here. > /sbin/restorecon reset /dev/stderr context unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0 > /sbin/restorecon reset /dev/stdin context unconfined_u:object_r:file_t:s0->system_u:object_r:device_t:s0 > /sbin/restorecon reset /dev/random context unconfined_u:object_r:file_t:s0->system_u:object_r:random_device_t:s0 That may make sense given that udev manages device node labels for us these days. But /dev/stderr is just a symlink to /proc/self/fd/2 anyway, right? > There were actually a whole lot less when the restorecon ran through > (still a bunch but a lot less), so I think that part is better. > > After the restorecon finished and before the e2fsck I got: > > Only root can do that. > > Anyone have ideas what that might have been? mount would do that if it didn't think it was running as root. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue May 13 14:52:21 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 May 2008 10:52:21 -0400 Subject: Samba shares... In-Reply-To: <021126B987E43D44A860139823C079110E2D65@mail.cdkkt.com> References: <021126B987E43D44A860139823C079110E2D65@mail.cdkkt.com> Message-ID: <1210690341.6206.158.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-13 at 07:38 -0700, Daniel B. Thurman wrote: > I am not sure what is going on. I am unable to get > samba shares to work for an NTFS filesystem. I do > have several shares working for ext3 filesystems. > > Here is what I did: > > 1) Create an empty directory: /AV > 2) chcon -t samba_share_t /AV > 3) chmod 775 !$ > 4) chgrp avusers !$ > 5) Add to fstab > /dev/sda1 /AV ntfs defaults 1 2 Not sure if this will work, but try adding a "context=system_u:object_r:samba_share_t" to the list of options in your fstab. > 6) mount -a > > + ls -ldZ /AV > drwxrwxrwx root root system_u:object_r:fusefs_t:s0 AV > > + chcon -t samba_share_t /AV > chcon: failed to change context of /AV to system_u:object_r:samba_share_t:s0: Operation not supported. > > + umount /AV (no errors) > + chcon -t samba_share_t /AV (no errors) > + mount /AV (no errors) > + ls -ldZ /AV > drwxrwxrwx root root system_u:object_r:fusefs_t:s0 AV > > So... why does the system insists of fusefs_t? > Does this mean that ntfs filesystems does not support samba_share_context? > > HELP!!! > > Thanks! > Dan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Stephen Smalley National Security Agency From dant at cdkkt.com Tue May 13 15:12:36 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 13 May 2008 08:12:36 -0700 Subject: Samba shares... Message-ID: <021126B987E43D44A860139823C0791103FD6F@mail.cdkkt.com> Stephen Smalley wrote: >> Daniel B. Thurman wrote: >> I am not sure what is going on. I am unable to get >> samba shares to work for an NTFS filesystem. I do >> have several shares working for ext3 filesystems. >> >> Here is what I did: >> >> 1) Create an empty directory: /AV >> 2) chcon -t samba_share_t /AV >> 3) chmod 775 !$ >> 4) chgrp avusers !$ >> 5) Add to fstab >> /dev/sda1 /AV ntfs defaults 1 2 > > Not sure if this will work, but try adding a > "context=system_u:object_r:samba_share_t" to the > list of options in your fstab. Sorry I was not able to get your reply in my inbox, it was spam-blocked, but I have it fixed now. Can you please tell me how to add your suggestion to the fstab as options? Thanks! Dan From sds at tycho.nsa.gov Tue May 13 15:23:35 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 May 2008 11:23:35 -0400 Subject: Samba shares... In-Reply-To: <021126B987E43D44A860139823C0791103FD6F@mail.cdkkt.com> References: <021126B987E43D44A860139823C0791103FD6F@mail.cdkkt.com> Message-ID: <1210692215.6206.165.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-13 at 08:12 -0700, Daniel B. Thurman wrote: > Stephen Smalley wrote: > >> Daniel B. Thurman wrote: > >> I am not sure what is going on. I am unable to get > >> samba shares to work for an NTFS filesystem. I do > >> have several shares working for ext3 filesystems. > >> > >> Here is what I did: > >> > >> 1) Create an empty directory: /AV > >> 2) chcon -t samba_share_t /AV > >> 3) chmod 775 !$ > >> 4) chgrp avusers !$ > >> 5) Add to fstab > >> /dev/sda1 /AV ntfs defaults 1 2 > > > > Not sure if this will work, but try adding a > > "context=system_u:object_r:samba_share_t" to the > > list of options in your fstab. > > Sorry I was not able to get your reply in my inbox, it was > spam-blocked, but I have it fixed now. > > Can you please tell me how to add your suggestion to > the fstab as options? It is just another mount option, so you can just do something like: /dev/sda1 /AV ntfs defaults,context=system_u:object_r:samba_share_t 1 2 -- Stephen Smalley National Security Agency From dant at cdkkt.com Tue May 13 15:40:17 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 13 May 2008 08:40:17 -0700 Subject: Samba shares... Message-ID: <021126B987E43D44A860139823C079110E2D67@mail.cdkkt.com> Stephen Smalley |On Tue, 2008-05-13 at 08:12 -0700, Daniel B. Thurman wrote: |> Stephen Smalley wrote: |> >> Daniel B. Thurman wrote: |> >> I am not sure what is going on. I am unable to get |> >> samba shares to work for an NTFS filesystem. I do |> >> have several shares working for ext3 filesystems. |> >> |> >> Here is what I did: |> >> |> >> 1) Create an empty directory: /AV |> >> 2) chcon -t samba_share_t /AV |> >> 3) chmod 775 !$ |> >> 4) chgrp avusers !$ |> >> 5) Add to fstab |> >> /dev/sda1 /AV ntfs defaults 1 2 [snipped!] | |It is just another mount option, so you can just do something like: |/dev/sda1 /AV ntfs defaults,context=system_u:object_r:samba_share_t 1 2 Yes, I thought so. I tried that and the context does not change. Any ideas? Thanks! Dan From eparis at redhat.com Tue May 13 16:06:08 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 13 May 2008 12:06:08 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210690002.6206.154.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> <1210689405.3228.73.camel@localhost.localdomain> <1210690002.6206.154.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210694768.3228.93.camel@localhost.localdomain> Current Setup: F9 trying to build an F9 livecd so policy should be happy. I'm trying to eliminate the illegal file context cruft to start with. Enforcing. the label on livecd-creator is bin_t NOT unconfined_notran_t chroot/selinux contains: null -> /dev/null load -> /dev/null mls -> 1 enforcing -> 1 policyvers -> 22 context -> regular file libselinux always opens files with O_TRUNC libselinux rpm_execcon has the patch to return -1 and set con = context_new(mycon); the new libselinux is being used inside and outside the chroot rpm was NOT rebuilt with the new libselinux, rpm.src.rpm only requires libeselinux-devel not libselinux-static so I'm hoping we are safe. ****************************** ^M Installing: kbd ##################### [126/129] ^M Installing: kernel ##################### [127/129] ^M Installing: selinux-policy ##################### [128/129] ^M Installing: selinux-policy-targeted ##################### [129/129] All of this still went smoothly... libsemanage.dbase_llist_query: could not query record value No idea where this is coming from /sbin/restorecon reset / context system_u:object_r:file_t:s0->system_u:object_r:root_t:s0 /sbin/restorecon reset /lib context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 /sbin/restorecon reset /lib/kbd context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 /sbin/restorecon reset /lib/kbd/consoletrans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 /sbin/restorecon reset /lib/kbd/consoletrans/cp1250_to_uni.trans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 /sbin/restorecon reset /lib/kbd/consoletrans/cp1251_to_uni.trans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 /sbin/restorecon reset /lib/kbd/consoletrans/8859-4_to_uni.trans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 We are back to calling restorecon on every single file..... -Eric From sds at tycho.nsa.gov Tue May 13 16:53:47 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 May 2008 12:53:47 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210694768.3228.93.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> <1210689405.3228.73.camel@localhost.localdomain> <1210690002.6206.154.camel@moss-spartans.epoch.ncsc.mil> <1210694768.3228.93.camel@localhost.localdomain> Message-ID: <1210697627.6206.179.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-13 at 12:06 -0400, Eric Paris wrote: > Current Setup: > > F9 trying to build an F9 livecd so policy should be happy. I'm trying > to eliminate the illegal file context cruft to start with. > > Enforcing. > > the label on livecd-creator is bin_t NOT unconfined_notran_t > > chroot/selinux contains: > null -> /dev/null > load -> /dev/null > mls -> 1 > enforcing -> 1 > policyvers -> 22 > context -> regular file Just as a reminder, I don't believe you should have context there at all, as omitting it should just work (tm). > libselinux always opens files with O_TRUNC And thus you wouldn't need this hack. > libselinux rpm_execcon has the patch to return -1 and set con = > context_new(mycon); Just to clarify, the patch should actually enable rpm_execcon() to proceed with rpm_script_t even if /selinux/create does not exist. > the new libselinux is being used inside and outside the chroot > > rpm was NOT rebuilt with the new libselinux, rpm.src.rpm only requires > libeselinux-devel not libselinux-static so I'm hoping we are safe. > > ****************************** > > ^M Installing: kbd ##################### [126/129] > ^M Installing: kernel ##################### [127/129] > ^M Installing: selinux-policy ##################### [128/129] > ^M Installing: selinux-policy-targeted ##################### [129/129] > > All of this still went smoothly... > > libsemanage.dbase_llist_query: could not query record value > > No idea where this is coming from Maybe a table was empty. Might want to look under etc/selinux/targeted within the chroot. > /sbin/restorecon reset / context system_u:object_r:file_t:s0->system_u:object_r:root_t:s0 > /sbin/restorecon reset /lib context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > /sbin/restorecon reset /lib/kbd context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > /sbin/restorecon reset /lib/kbd/consoletrans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > /sbin/restorecon reset /lib/kbd/consoletrans/cp1250_to_uni.trans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > /sbin/restorecon reset /lib/kbd/consoletrans/cp1251_to_uni.trans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > /sbin/restorecon reset /lib/kbd/consoletrans/8859-4_to_uni.trans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > > We are back to calling restorecon on every single file..... Well, you did put back in a /selinux/context against my advice, and I'm not sure what else you changed in the above. But more fundamentally we really need someone who understands the code flow in rpm to explain when rpm checks for SELinux status and how it switches from using policy outside the chroot to using policy within the chroot for file labeling. An strace of rpm might be interesting although no doubt very hard to follow. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue May 13 16:55:53 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 13 May 2008 12:55:53 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210694768.3228.93.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> <1210689405.3228.73.camel@localhost.localdomain> <1210690002.6206.154.camel@moss-spartans.epoch.ncsc.mil> <1210694768.3228.93.camel@localhost.localdomain> Message-ID: <4829C819.4010901@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Paris wrote: > Current Setup: > > F9 trying to build an F9 livecd so policy should be happy. I'm trying > to eliminate the illegal file context cruft to start with. > > Enforcing. > > the label on livecd-creator is bin_t NOT unconfined_notran_t > > chroot/selinux contains: > null -> /dev/null > load -> /dev/null > mls -> 1 > enforcing -> 1 > policyvers -> 22 > context -> regular file > > libselinux always opens files with O_TRUNC > > libselinux rpm_execcon has the patch to return -1 and set con = > context_new(mycon); > > the new libselinux is being used inside and outside the chroot > > rpm was NOT rebuilt with the new libselinux, rpm.src.rpm only requires > libeselinux-devel not libselinux-static so I'm hoping we are safe. > > ****************************** > > ^M Installing: kbd ##################### [126/129] > ^M Installing: kernel ##################### [127/129] > ^M Installing: selinux-policy ##################### [128/129] > ^M Installing: selinux-policy-targeted ##################### [129/129] > > All of this still went smoothly... > > libsemanage.dbase_llist_query: could not query record value > > No idea where this is coming from > > /sbin/restorecon reset / context system_u:object_r:file_t:s0->system_u:object_r:root_t:s0 > /sbin/restorecon reset /lib context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > /sbin/restorecon reset /lib/kbd context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > /sbin/restorecon reset /lib/kbd/consoletrans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > /sbin/restorecon reset /lib/kbd/consoletrans/cp1250_to_uni.trans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > /sbin/restorecon reset /lib/kbd/consoletrans/cp1251_to_uni.trans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > /sbin/restorecon reset /lib/kbd/consoletrans/8859-4_to_uni.trans context unconfined_u:object_r:file_t:s0->system_u:object_r:lib_t:s0 > > We are back to calling restorecon on every single file..... > > -Eric > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I don't have a problem with calling restorecon on every single file, since this is a limited number of files. The goal is to allow the chroot to run without mucking around with the host security. So I don't have to run permissive or disabled if I use mock/livecd. If mock/livecd have to relabel when they complete that is fine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgpyBkACgkQrlYvE4MpobNUlACbBN5WJvv0IUH6Voq3L2GgLIej MXYAn3ja4+e8pZpHQTXbctm5fYIe9UOj =a9ex -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Tue May 13 17:27:01 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 May 2008 13:27:01 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210697627.6206.179.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> <1210689405.3228.73.camel@localhost.localdomain> <1210690002.6206.154.camel@moss-spartans.epoch.ncsc.mil> <1210694768.3228.93.camel@localhost.localdomain> <1210697627.6206.179.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210699621.6206.200.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-13 at 12:53 -0400, Stephen Smalley wrote: > On Tue, 2008-05-13 at 12:06 -0400, Eric Paris wrote: > > Current Setup: > > > > F9 trying to build an F9 livecd so policy should be happy. I'm trying > > to eliminate the illegal file context cruft to start with. > > > > Enforcing. > > > > the label on livecd-creator is bin_t NOT unconfined_notran_t > > > > chroot/selinux contains: > > null -> /dev/null > > load -> /dev/null > > mls -> 1 > > enforcing -> 1 > > policyvers -> 22 > > context -> regular file > > Just as a reminder, I don't believe you should have context there at > all, as omitting it should just work (tm). You also shouldn't need "null" in /selinux; that's a node within selinuxfs for use by the kernel when closing unauthorized files upon execve and replacing them with references to the null device. It doesn't get used by SELinux userspace. There is no "enforcing" file; it is "enforce" and I don't think you need it within the chroot for anything. It isn't the indicator of whether SELinux is enabled. So that leaves you with just "load" (so that policy reload appears to succeed), "mls" (so that semanage knows whether to include MLS fields), and "policyvers" (again for policy reload purposes). And neither "load" nor "policyvers" should be necessary if we could just disable policy reload altogether (which is possible but not sure how to make it happen transparently under only these conditions), and "mls" wouldn't be necessary if we introduced proper support into libsemanage for querying the MLS status of the policy and change semanage/seobject.py to use that instead. -- Stephen Smalley National Security Agency From dant at cdkkt.com Tue May 13 17:27:58 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 13 May 2008 10:27:58 -0700 Subject: Samba shares... Message-ID: <021126B987E43D44A860139823C0791103FD71@mail.cdkkt.com> Daniel B. Thurman wrote: |Stephen Smalley ||On Tue, 2008-05-13 at 08:12 -0700, Daniel B. Thurman wrote: ||> Stephen Smalley wrote: ||> >> Daniel B. Thurman wrote: ||> >> I am not sure what is going on. I am unable to get ||> >> samba shares to work for an NTFS filesystem. I do ||> >> have several shares working for ext3 filesystems. ||> >> ||> >> Here is what I did: ||> >> ||> >> 1) Create an empty directory: /AV ||> >> 2) chcon -t samba_share_t /AV ||> >> 3) chmod 775 !$ ||> >> 4) chgrp avusers !$ ||> >> 5) Add to fstab ||> >> /dev/sda1 /AV ntfs defaults 1 2 | [snipped!] || ||It is just another mount option, so you can just do something like: ||/dev/sda1 /AV ntfs |defaults,context=system_u:object_r:samba_share_t 1 2 | |Yes, I thought so. I tried that and the context does not |change. Any ideas? Mounting an NTFS filesystem even with context options, the context always remains as fusefs_t. I am allowed to change the context on the directory before the mount, but not after the mount. After mounting, I am not allowed to chcon the mounted FS as it says that the Operation is not allowed. I even tried: setsebool -P samba_export_all_rw=1 and that does not work, either. If I setenforce 0, I can share the NTFS filesystem, but I really do not want to do this. Can someone please give me a workaround? Thanks- Dan From dennis at ausil.us Tue May 13 17:29:30 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 13 May 2008 12:29:30 -0500 Subject: Fedora buildsys and SELinux In-Reply-To: <4829C819.4010901@redhat.com> References: <1208379430.5019.286.camel@calliope.phig.org> <1210694768.3228.93.camel@localhost.localdomain> <4829C819.4010901@redhat.com> Message-ID: <200805131229.37017.dennis@ausil.us> On Tuesday 13 May 2008, Daniel J Walsh wrote: > > I don't have a problem with calling restorecon on every single file, > since this is a limited number of files. The goal is to allow the > chroot to run without mucking around with the host security. So I don't > have to run permissive or disabled if I use mock/livecd. If mock/livecd > have to relabel when they complete that is fine. I would really like to enable selinux on the actual builders. Right now it has to be disabled. If not alot of things build ok but certain packages will switch to enforcing inside the chroot when the host is in permissive mode. and it causes all sorts of fun and failed builds. for the builders i think that calling restorecon will slow down builds too much. A new chroot is created for each and every build. This is a seperate issue from having machines for doing composes. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From sds at tycho.nsa.gov Tue May 13 17:37:42 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 May 2008 13:37:42 -0400 Subject: Samba shares... In-Reply-To: <021126B987E43D44A860139823C0791103FD71@mail.cdkkt.com> References: <021126B987E43D44A860139823C0791103FD71@mail.cdkkt.com> Message-ID: <1210700262.6206.205.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-13 at 10:27 -0700, Daniel B. Thurman wrote: > Daniel B. Thurman wrote: > |Stephen Smalley > ||On Tue, 2008-05-13 at 08:12 -0700, Daniel B. Thurman wrote: > ||> Stephen Smalley wrote: > ||> >> Daniel B. Thurman wrote: > ||> >> I am not sure what is going on. I am unable to get > ||> >> samba shares to work for an NTFS filesystem. I do > ||> >> have several shares working for ext3 filesystems. > ||> >> > ||> >> Here is what I did: > ||> >> > ||> >> 1) Create an empty directory: /AV > ||> >> 2) chcon -t samba_share_t /AV > ||> >> 3) chmod 775 !$ > ||> >> 4) chgrp avusers !$ > ||> >> 5) Add to fstab > ||> >> /dev/sda1 /AV ntfs defaults 1 2 > | [snipped!] > || > ||It is just another mount option, so you can just do something like: > ||/dev/sda1 /AV ntfs > |defaults,context=system_u:object_r:samba_share_t 1 2 > | > |Yes, I thought so. I tried that and the context does not > |change. Any ideas? > > Mounting an NTFS filesystem even with context options, > the context always remains as fusefs_t. I am allowed > to change the context on the directory before the mount, > but not after the mount. After mounting, I am not allowed > to chcon the mounted FS as it says that the Operation is > not allowed. Can you confirm that if you umount /AV and then mount it with the context= option that it really doesn't work for you? You do have to umount it though if you previously mounted it w/o the context option to make the option take affect. I'm not sure why a context mount option wouldn't work for fuse - Eric? fuse itself won't let you chcon (setxattr) the files unless the filesystem supports setxattr, which is why you get Operation not supported there. > I even tried: setsebool -P samba_export_all_rw=1 and that > does not work, either. > > If I setenforce 0, I can share the NTFS filesystem, but I > really do not want to do this. Can someone please give me > a workaround? You can certainly generate a local policy module that gives access to fusefs_t, but it would be better if we could get the context mount option to work. -- Stephen Smalley National Security Agency From herve.werner at ensi-bourges.fr Tue May 13 17:58:03 2008 From: herve.werner at ensi-bourges.fr (=?iso-8859-1?Q?Herv=E9_WERNER?=) Date: Tue, 13 May 2008 19:58:03 +0200 (CEST) Subject: NFSv4 and SELinux Message-ID: <54462.82.246.196.177.1210701483.squirrel@webmail.ensi-bourges.fr> Hi. I've just installed Fedora 9 today in order to test NFSv4 through SELinux. I know that sending context across the wire is still in progress, but could I find some patch to test? Is there anything I could test to make it work? I also would like to make the context mount option work with NFSv4. The mount command doesn't give any error at mounting but when I list the context of the NFSv4 mount point I get "system_u:object_r:nfs_t". Is there any way to set context for the mounted points? Any help would be appreciated. From herve.werner at ensi-bourges.fr Tue May 13 17:59:42 2008 From: herve.werner at ensi-bourges.fr (=?iso-8859-1?Q?Herv=E9_WERNER?=) Date: Tue, 13 May 2008 19:59:42 +0200 (CEST) Subject: NFSv4 and SELinux Message-ID: <54469.82.246.196.177.1210701582.squirrel@webmail.ensi-bourges.fr> Hi. I've just installed Fedora 9 today in order to test NFSv4 through SELinux. I know that sending context across the wire is still in progress, but could I find some patch to test? Is there anything I could test to make it work? I also would like to make the context mount option work with NFSv4. The mount command doesn't give any error at mounting but when I list the context of the NFSv4 mount point I get "system_u:object_r:nfs_t". Is there any way to set context for the mounted points? Any help would be appreciated. From eparis at redhat.com Tue May 13 18:08:02 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 13 May 2008 14:08:02 -0400 Subject: NFSv4 and SELinux In-Reply-To: <54462.82.246.196.177.1210701483.squirrel@webmail.ensi-bourges.fr> References: <54462.82.246.196.177.1210701483.squirrel@webmail.ensi-bourges.fr> Message-ID: <1210702082.3118.3.camel@localhost.localdomain> On Tue, 2008-05-13 at 19:58 +0200, Herv? WERNER wrote: > Hi. > > I've just installed Fedora 9 today in order to test NFSv4 through SELinux. > I know that sending context across the wire is still in progress, but > could I find some patch to test? Is there anything I could test to make it > work? not my area > I also would like to make the context mount option work with NFSv4. The > mount command doesn't give any error at mounting but when I list the > context of the NFSv4 mount point I get "system_u:object_r:nfs_t". Is there > any way to set context for the mounted points? not until the nfs maintainers accept my latest patch, send it to linus, and it gets back into fedora kernels http://marc.info/?l=linux-nfs&m=120844123922204&w=2 we are hung up on the upstream NFS people here (they have been poked) -Eric From eparis at redhat.com Tue May 13 18:08:43 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 13 May 2008 14:08:43 -0400 Subject: Samba shares... In-Reply-To: <1210700262.6206.205.camel@moss-spartans.epoch.ncsc.mil> References: <021126B987E43D44A860139823C0791103FD71@mail.cdkkt.com> <1210700262.6206.205.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210702123.3118.5.camel@localhost.localdomain> On Tue, 2008-05-13 at 13:37 -0400, Stephen Smalley wrote: > On Tue, 2008-05-13 at 10:27 -0700, Daniel B. Thurman wrote: > > Daniel B. Thurman wrote: > > |Stephen Smalley > > ||On Tue, 2008-05-13 at 08:12 -0700, Daniel B. Thurman wrote: > > ||> Stephen Smalley wrote: > > ||> >> Daniel B. Thurman wrote: > > ||> >> I am not sure what is going on. I am unable to get > > ||> >> samba shares to work for an NTFS filesystem. I do > > ||> >> have several shares working for ext3 filesystems. > > ||> >> > > ||> >> Here is what I did: > > ||> >> > > ||> >> 1) Create an empty directory: /AV > > ||> >> 2) chcon -t samba_share_t /AV > > ||> >> 3) chmod 775 !$ > > ||> >> 4) chgrp avusers !$ > > ||> >> 5) Add to fstab > > ||> >> /dev/sda1 /AV ntfs defaults 1 2 > > | [snipped!] > > || > > ||It is just another mount option, so you can just do something like: > > ||/dev/sda1 /AV ntfs > > |defaults,context=system_u:object_r:samba_share_t 1 2 > > | > > |Yes, I thought so. I tried that and the context does not > > |change. Any ideas? > > > > Mounting an NTFS filesystem even with context options, > > the context always remains as fusefs_t. I am allowed > > to change the context on the directory before the mount, > > but not after the mount. After mounting, I am not allowed > > to chcon the mounted FS as it says that the Operation is > > not allowed. > > Can you confirm that if you umount /AV and then mount it with the > context= option that it really doesn't work for you? You do have to > umount it though if you previously mounted it w/o the context option to > make the option take affect. > > I'm not sure why a context mount option wouldn't work for fuse - Eric? No idea, but I haven't looked at what hackers fuse does either..... -Eric From dant at cdkkt.com Tue May 13 18:30:27 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 13 May 2008 11:30:27 -0700 Subject: Samba shares... Message-ID: <021126B987E43D44A860139823C079110E2D6B@mail.cdkkt.com> Stephen Smalley wrote: |On Tue, 2008-05-13 at 10:27 -0700, Daniel B. Thurman wrote: |> Daniel B. Thurman wrote: |> |Stephen Smalley |> ||On Tue, 2008-05-13 at 08:12 -0700, Daniel B. Thurman wrote: |> ||> Stephen Smalley wrote: |> ||> >> Daniel B. Thurman wrote: |> ||> >> I am not sure what is going on. I am unable to get |> ||> >> samba shares to work for an NTFS filesystem. I do |> ||> >> have several shares working for ext3 filesystems. |> ||> >> |> ||> >> Here is what I did: |> ||> >> |> ||> >> 1) Create an empty directory: /AV |> ||> >> 2) chcon -t samba_share_t /AV |> ||> >> 3) chmod 775 !$ |> ||> >> 4) chgrp avusers !$ |> ||> >> 5) Add to fstab |> ||> >> /dev/sda1 /AV ntfs defaults 1 2 |> | [snipped!] |> || |> ||It is just another mount option, so you can just do something like: |> ||/dev/sda1 /AV ntfs |> |defaults,context=system_u:object_r:samba_share_t 1 2 |> | |> |Yes, I thought so. I tried that and the context does not |> |change. Any ideas? |> |> Mounting an NTFS filesystem even with context options, |> the context always remains as fusefs_t. I am allowed |> to change the context on the directory before the mount, |> but not after the mount. After mounting, I am not allowed |> to chcon the mounted FS as it says that the Operation is |> not allowed. | |Can you confirm that if you umount /AV and then mount it with the |context= option that it really doesn't work for you? You do have to |umount it though if you previously mounted it w/o the context option to |make the option take affect. Yes, I can confirm that adding context= to the option line in /etc/fstab does not seem to do anything, i.e. the context does not change and remains fusefs_t. I tried several times, and even tried the fscontext= as well, neither seems to work. I was forced to reboot sometimes since I was not at times able to unmount the /AV filesystem, it sometimes reports that the /AV filesystem was 'busy'. This seems to happen if I mount/unmount several times then it says 'busy', preventing me from unmounting. Hmm. |I'm not sure why a context mount option wouldn't work for fuse - Eric? | |fuse itself won't let you chcon (setxattr) the files unless the |filesystem supports setxattr, which is why you get Operation not |supported there. | |> I even tried: setsebool -P samba_export_all_rw=1 and that |> does not work, either. |> |> If I setenforce 0, I can share the NTFS filesystem, but I |> really do not want to do this. Can someone please give me |> a workaround? | |You can certainly generate a local policy module that gives access to |fusefs_t, but it would be better if we could get the context mount |option to work. I will try anything you suggest. Let me know if you can resolve this issue, otherwise let me know (in detail) how to write a policy as a last resort? Thanks much! Dan From dpquigl at tycho.nsa.gov Tue May 13 18:22:29 2008 From: dpquigl at tycho.nsa.gov (Dave Quigley) Date: Tue, 13 May 2008 14:22:29 -0400 Subject: NFSv4 and SELinux In-Reply-To: <54462.82.246.196.177.1210701483.squirrel@webmail.ensi-bourges.fr> References: <54462.82.246.196.177.1210701483.squirrel@webmail.ensi-bourges.fr> Message-ID: <1210702949.21507.22.camel@moss-terrapins.epoch.ncsc.mil> On Tue, 2008-05-13 at 19:58 +0200, Herv? WERNER wrote: > Hi. > > I've just installed Fedora 9 today in order to test NFSv4 through SELinux. > I know that sending context across the wire is still in progress, but > could I find some patch to test? Is there anything I could test to make it > work? > > I also would like to make the context mount option work with NFSv4. The > mount command doesn't give any error at mounting but when I list the > context of the NFSv4 mount point I get "system_u:object_r:nfs_t". Is there > any way to set context for the mounted points? > > > Any help would be appreciated. > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Hello, Since F9 was released today I haven't had a chance to test our Labeled-NFS patches with it yet. There were some complications with getting it working with the 2.6.25 kernel that is shipped with Fedora and one of my associates on the project with me was working on fixing that. He is currently away on vacation so I have a few pending requests for his patches for when he gets back. When he is back in town I'll get a version of the patches that work with F9 and I'll send it off to you. I had a blurb about the mount options but it seems that Eric beat me to it. Dave From dwalsh at redhat.com Tue May 13 18:46:06 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 13 May 2008 14:46:06 -0400 Subject: Samba shares... In-Reply-To: <021126B987E43D44A860139823C079110E2D6B@mail.cdkkt.com> References: <021126B987E43D44A860139823C079110E2D6B@mail.cdkkt.com> Message-ID: <4829E1EE.9040702@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel B. Thurman wrote: > Stephen Smalley wrote: > |On Tue, 2008-05-13 at 10:27 -0700, Daniel B. Thurman wrote: > |> Daniel B. Thurman wrote: > |> |Stephen Smalley > |> ||On Tue, 2008-05-13 at 08:12 -0700, Daniel B. Thurman wrote: > |> ||> Stephen Smalley wrote: > |> ||> >> Daniel B. Thurman wrote: > |> ||> >> I am not sure what is going on. I am unable to get > |> ||> >> samba shares to work for an NTFS filesystem. I do > |> ||> >> have several shares working for ext3 filesystems. > |> ||> >> > |> ||> >> Here is what I did: > |> ||> >> > |> ||> >> 1) Create an empty directory: /AV > |> ||> >> 2) chcon -t samba_share_t /AV > |> ||> >> 3) chmod 775 !$ > |> ||> >> 4) chgrp avusers !$ > |> ||> >> 5) Add to fstab > |> ||> >> /dev/sda1 /AV ntfs defaults 1 2 > |> | [snipped!] > |> || > |> ||It is just another mount option, so you can just do something like: > |> ||/dev/sda1 /AV ntfs > |> |defaults,context=system_u:object_r:samba_share_t 1 2 > |> | > |> |Yes, I thought so. I tried that and the context does not > |> |change. Any ideas? > |> > |> Mounting an NTFS filesystem even with context options, > |> the context always remains as fusefs_t. I am allowed > |> to change the context on the directory before the mount, > |> but not after the mount. After mounting, I am not allowed > |> to chcon the mounted FS as it says that the Operation is > |> not allowed. > | > |Can you confirm that if you umount /AV and then mount it with the > |context= option that it really doesn't work for you? You do have to > |umount it though if you previously mounted it w/o the context option to > |make the option take affect. > > Yes, I can confirm that adding context= to the option line > in /etc/fstab does not seem to do anything, i.e. the context > does not change and remains fusefs_t. I tried several times, > and even tried the fscontext= as well, neither seems to work. > > I was forced to reboot sometimes since I was not at times > able to unmount the /AV filesystem, it sometimes reports > that the /AV filesystem was 'busy'. This seems to happen > if I mount/unmount several times then it says 'busy', > preventing me from unmounting. Hmm. > > |I'm not sure why a context mount option wouldn't work for fuse - Eric? > | > |fuse itself won't let you chcon (setxattr) the files unless the > |filesystem supports setxattr, which is why you get Operation not > |supported there. > | > |> I even tried: setsebool -P samba_export_all_rw=1 and that > |> does not work, either. > |> > |> If I setenforce 0, I can share the NTFS filesystem, but I > |> really do not want to do this. Can someone please give me > |> a workaround? > | > |You can certainly generate a local policy module that gives access to > |fusefs_t, but it would be better if we could get the context mount > |option to work. > > I will try anything you suggest. Let me know if you can > resolve this issue, otherwise let me know (in detail) how > to write a policy as a last resort? > > Thanks much! > Dan This looks like a bug. If you are using fedora 9 policy it has a boolean samba_share_fusefs -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgp4e4ACgkQrlYvE4MpobN14ACg1mVCa9sxAoDThvTwSMW5v+2C etcAoIVXMYbp+hBFVWzjDjVP2VYh7Iaf =VZTf -----END PGP SIGNATURE----- From selinux at hilbig.name Tue May 13 18:57:07 2008 From: selinux at hilbig.name (D. Hilbig) Date: Tue, 13 May 2008 11:57:07 -0700 Subject: FW: SELinux, apache/php and qmail's sendmail Message-ID: <22B2C789DC6C49C49C18A5C02803275F@LAP21> Can someone please help me with this? -----Original Message----- From: D. Hilbig [mailto:selinux at hilbig.name] Sent: Thursday, May 08, 2008 10:14 AM To: 'fedora-selinux-list at redhat.com' Subject: SELinux, apache/php and qmail's sendmail I use qmail instead of sendmail on RHEL v5 and I could use some advice on setting contexts for qmail's sendmail so that apache/php can use it. Below are the files and directories involved with qmail's sendmail (and delivery to queue) allow apache/php to invoke qmail's sendmail program: /var/qmail/bin/sendmail allow qmail's sendmail to invoke qmail-inject program: /var/qmail/bin/qmail-inject allow qmail-inject to list the contents of the config files directory: /var/qmail/control allow qmail-inject to read the config files it uses: /var/qmail/control/defaultdomain /var/qmail/control/deaulthost /var/qmail/control/idhost /var/qmail/control/plusdomain /var/qmail/control/me allow qmail-inject to invoke qmail-queue program: /var/qmail/bin/qmail-queue allow qmail-queue to read the config file used by the 'taps' patch: /var/qmail/control/taps allow qmail-queue to put a message into the queue: (create, edit, delete and link files) /var/qmail/queue/pid (and subdirectories) /var/qmail/queue/mess (and subdirectories) /var/qmail/queue/intd (and subdirectories) /var/qmail/queue/todo (and subdirectories) For testing I specified the context "httpd_sys_content_t" but I know that it isn't the desired context. What context(s) should I specify for the aforementioned programs, directories and configuration files? Are there any other things I should do or consider besides setting the context(s)? Your guidance is greatly appreciated. From selinux at hilbig.name Tue May 13 18:57:07 2008 From: selinux at hilbig.name (D. Hilbig) Date: Tue, 13 May 2008 11:57:07 -0700 Subject: FW: SELinux, apache/php and qmail's sendmail Message-ID: <22B2C789DC6C49C49C18A5C02803275F@LAP21> Can someone please help me with this? -----Original Message----- From: D. Hilbig [mailto:selinux at hilbig.name] Sent: Thursday, May 08, 2008 10:14 AM To: 'fedora-selinux-list at redhat.com' Subject: SELinux, apache/php and qmail's sendmail I use qmail instead of sendmail on RHEL v5 and I could use some advice on setting contexts for qmail's sendmail so that apache/php can use it. Below are the files and directories involved with qmail's sendmail (and delivery to queue) allow apache/php to invoke qmail's sendmail program: /var/qmail/bin/sendmail allow qmail's sendmail to invoke qmail-inject program: /var/qmail/bin/qmail-inject allow qmail-inject to list the contents of the config files directory: /var/qmail/control allow qmail-inject to read the config files it uses: /var/qmail/control/defaultdomain /var/qmail/control/deaulthost /var/qmail/control/idhost /var/qmail/control/plusdomain /var/qmail/control/me allow qmail-inject to invoke qmail-queue program: /var/qmail/bin/qmail-queue allow qmail-queue to read the config file used by the 'taps' patch: /var/qmail/control/taps allow qmail-queue to put a message into the queue: (create, edit, delete and link files) /var/qmail/queue/pid (and subdirectories) /var/qmail/queue/mess (and subdirectories) /var/qmail/queue/intd (and subdirectories) /var/qmail/queue/todo (and subdirectories) For testing I specified the context "httpd_sys_content_t" but I know that it isn't the desired context. What context(s) should I specify for the aforementioned programs, directories and configuration files? Are there any other things I should do or consider besides setting the context(s)? Your guidance is greatly appreciated. From dant at cdkkt.com Tue May 13 19:09:34 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 13 May 2008 12:09:34 -0700 Subject: Samba shares... Message-ID: <021126B987E43D44A860139823C0791103FD72@mail.cdkkt.com> Daniel J Walsh |Daniel B. Thurman wrote: |> Stephen Smalley wrote: |> |On Tue, 2008-05-13 at 10:27 -0700, Daniel B. Thurman wrote: |> |> Daniel B. Thurman wrote: |> |> |Stephen Smalley |> |> ||On Tue, 2008-05-13 at 08:12 -0700, Daniel B. Thurman wrote: |> |> ||> Stephen Smalley wrote: |> |> ||> >> Daniel B. Thurman wrote: |> |> ||> >> I am not sure what is going on. I am unable to get |> |> ||> >> samba shares to work for an NTFS filesystem. I do |> |> ||> >> have several shares working for ext3 filesystems. |> |> ||> >> |> |> ||> >> Here is what I did: |> |> ||> >> |> |> ||> >> 1) Create an empty directory: /AV |> |> ||> >> 2) chcon -t samba_share_t /AV |> |> ||> >> 3) chmod 775 !$ |> |> ||> >> 4) chgrp avusers !$ |> |> ||> >> 5) Add to fstab |> |> ||> >> /dev/sda1 /AV ntfs defaults 1 2 |> |> | [snipped!] |> |> || |> |> ||It is just another mount option, so you can just do |something like: |> |> ||/dev/sda1 /AV ntfs |> |> |defaults,context=system_u:object_r:samba_share_t 1 2 |> |> | |> |> |Yes, I thought so. I tried that and the context does not |> |> |change. Any ideas? |> |> |> |> Mounting an NTFS filesystem even with context options, |> |> the context always remains as fusefs_t. I am allowed |> |> to change the context on the directory before the mount, |> |> but not after the mount. After mounting, I am not allowed |> |> to chcon the mounted FS as it says that the Operation is |> |> not allowed. |> | |> |Can you confirm that if you umount /AV and then mount it with the |> |context= option that it really doesn't work for you? You do have to |> |umount it though if you previously mounted it w/o the |context option to |> |make the option take affect. |> |> Yes, I can confirm that adding context= to the option line |> in /etc/fstab does not seem to do anything, i.e. the context |> does not change and remains fusefs_t. I tried several times, |> and even tried the fscontext= as well, neither seems to work. |> |> I was forced to reboot sometimes since I was not at times |> able to unmount the /AV filesystem, it sometimes reports |> that the /AV filesystem was 'busy'. This seems to happen |> if I mount/unmount several times then it says 'busy', |> preventing me from unmounting. Hmm. |> |> |I'm not sure why a context mount option wouldn't work for |fuse - Eric? |> | |> |fuse itself won't let you chcon (setxattr) the files unless the |> |filesystem supports setxattr, which is why you get Operation not |> |supported there. |> | |> |> I even tried: setsebool -P samba_export_all_rw=1 and that |> |> does not work, either. |> |> |> |> If I setenforce 0, I can share the NTFS filesystem, but I |> |> really do not want to do this. Can someone please give me |> |> a workaround? |> | |> |You can certainly generate a local policy module that gives |access to |> |fusefs_t, but it would be better if we could get the context mount |> |option to work. |> |> I will try anything you suggest. Let me know if you can |> resolve this issue, otherwise let me know (in detail) how |> to write a policy as a last resort? |> |> Thanks much! |> Dan |This looks like a bug. Seems so. Also, I tried disabling the fuse service and rebooted and for some reason, the fusefs still runs? It still mounts /media files even when this service is so-called disabled? I went back to look to see if the service was running (it wasn't) and even tried ps -ef| grep fuse (finding no match), so why is fuse filesystem still running? Is that a major bug or is it that the fuse service has no relation to the fusefs? Well, can I have a policy work around or will it fail anyway due to fuse? BTW: I am running Fedora F8. Thanks! Dan From dant at cdkkt.com Tue May 13 19:23:35 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 13 May 2008 12:23:35 -0700 Subject: Samba shares... Message-ID: <021126B987E43D44A860139823C079110E2D6D@mail.cdkkt.com> Daniel B. Thurman wrote: |Daniel J Walsh [ snip! ] ||This looks like a bug. |Seems so. Also, I tried disabling the fuse service |and rebooted and for some reason, the fusefs still |runs? It still mounts /media files even when this |service is so-called disabled? I went back to look |to see if the service was running (it wasn't) and |even tried ps -ef| grep fuse (finding no match), so |why is fuse filesystem still running? Is that a major |bug or is it that the fuse service has no relation to |the fusefs? | |Well, can I have a policy work around or will it fail |anyway due to fuse? | |BTW: I am running Fedora F8. Oh man.... This is what I did: 1) Disable the fuse service permemantly 2) Unmount all fuse filesystems (as root) 3) rmmod fuse 4) lsmod| grep fuse (make sure fuse module is NOT loaded) 5) mount /dev/sda1 /AV -t ntfs -o context=system_u:object_r:samba_share_t 6) lsmod|grep fuse (module is reloaded!) 7) ls -ldZ /AV shows fusefs_t context. So it looks like there is no possible way to get rid of the fuse filesystem module, mount seems to force a fuse filesystem regardless of attempts NOT to do so! Grrr.... Well, please let me know what to do at this point. Seems I have to wait or to setenforce 0 for now until this fix for F8 appears upstream? Thanks for all your time guys! Dan From sds at tycho.nsa.gov Tue May 13 19:27:18 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 13 May 2008 15:27:18 -0400 Subject: Samba shares... In-Reply-To: <021126B987E43D44A860139823C079110E2D6B@mail.cdkkt.com> References: <021126B987E43D44A860139823C079110E2D6B@mail.cdkkt.com> Message-ID: <1210706838.6206.232.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-13 at 11:30 -0700, Daniel B. Thurman wrote: > |You can certainly generate a local policy module that gives access to > |fusefs_t, but it would be better if we could get the context mount > |option to work. > > I will try anything you suggest. Let me know if you can > resolve this issue, otherwise let me know (in detail) how > to write a policy as a last resort? To generate local policy for this issue, you'd do something like this: $ su - # ausearch -m AVC | grep fuse | audit2allow -M myfuse # semodule -i myfuse.pp Then the fuse-related denials should be allowed. -- Stephen Smalley National Security Agency From dant at cdkkt.com Tue May 13 19:55:04 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Tue, 13 May 2008 12:55:04 -0700 Subject: Samba shares... Message-ID: <021126B987E43D44A860139823C0791103FD73@mail.cdkkt.com> Stephen Smalley |Daniel B. Thurman wrote: |> |You can certainly generate a local policy module that gives |> |access to fusefs_t, but it would be better if we could get |> |the context mount option to work. |> |> I will try anything you suggest. Let me know if you can |> resolve this issue, otherwise let me know (in detail) how |> to write a policy as a last resort? | |To generate local policy for this issue, you'd do something like this: | |$ su - |# ausearch -m AVC | grep fuse | audit2allow -M myfuse |# semodule -i myfuse.pp | |Then the fuse-related denials should be allowed. Uh, almost. It still will not allow me to chmod or chgrp the mounted filesystem which means that I cannot write to the shared NTFS filesystem without assigning the proper permissions. I have set samba properties to allow writes but apparently this problem resides with fuse again. Grr. What can I do to allow samba shared writes? Thanks! Dan From paul at city-fan.org Tue May 13 22:50:11 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 13 May 2008 23:50:11 +0100 Subject: Fedora buildsys and SELinux In-Reply-To: <200805131229.37017.dennis@ausil.us> References: <1208379430.5019.286.camel@calliope.phig.org> <1210694768.3228.93.camel@localhost.localdomain> <4829C819.4010901@redhat.com> <200805131229.37017.dennis@ausil.us> Message-ID: <20080513235011.6a7fb7fc@metropolis.intra.city-fan.org> On Tue, 13 May 2008 12:29:30 -0500 Dennis Gilmore wrote: > On Tuesday 13 May 2008, Daniel J Walsh wrote: > > > > I don't have a problem with calling restorecon on every single file, > > since this is a limited number of files. The goal is to allow the > > chroot to run without mucking around with the host security. So I > > don't have to run permissive or disabled if I use mock/livecd. If > > mock/livecd have to relabel when they complete that is fine. > > > I would really like to enable selinux on the actual builders. Right > now it has to be disabled. If not alot of things build ok but > certain packages will switch to enforcing inside the chroot when the > host is in permissive mode. and it causes all sorts of fun and failed > builds. Which packages do this? I run my own mock builders with selinux enforcing on F8 and haven't come across anything like that, though obviously the Fedora builders are exposed to a much wider variety of packages than my small collection. Paul. From dwalsh at redhat.com Wed May 14 13:23:23 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 14 May 2008 09:23:23 -0400 Subject: Samba shares... In-Reply-To: <021126B987E43D44A860139823C0791103FD73@mail.cdkkt.com> References: <021126B987E43D44A860139823C0791103FD73@mail.cdkkt.com> Message-ID: <482AE7CB.2020108@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel B. Thurman wrote: | Stephen Smalley | |Daniel B. Thurman wrote: | |> |You can certainly generate a local policy module that gives | |> |access to fusefs_t, but it would be better if we could get | |> |the context mount option to work. | |> | |> I will try anything you suggest. Let me know if you can | |> resolve this issue, otherwise let me know (in detail) how | |> to write a policy as a last resort? | | | |To generate local policy for this issue, you'd do something like this: | | | |$ su - | |# ausearch -m AVC | grep fuse | audit2allow -M myfuse | |# semodule -i myfuse.pp | | | |Then the fuse-related denials should be allowed. | | Uh, almost. It still will not allow me to chmod or chgrp | the mounted filesystem which means that I cannot write to | the shared NTFS filesystem without assigning the proper | permissions. I have set samba properties to allow writes | but apparently this problem resides with fuse again. Grr. | | What can I do to allow samba shared writes? | | Thanks! | Dan Look for additional AVC's with ausearch You can run the above command another time. You can put the machine into permissive mode and gather all of the AVC messages setenforce 0 Run your test ausearch -m AVC | grep fuse | audit2allow -M myfuse semodule -i myfuse.pp setenforce 1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgq58sACgkQrlYvE4MpobPUCwCeOmeEF6ayyczUASCAfMzi05DD j60AnRwY+T5dlMRTJOtzvZcY605JjW+a =hWbq -----END PGP SIGNATURE----- From dwalsh at redhat.com Wed May 14 13:32:01 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 14 May 2008 09:32:01 -0400 Subject: FW: SELinux, apache/php and qmail's sendmail In-Reply-To: <22B2C789DC6C49C49C18A5C02803275F@LAP21> References: <22B2C789DC6C49C49C18A5C02803275F@LAP21> Message-ID: <482AE9D1.2010207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 D. Hilbig wrote: | Can someone please help me with this? | | | | -----Original Message----- | From: D. Hilbig [mailto:selinux at hilbig.name] | Sent: Thursday, May 08, 2008 10:14 AM | To: 'fedora-selinux-list at redhat.com' | Subject: SELinux, apache/php and qmail's sendmail | | | I use qmail instead of sendmail on RHEL v5 and I could use some advice on | setting contexts for qmail's sendmail so that apache/php can use it. | | Below are the files and directories involved with qmail's sendmail (and | delivery to queue) | | allow apache/php to invoke qmail's sendmail program: | /var/qmail/bin/sendmail | potentially sendmail_exec_t? semanage fcontext -a -t bin_t /var/qmail/bin/sendmail | allow qmail's sendmail to invoke qmail-inject program: | /var/qmail/bin/qmail-inject | All of the files in this directory should be labeled bin_t If not you can add this context by executing semanage fcontext -a -t bin_t '/var/qmail/bin(/.*)?' restorecon -R -v /var/qmail/bin | allow qmail-inject to list the contents of the config files directory: | /var/qmail/control | | allow qmail-inject to read the config files it uses: | /var/qmail/control/defaultdomain | /var/qmail/control/deaulthost | /var/qmail/control/idhost | /var/qmail/control/plusdomain | /var/qmail/control/me | | allow qmail-inject to invoke qmail-queue program: | /var/qmail/bin/qmail-queue | | allow qmail-queue to read the config file used by the 'taps' patch: | /var/qmail/control/taps | | allow qmail-queue to put a message into the queue: | (create, edit, delete and link files) | /var/qmail/queue/pid (and subdirectories) | /var/qmail/queue/mess (and subdirectories) | /var/qmail/queue/intd (and subdirectories) | /var/qmail/queue/todo (and subdirectories) | semanage fcontext -a -t mail_spool_t '/var/qmail/queue(/.*)?' restorecon -R -v /var/qmail/queuue | | | For testing I specified the context "httpd_sys_content_t" but I know that it | isn't the desired context. What context(s) should I specify for the | aforementioned programs, directories and configuration files? | | Are there any other things I should do or consider besides setting the | context(s)? | | Your guidance is greatly appreciated. | | -- I would try something like the above. | fedora-selinux-list mailing list | fedora-selinux-list at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-selinux-list After you make the changes above run the -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgq6dAACgkQrlYvE4MpobOKOACeJGjZETm7I8XWt3WYdQvtM1Z9 s+sAniRXcYS4C2iZfCMHXosn005b0TZ3 =GXq9 -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Wed May 14 13:35:48 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 14 May 2008 09:35:48 -0400 Subject: Samba shares... In-Reply-To: <482AE7CB.2020108@redhat.com> References: <021126B987E43D44A860139823C0791103FD73@mail.cdkkt.com> <482AE7CB.2020108@redhat.com> Message-ID: <1210772148.6206.340.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-05-14 at 09:23 -0400, Daniel J Walsh wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Daniel B. Thurman wrote: > | Stephen Smalley > | |Daniel B. Thurman wrote: > | |> |You can certainly generate a local policy module that gives > | |> |access to fusefs_t, but it would be better if we could get > | |> |the context mount option to work. > | |> > | |> I will try anything you suggest. Let me know if you can > | |> resolve this issue, otherwise let me know (in detail) how > | |> to write a policy as a last resort? > | | > | |To generate local policy for this issue, you'd do something like this: > | | > | |$ su - > | |# ausearch -m AVC | grep fuse | audit2allow -M myfuse > | |# semodule -i myfuse.pp > | | > | |Then the fuse-related denials should be allowed. > | > | Uh, almost. It still will not allow me to chmod or chgrp > | the mounted filesystem which means that I cannot write to > | the shared NTFS filesystem without assigning the proper > | permissions. I have set samba properties to allow writes > | but apparently this problem resides with fuse again. Grr. > | > | What can I do to allow samba shared writes? > | > | Thanks! > | Dan > Look for additional AVC's with ausearch > > You can run the above command another time. > > You can put the machine into permissive mode and gather all of the AVC > messages > > setenforce 0 > Run your test > ausearch -m AVC | grep fuse | audit2allow -M myfuse > semodule -i myfuse.pp > setenforce 1 Is he really encountering permission denials from SELinux, or are these denials from fuse? fuse does have special restrictions imposed on it that wouldn't apply to the native ntfs support. -- Stephen Smalley National Security Agency From Dario.Sciola at cse-cst.gc.ca Wed May 14 15:12:30 2008 From: Dario.Sciola at cse-cst.gc.ca (Sciola, Dario) Date: Wed, 14 May 2008 11:12:30 -0400 Subject: Stuck in init_t Message-ID: <80E9A9C4BD562A418AFA1226EF5FD9A307101C@ripsaw.CORP.CSE-CST.GC.CA> Classification: UNCLASSIFIED Hi, I've got a small application that I'm trying to get running as a service on and FC8 SELinux box. I've got an entry in my inittab file to kick start the app, but all my attempts at writing an appropriate policy leaves that app running in the init_t domain. The inittab file entry is: cds:2345:respawn:/usr/bin/CDSserver -l -p 2732 ps -efZ (observing this as a 'root' user) gives: system_u:system_r:init_t:s0 root 2663 1 0 10:01 ? 00:00:00 /usr/bin/CDSserver -l -p 2732 My .te file contains: policy_module(cdsserver,1.0.3) ######################################## # # Declarations # ######################################## # Type declarations ################### # the target domain: type cds_t; # Entrypoint for exec type cds_exec_t; # domain type #domain_type(cds_t) # Mark cds_t as a domain and cds_exec_t as an entrypoint init_daemon_domain(cds_t, cds_exec_t) domain_entry_file(cds_t, cds_exec_t) allow cds_t self:process execmem; ... My .fc file contains: /usr/bin/CDSserver -- gen_context(system_u:object_r:cds_exec_t,s0) My .if file contains: interface(`cds_domtrans',` gen_require(` type cds_t, cds_exec_t; ') domain_auto_trans($1,cds_exec_t,cds_t) allow $1 cds_t:fd use; allow cds_t $1:fd use; allow cds_t $1:fifo_file rw_file_perms; allow cds_t $1:process sigchld; ') I've also tried putting init_t as $1 in the domain_auto_trans() Why isn't the process transitioning to cds_t? I've looked at a lot of sites and examples and can't seem to figure out my problem. The policy is the targeted FC8 policy. Module compiles and loads (semodule) fine. # sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 21 Policy from config file: targeted Any ideas? Dario Sciola -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Wed May 14 17:22:58 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 14 May 2008 13:22:58 -0400 Subject: Stuck in init_t In-Reply-To: <80E9A9C4BD562A418AFA1226EF5FD9A307101C@ripsaw.CORP.CSE-CST.GC.CA> References: <80E9A9C4BD562A418AFA1226EF5FD9A307101C@ripsaw.CORP.CSE-CST.GC.CA> Message-ID: <1210785778.28282.11.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-05-14 at 11:12 -0400, Sciola, Dario wrote: > Classification: UNCLASSIFIED > > Hi, > > I've got a small application that I'm trying to get running as a > service on and FC8 SELinux box. I've got an entry in my inittab file > to kick start the app, but all my attempts at writing an appropriate > policy leaves that app running in the init_t domain. This kind of question likely belongs on selinux at tycho.nsa.gov, not here - it isn't really Fedora-specific. > The inittab file entry is: > > cds:2345:respawn:/usr/bin/CDSserver -l -p 2732 > > ps -efZ (observing this as a 'root' user) gives: > > system_u:system_r:init_t:s0 root 2663 1 0 10:01 ? > 00:00:00 /usr/bin/CDSserver -l -p 2732 > > My .te file contains: > > policy_module(cdsserver,1.0.3) > > ######################################## > # > # Declarations > # > ######################################## > > # Type declarations > ################### > > # the target domain: > type cds_t; > > # Entrypoint for exec > type cds_exec_t; > > > # domain type > #domain_type(cds_t) > > # Mark cds_t as a domain and cds_exec_t as an entrypoint > init_daemon_domain(cds_t, cds_exec_t) init_daemon_domain is for a normal daemon started by an /etc/rc.d script, not for something directly started by /sbin/init. You want init_domain() instead I think. > domain_entry_file(cds_t, cds_exec_t) This should be covered by the above. > allow cds_t self:process execmem; Better if you can avoid that. > ... > > My .fc file contains: > > /usr/bin/CDSserver -- > gen_context(system_u:object_r:cds_exec_t,s0) > > > My .if file contains: > > interface(`cds_domtrans',` > gen_require(` > type cds_t, cds_exec_t; > ') > > domain_auto_trans($1,cds_exec_t,cds_t) > > allow $1 cds_t:fd use; > allow cds_t $1:fd use; > allow cds_t $1:fifo_file rw_file_perms; > allow cds_t $1:process sigchld; > ') > > I've also tried putting init_t as $1 in the domain_auto_trans() An .if file serves no purpose unless you have something that calls the interfaces it defines. It just defines a set of interfaces for other .te files to use. > Why isn't the process transitioning to cds_t? I've looked at a lot of > sites and examples and can't seem to figure out my problem. The policy > is the targeted FC8 policy. Module compiles and loads (semodule) fine. > > # sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: permissive > Mode from config file: permissive > Policy version: 21 > Policy from config file: targeted > > Any ideas? > > > Dario Sciola > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Stephen Smalley National Security Agency From eparis at redhat.com Wed May 14 20:38:36 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 14 May 2008 16:38:36 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210697627.6206.179.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> <1210689405.3228.73.camel@localhost.localdomain> <1210690002.6206.154.camel@moss-spartans.epoch.ncsc.mil> <1210694768.3228.93.camel@localhost.localdomain> <1210697627.6206.179.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210797516.3061.4.camel@localhost.localdomain> > > ^M Installing: kbd ##################### [126/129] > > ^M Installing: kernel ##################### [127/129] > > ^M Installing: selinux-policy ##################### [128/129] > > ^M Installing: selinux-policy-targeted ##################### [129/129] > > > > All of this still went smoothly... > > > > libsemanage.dbase_llist_query: could not query record value > > > > No idea where this is coming from > > Maybe a table was empty. Might want to look under etc/selinux/targeted > within the chroot. Without any helpful input I've still been banging my head against this wall, cleaned up a bunch of stuff in how the livecd-tools make images, wrote some policy (going to need to redo it) and it seems like I'm building images at least now. Remember all of this is building F10 images on F10, I'm not trying to handle the 'illegal' context stuff at all, let just make that clear. Anyway, I'm still getting a couple of ?error? messages Installing: kbd ##################### [126/129] Installing: selinux-policy ##################### [127/129] Installing: selinux-policy-targeted ##################### [128/129] libsemanage.dbase_llist_query: could not query record value /usr/sbin/semanage: Invalid prefix user /usr/sbin/semanage: Invalid prefix user Installing: kernel ##################### [129/129] Only root can do that. e2fsck 1.40.9 (27-Apr-2008) Pass 1: Checking inodes, blocks, and sizes but I'm about to try to boot one of these things and see what happens. Anyone have hints on what to look for with the above error messages? As usual I don't know what a 'table' is in this context :) -Eric From dant at cdkkt.com Wed May 14 20:47:47 2008 From: dant at cdkkt.com (Daniel B. Thurman) Date: Wed, 14 May 2008 13:47:47 -0700 Subject: Samba shares... Message-ID: <021126B987E43D44A860139823C079110E2D70@mail.cdkkt.com> Daniel J Walsh wrote: |Daniel B. Thurman wrote: || Stephen Smalley || |Daniel B. Thurman wrote: || |> |You can certainly generate a local policy module that gives || |> |access to fusefs_t, but it would be better if we could get || |> |the context mount option to work. || |> || |> I will try anything you suggest. Let me know if you can || |> resolve this issue, otherwise let me know (in detail) how || |> to write a policy as a last resort? || | || |To generate local policy for this issue, you'd do something |like this: || | || |$ su - || |# ausearch -m AVC | grep fuse | audit2allow -M myfuse || |# semodule -i myfuse.pp || | || |Then the fuse-related denials should be allowed. || || Uh, almost. It still will not allow me to chmod or chgrp || the mounted filesystem which means that I cannot write to || the shared NTFS filesystem without assigning the proper || permissions. I have set samba properties to allow writes || but apparently this problem resides with fuse again. Grr. || || What can I do to allow samba shared writes? |Look for additional AVC's with ausearch | |You can run the above command another time. | |You can put the machine into permissive mode and gather all of the AVC |messages | |setenforce 0 |Run your test |ausearch -m AVC | grep fuse | audit2allow -M myfuse |semodule -i myfuse.pp |setenforce 1 Yup! That worked! Thanks, Dan! Dan From mike.clarkson at baesystems.com Wed May 14 23:11:33 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Wed, 14 May 2008 16:11:33 -0700 Subject: polyinstantiation of the /tmp dir Message-ID: <0794F277152EF94AA637E3AECF5CB70F939582@blums0042.bluelnk.net> I'm having a problem setting up polyinstantiation for the /tmp dir. I'm using RHEL5.1 and I've set it up to create instance directories under the /tmp-inst directory based on level when using newrole. It works, but the instance directory has ownership/permissions (dac permissions) set so that the user can not write to the polyinstantiated directory #ls -l /tmp-inst/ total 24 drwxr-xr-x 2 root root 4096 May 14 20:17 system_u:object_r:tmp_t:s0-s4:c0.c255_clarkson drwxr-xr-x 2 root root 4096 May 14 18:40 system_u:object_r:tmp_t:s4:c0.c255_clarkson Either the directories need to be created with the user as the owner (clarkson in this case), or the permissions need to be 777. I've set this up before on other boxes and had it work. Not sure what the difference is now. Any ideas? From tmraz at redhat.com Thu May 15 07:41:40 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 15 May 2008 09:41:40 +0200 Subject: polyinstantiation of the /tmp dir In-Reply-To: <0794F277152EF94AA637E3AECF5CB70F939582@blums0042.bluelnk.net> References: <0794F277152EF94AA637E3AECF5CB70F939582@blums0042.bluelnk.net> Message-ID: <1210837300.539.137.camel@vespa.frost.loc> On Wed, 2008-05-14 at 16:11 -0700, Clarkson, Mike R (US SSA) wrote: > I'm having a problem setting up polyinstantiation for the /tmp dir. I'm > using RHEL5.1 and I've set it up to create instance directories under > the /tmp-inst directory based on level when using newrole. It works, but > the instance directory has ownership/permissions (dac permissions) set > so that the user can not write to the polyinstantiated directory > > #ls -l /tmp-inst/ > total 24 > drwxr-xr-x 2 root root 4096 May 14 20:17 > system_u:object_r:tmp_t:s0-s4:c0.c255_clarkson > drwxr-xr-x 2 root root 4096 May 14 18:40 > system_u:object_r:tmp_t:s4:c0.c255_clarkson > > Either the directories need to be created with the user as the owner > (clarkson in this case), or the permissions need to be 777. > > I've set this up before on other boxes and had it work. Not sure what > the difference is now. Any ideas? Remove the instances and add debug option to the pam_namespace.so. Do you see anything suspicious in /var/log/secure? Also what ls -ld /tmp says? The permissions should be copied from the polydir. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From tmraz at redhat.com Thu May 15 17:11:54 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 15 May 2008 19:11:54 +0200 Subject: Differences between openssh and pam_selinux Message-ID: <1210871514.20548.53.camel@vespa.frost.loc> There are some differences in how openssh and pam_selinux get the user's context. As I want to replace part of the openssh's SELinux code with pam_selinux I'd like to know which one is more correct. Here's the rough algorithm for both: OpenSSH ======= 1. get selinux user & default level with getseuserbyname() 2. obtain default ctx with get_default_context_with_level() 3. obtain requested ctx for requested level with get_default_context_with_level() 4. set requested role to the requested ctx 5. set type for the requested role to the requested ctx (obtained from get_default_type(requested role)) 6. copy the requested ctx and set the requested level in the copy 7. compare the requested ctx with the copy - if not equal -> fail 8. do the points 3. - 7. with the difference that the default level is used instead of requested level 9. do security_compute_av with CONTEXT__CONTAINS to check whether the context from 7. is allowed for context from 8. if not allowed -> fail 10. use the context from 7. as the user's context. pam_selinux =========== 1. get selinux user & default level with getseuserbyname() 2. use get_ordered_context_list_with_level() to obtain list of context for the user & level, as the default user's context is taken the first one on the list 3. if this fails: 3a. the level and role is obtained from user and combined into a context with default type for the role and the selinux user 3b. this ctx is checked with security_check_context() - if fails -> fail else we have the user's context -> end 4. if 2. succeeds and module is configured to allow asking user for role/level then user is asked for requested role and level 5. the requested ctx starts as copy of the default ctx 6. the requested role is set to requested ctx, requested level is set and the default type (get_default_type()) for the requested role is set 7. the requested ctx is checked with security_check_context() - if fails -> fail 8. do security_compute_av with CONTEXT__CONTAINS to check whether the context from 7. is allowed for default context if not allowed -> fail 9. use the context from 7. as the user's context. So which one is correct if any? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From eparis at redhat.com Thu May 15 17:50:08 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 15 May 2008 13:50:08 -0400 Subject: livecd-creator + selinux Message-ID: <1210873808.3061.38.camel@localhost.localdomain> So I'm still stumbling along in the dark trying to get livecd-creator to build me a nice new F10 image inside an F10 host. I've actually got an image that built and runs, but not without its issues. my kickstart file has: auth --enableshadow --enablemd5 rootpw redhat but the livecd always has x for the password in /etc/password and * for the password in /etc/shadow. No ideas here I must admit. I'm highly doubtful its selinux since it happens in permissive and enforcing. I have just been booting into single user, calling passwd, init 3, and logging in to play around in my live image.... 3 errors/issues/quirks in building/running my livecd 1) libsemanage.dbase_llist_query: could not query record value I'm told empty table, but I don't know what that means 2) /usr/sbin/semanage: Invalid prefix user This pops out when semanage calls: if selinux.security_check_context("system_u:object_r:%s_home_t:s0" % prefix) != 0: I assume this has to do with my bastardized /selinux inside the chroot. Should we just make it != 0 && != -ENOENT or whatever the error is we get there? 3) When booting I get 3 messages that say: inode_doinit_with_dentry: no dentry for dev=dm-0 ino=8345 The 3 inodes in question correspond to /etc/udev /etc/udev/rules.d /etc/udev/rules.d/50-udev-default.rules no clues where this is coming from. I don't see it when I booted my host system.... Anyway, at this point I want clues/help/suggestions on how to create my hacked up /selinux inside the chroot. Right now all I'm going is creating it on the host system and bind mounting it into the chroot. I really should be creating this inside creator.py. All that needs to be inside it is 3 files. copies of mls and policyvers from the host system and load is a chrfile of /dev/null. I could just create those in the livecd image and they will get mounted on top of when its running, but I don't want to waste the 50 bytes or whatever it would take. Any good suggests on how to build this temp? Or where I could clean it out later? -Eric From sds at tycho.nsa.gov Thu May 15 18:36:16 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 15 May 2008 14:36:16 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210797516.3061.4.camel@localhost.localdomain> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> <1210689405.3228.73.camel@localhost.localdomain> <1210690002.6206.154.camel@moss-spartans.epoch.ncsc.mil> <1210694768.3228.93.camel@localhost.localdomain> <1210697627.6206.179.camel@moss-spartans.epoch.ncsc.mil> <1210797516.3061.4.camel@localhost.localdomain> Message-ID: <1210876576.28282.109.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-05-14 at 16:38 -0400, Eric Paris wrote: > > > ^M Installing: kbd ##################### [126/129] > > > ^M Installing: kernel ##################### [127/129] > > > ^M Installing: selinux-policy ##################### [128/129] > > > ^M Installing: selinux-policy-targeted ##################### [129/129] > > > > > > All of this still went smoothly... > > > > > > libsemanage.dbase_llist_query: could not query record value > > > > > > No idea where this is coming from > > > > Maybe a table was empty. Might want to look under etc/selinux/targeted > > within the chroot. > > Without any helpful input I've still been banging my head against this > wall, cleaned up a bunch of stuff in how the livecd-tools make images, > wrote some policy (going to need to redo it) and it seems like I'm > building images at least now. Remember all of this is building F10 > images on F10, I'm not trying to handle the 'illegal' context stuff at > all, let just make that clear. > > Anyway, I'm still getting a couple of ?error? messages > > Installing: kbd ##################### [126/129] > Installing: selinux-policy ##################### [127/129] > Installing: selinux-policy-targeted ##################### [128/129] > libsemanage.dbase_llist_query: could not query record value > /usr/sbin/semanage: Invalid prefix user > /usr/sbin/semanage: Invalid prefix user > > Installing: kernel ##################### [129/129] > Only root can do that. > e2fsck 1.40.9 (27-Apr-2008) > Pass 1: Checking inodes, blocks, and sizes > > but I'm about to try to boot one of these things and see what happens. > Anyone have hints on what to look for with the above error messages? As > usual I don't know what a 'table' is in this context :) The invalid prefix user is another artifact of semanage/seobject.py trying to check something against the host's policy rather than checking against the target policy just due to lack of adequate libsemanage interfaces. Calls to is_selinux_mls_enabled() and security_check_context() need to be turned into libsemanage calls. The could not query record value one is too generic. Might help to get a snapshot of the /etc/selinux/targeted tree that it built and see what's there. Or possibly patching libsemanage to give more useful output, but it's a bit hard due to abstraction layers there. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu May 15 19:30:39 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 15 May 2008 15:30:39 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210873808.3061.38.camel@localhost.localdomain> References: <1210873808.3061.38.camel@localhost.localdomain> Message-ID: <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote: > So I'm still stumbling along in the dark trying to get livecd-creator to > build me a nice new F10 image inside an F10 host. I've actually got an > image that built and runs, but not without its issues. > > my kickstart file has: > auth --enableshadow --enablemd5 > rootpw redhat > > but the livecd always has x for the password in /etc/password and * for > the password in /etc/shadow. No ideas here I must admit. I'm highly > doubtful its selinux since it happens in permissive and enforcing. I > have just been booting into single user, calling passwd, init 3, and > logging in to play around in my live image.... No ideas here - hopefully the livecd folks can help you with that one. > > 3 errors/issues/quirks in building/running my livecd > > 1) libsemanage.dbase_llist_query: could not query record value > I'm told empty table, but I don't know what that means Looking at selinux-policy.spec, I see that it runs semanage login -l and semanage user -l in its scriptlets. If it does that and there are no user or login entries defined yet, then you'd get that error I think. Not sure if that means that something went wrong earlier or if it is normal/legitimate. Dan? > 2) /usr/sbin/semanage: Invalid prefix user > This pops out when semanage calls: > if selinux.security_check_context("system_u:object_r:%s_home_t:s0" % prefix) != 0: > I assume this has to do with my bastardized /selinux inside the chroot. > Should we just make it != 0 && != -ENOENT or whatever the error is we > get there? That should work, and this check should really be replaced by a new libsemanage interface that checks against the target policy rather than the host policy, like the mls enabled test. > 3) When booting I get 3 messages that say: > inode_doinit_with_dentry: no dentry for dev=dm-0 ino=8345 > The 3 inodes in question correspond to > /etc/udev > /etc/udev/rules.d > /etc/udev/rules.d/50-udev-default.rules Happens when SELinux is setting up pre-existing inodes upon initial policy load and it cannot find a dentry for the inode and thus cannot invoke the ->getxattr method on it. Likely harmless. When/if the files are subsequently looked up, the inodes should get set up at that time upon the d_instantiate/d_splice_alias. > no clues where this is coming from. I don't see it when I booted my > host system.... > > > > Anyway, at this point I want clues/help/suggestions on how to create my > hacked up /selinux inside the chroot. Right now all I'm going is > creating it on the host system and bind mounting it into the chroot. I > really should be creating this inside creator.py. All that needs to be > inside it is 3 files. copies of mls and policyvers from the host > system and load is a chrfile of /dev/null. I could just create those in > the livecd image and they will get mounted on top of when its running, > but I don't want to waste the 50 bytes or whatever it would take. Any > good suggests on how to build this temp? Or where I could clean it out > later? > > -Eric -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu May 15 19:10:40 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 15 May 2008 15:10:40 -0400 Subject: Fedora buildsys and SELinux In-Reply-To: <1210876576.28282.109.camel@moss-spartans.epoch.ncsc.mil> References: <1208379430.5019.286.camel@calliope.phig.org> <1208879711.15796.143.camel@moss-spartans.epoch.ncsc.mil> <1208882324.15796.151.camel@moss-spartans.epoch.ncsc.mil> <1209748815.25678.602.camel@moss-spartans.epoch.ncsc.mil> <1210361590.3057.5.camel@localhost.localdomain> <1210363217.3057.9.camel@localhost.localdomain> <1210594647.6206.10.camel@moss-spartans.epoch.ncsc.mil> <1210624387.20164.31.camel@aglarond.local> <43af0f430805121405x4c6c309fuceffb7c8b494ef0c@mail.gmail.com> <1210627584.3228.54.camel@localhost.localdomain> <43af0f430805130544i785e3dabp41bd24bb3a2c1d67@mail.gmail.com> <1210689405.3228.73.camel@localhost.localdomain> <1210690002.6206.154.camel@moss-spartans.epoch.ncsc.mil> <1210694768.3228.93.camel@localhost.localdomain> <1210697627.6206.179.camel@moss-spartans.epoch.ncsc.mil> <1210797516.3061.4.camel@localhost.localdomain> <1210876576.28282.109.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210878640.28282.138.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-05-15 at 14:36 -0400, Stephen Smalley wrote: > On Wed, 2008-05-14 at 16:38 -0400, Eric Paris wrote: > > > > ^M Installing: kbd ##################### [126/129] > > > > ^M Installing: kernel ##################### [127/129] > > > > ^M Installing: selinux-policy ##################### [128/129] > > > > ^M Installing: selinux-policy-targeted ##################### [129/129] > > > > > > > > All of this still went smoothly... > > > > > > > > libsemanage.dbase_llist_query: could not query record value > > > > > > > > No idea where this is coming from > > > > > > Maybe a table was empty. Might want to look under etc/selinux/targeted > > > within the chroot. > > > > Without any helpful input I've still been banging my head against this > > wall, cleaned up a bunch of stuff in how the livecd-tools make images, > > wrote some policy (going to need to redo it) and it seems like I'm > > building images at least now. Remember all of this is building F10 > > images on F10, I'm not trying to handle the 'illegal' context stuff at > > all, let just make that clear. > > > > Anyway, I'm still getting a couple of ?error? messages > > > > Installing: kbd ##################### [126/129] > > Installing: selinux-policy ##################### [127/129] > > Installing: selinux-policy-targeted ##################### [128/129] > > libsemanage.dbase_llist_query: could not query record value > > /usr/sbin/semanage: Invalid prefix user > > /usr/sbin/semanage: Invalid prefix user > > > > Installing: kernel ##################### [129/129] > > Only root can do that. > > e2fsck 1.40.9 (27-Apr-2008) > > Pass 1: Checking inodes, blocks, and sizes > > > > but I'm about to try to boot one of these things and see what happens. > > Anyone have hints on what to look for with the above error messages? As > > usual I don't know what a 'table' is in this context :) > > The invalid prefix user is another artifact of semanage/seobject.py > trying to check something against the host's policy rather than checking > against the target policy just due to lack of adequate libsemanage > interfaces. Calls to is_selinux_mls_enabled() and > security_check_context() need to be turned into libsemanage calls. > > The could not query record value one is too generic. Might help to get > a snapshot of the /etc/selinux/targeted tree that it built and see > what's there. Or possibly patching libsemanage to give more useful > output, but it's a bit hard due to abstraction layers there. BTW, are you doing all of this with the patch for rpm_execcon that I sent you? If so, I should likely commit that upstream. -- Stephen Smalley National Security Agency From eparis at redhat.com Thu May 15 20:33:55 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 15 May 2008 16:33:55 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210883635.3061.46.camel@localhost.localdomain> #4 At the end of the rpm transaction when everything is installed it calls restorecon and I get one for (I assume) every file almost all of which look like: /sbin/restorecon reset /srv context system_u:object_r:var_t:s0->system_u:object_r:var_t:s0 Notice nothing changed? Again I assume its my hack of a /selinux which causes it and I'll try to run down why, but maybe someone else sees that quickly. -Eric From sds at tycho.nsa.gov Thu May 15 20:47:18 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 15 May 2008 16:47:18 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210883635.3061.46.camel@localhost.localdomain> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> <1210883635.3061.46.camel@localhost.localdomain> Message-ID: <1210884438.28282.167.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-05-15 at 16:33 -0400, Eric Paris wrote: > #4 At the end of the rpm transaction when everything is installed it > calls restorecon and I get one for (I assume) every file almost all of > which look like: > > /sbin/restorecon reset /srv context system_u:object_r:var_t:s0->system_u:object_r:var_t:s0 > > Notice nothing changed? Again I assume its my hack of a /selinux which > causes it and I'll try to run down why, but maybe someone else sees that > quickly. That suggests it is being called with the -f (force) flag from e.g. /sbin/fixfiles. selinux-policy.spec does a fixfiles -C file_contexts.pre restore fixfiles -C does a diff between the old and new file contexts configurations and applies restorecon to the result. There is some serious magic in there, and it is all Dan's fault ;) -- Stephen Smalley National Security Agency From notting at redhat.com Thu May 15 21:05:49 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 May 2008 17:05:49 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210873808.3061.38.camel@localhost.localdomain> References: <1210873808.3061.38.camel@localhost.localdomain> Message-ID: <20080515210549.GA645@nostromo.devel.redhat.com> Eric Paris (eparis at redhat.com) said: > So I'm still stumbling along in the dark trying to get livecd-creator to > build me a nice new F10 image inside an F10 host. I've actually got an > image that built and runs, but not without its issues. > > my kickstart file has: > auth --enableshadow --enablemd5 > rootpw redhat > > but the livecd always has x for the password in /etc/password and * for > the password in /etc/shadow. No ideas here I must admit. I'm highly > doubtful its selinux since it happens in permissive and enforcing. I > have just been booting into single user, calling passwd, init 3, and > logging in to play around in my live image.... LiveCD has no root password. AFAIK, it just ignores that line. Bill From eparis at redhat.com Thu May 15 21:20:27 2008 From: eparis at redhat.com (Eric Paris) Date: Thu, 15 May 2008 17:20:27 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210884438.28282.167.camel@moss-spartans.epoch.ncsc.mil> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> <1210883635.3061.46.camel@localhost.localdomain> <1210884438.28282.167.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210886427.3061.67.camel@localhost.localdomain> On Thu, 2008-05-15 at 16:47 -0400, Stephen Smalley wrote: > On Thu, 2008-05-15 at 16:33 -0400, Eric Paris wrote: > > #4 At the end of the rpm transaction when everything is installed it > > calls restorecon and I get one for (I assume) every file almost all of > > which look like: > > > > /sbin/restorecon reset /srv context system_u:object_r:var_t:s0->system_u:object_r:var_t:s0 > > > > Notice nothing changed? Again I assume its my hack of a /selinux which > > causes it and I'll try to run down why, but maybe someone else sees that > > quickly. > > That suggests it is being called with the -f (force) flag from > e.g. /sbin/fixfiles. selinux-policy.spec does a > fixfiles -C file_contexts.pre restore > > fixfiles -C does a diff between the old and new file contexts > configurations and applies restorecon to the result. There is some > serious magic in there, and it is all Dan's fault ;) ok, in the livecd-creator kickstart.py I see if os.path.exists(self.path("/sbin/restorecon")): self.call(["/sbin/restorecon", "-l", "-v", "-r", "-F", "-e", "/proc", "-e", "/sys", "-e", "/dev", "-e", "/selinux", "/"]) So there is our -F. Is there a way to get it to fix "user" without getting it to fix "things that aren't wrong" -Eric From dmcclendon at vmware.com Thu May 15 22:30:33 2008 From: dmcclendon at vmware.com (Douglas McClendon) Date: Thu, 15 May 2008 15:30:33 -0700 Subject: livecd-creator + selinux In-Reply-To: <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <482CB989.803@vmware.com> Stephen Smalley wrote: > On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote: >> So I'm still stumbling along in the dark trying to get livecd-creator to >> build me a nice new F10 image inside an F10 host. I've actually got an >> image that built and runs, but not without its issues. >> >> my kickstart file has: >> auth --enableshadow --enablemd5 >> rootpw redhat As Bill said, the handling of rootpw is non-intuitive from a historical kickstart perspective. I once suggested changing the kickstarts in livecd-tools to explicitly have rootpw lines (and then nuke the pw in %post), such that they would be generic fully automated kickstarts. People disagreed. (though what you observed is a bug that can be fixed without heeding my suggestion) >> 3) When booting I get 3 messages that say: >> inode_doinit_with_dentry: no dentry for dev=dm-0 ino=8345 >> The 3 inodes in question correspond to >> /etc/udev >> /etc/udev/rules.d >> /etc/udev/rules.d/50-udev-default.rules > > Happens when SELinux is setting up pre-existing inodes upon initial > policy load and it cannot find a dentry for the inode and thus cannot > invoke the ->getxattr method on it. Likely harmless. When/if the > files are subsequently looked up, the inodes should get set up at that > time upon the d_instantiate/d_splice_alias. I've seen these messages forever, though didn't realize till now that they were an selinux related issue. If they are truly harmless, can someone remove the code that spits out the message please? FYI- note that what is going on with that file is that it is being modified by the initramfs before policy is loaded- see do_live_from_base_loop in /usr/lib/livecd-creator/mayflower, i.e. stuff like this- echo "KERNEL==\"hd[a-z]\", BUS==\"ide\", SYSFS{removable}==\"1\", ATTRS{media}==\"cdrom\", PROGRAM=\"/lib/udev/vol_id -l %N\", RESULT==\"\$CDLABEL\", SYMLINK+=\"live\"" >> /sysroot/etc/udev/rules.d/50-udev* > >> no clues where this is coming from. I don't see it when I booted my >> host system.... >> >> >> >> Anyway, at this point I want clues/help/suggestions on how to create my >> hacked up /selinux inside the chroot. Out of curiosity, if someone feels like answering- are there any plans for selinux to support chroots in the sense of policy and even enabled/disabled being completely different between the host and the chroot? Seems like "chroot /mnt/sysimage rpm " ought to 'just work(tm)'. But maybe I'm expecting too much functionality from a default fedora system. -dmc From olivares14031 at yahoo.com Thu May 15 22:46:00 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 15 May 2008 15:46:00 -0700 (PDT) Subject: lost gnome In-Reply-To: <482CBBB6.6040809@cox.net> Message-ID: <357842.95897.qm@web52605.mail.re2.yahoo.com> --- "Clyde E. Kunkel" wrote: > Antonio Olivares wrote: > > Dear all, > > > > After changing the repos to point back to rawhide. > I > > have lost gnome in the process. I cannot log into > > gnome. Thankfully KDE does work :), However, I > would > > like to have both functioning if possible. > > > > I'll attach a text file which shows messages that > > could be useful to fix this issue. > > > > Regards, > > > > Antonio > > > > > > > > > Earlier thread discussed this and response from Tom > London: > > "Reverting GConf2 packages "fixed this for me". (I > noticed some new > SELinux messages that may be causing this, and > reported to dwalsh > already.) > > I had other issues that reverting gnome-session and > gnome-settings-daemon fixed..... > > tom" > -- > --------------------------------- > Regards, > > Old Fart > > -- > fedora-test-list mailing list > fedora-test-list at redhat.com > To unsubscribe: > https://www.redhat.com/mailman/listinfo/fedora-test-list > Thank you very much Clyde, That is it! Selinux has its hands on it: I'll run KDE in the meantime, the cure looks a bit complicated :( Part of dmesg: [olivares at localhost ~]$ uname -a Linux localhost 2.6.25.2-5.fc10.i686 #1 SMP Wed May 7 18:06:55 EDT 2008 i686 athlon i386 GNU/Linux [olivares at localhost ~]$ cat /etc/fedora-release Fedora release 9.90 (Rawhide) [olivares at localhost ~]$ dmesg Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.25.2-5.fc10.i686 (mockbuild@) (gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Wed May 7 18:06:55 EDT 2008 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000002ffd0000 (usable) BIOS-e820: 000000002ffd0000 - 000000002ffdf000 (ACPI data) BIOS-e820: 000000002ffdf000 - 0000000030000000 (ACPI NVS) BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff7c0000 - 0000000100000000 (reserved) ***** removed to show relevant parts ***** SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts SELinux: initialized (dev autofs, type autofs), uses genfs_contexts SELinux: initialized (dev autofs, type autofs), uses genfs_contexts SELinux: initialized (dev autofs, type autofs), uses genfs_contexts Bluetooth: Core ver 2.11 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.9 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 Bluetooth: BNEP (Ethernet Emulation) ver 1.2 Bluetooth: BNEP filters: protocol multicast Bridge firewalling registered pan0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM feature. serial8250: too much work for irq18 serial8250: too much work for irq18 type=1400 audit(1210890146.560:4): avc: denied { execute } for pid=2337 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890146.610:5): avc: denied { execute } for pid=2339 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890147.848:6): avc: denied { execute } for pid=2350 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890147.850:7): avc: denied { execute } for pid=2352 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890147.865:8): avc: denied { execute } for pid=2354 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890147.877:9): avc: denied { execute } for pid=2356 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890148.582:10): avc: denied { execute } for pid=2363 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890148.632:11): avc: denied { execute } for pid=2365 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890148.650:12): avc: denied { execute } for pid=2367 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890148.662:13): avc: denied { execute } for pid=2369 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file printk: 196 messages suppressed. type=1400 audit(1210890151.618:79): avc: denied { execute } for pid=2505 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file printk: 57 messages suppressed. type=1400 audit(1210890163.178:99): avc: denied { execute } for pid=2556 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890163.214:100): avc: denied { execute } for pid=2560 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file printk: 33 messages suppressed. gnome-session[2618]: segfault at 0 ip 00d36187 sp bfc554a4 error 4 in libglib-2.0.so.0.1600.3[cdc000+e0000] type=1400 audit(1210890178.407:112): avc: denied { execute } for pid=2831 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890178.421:113): avc: denied { execute } for pid=2834 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file printk: 250 messages suppressed. type=1400 audit(1210890187.515:197): avc: denied { execute } for pid=3058 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890187.562:198): avc: denied { execute } for pid=3063 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file printk: 33 messages suppressed. type=1400 audit(1210890240.289:210): avc: denied { read } for pid=3496 comm="nm-system-setti" name="PolicyKit.reload" dev=dm-0 ino=3244718 scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_crond_var_lib_t:s0 tclass=file type=1400 audit(1210890240.432:211): avc: denied { getattr } for pid=3496 comm="nm-system-setti" path="/dev/root" dev=tmpfs ino=318 scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file type=1400 audit(1210890242.221:212): avc: denied { execstack } for pid=3506 comm="nspluginscan" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process klauncher[3388]: segfault at 8048814 ip 001c8da8 sp bffe22c0 error 7 in libX11.so.6.2.0[1b3000+fd000] nepomukservices[3465] general protection ip:448adef sp:bfdc34f0 error:0 in libnepomuk.so.4.1.0[4460000+6d000] type=1400 audit(1210890272.055:213): avc: denied { execute } for pid=3593 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890272.069:214): avc: denied { execute } for pid=3596 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890272.314:215): avc: denied { execute } for pid=3622 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890272.317:216): avc: denied { execute } for pid=3624 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890272.319:217): avc: denied { execute } for pid=3626 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890272.321:218): avc: denied { execute } for pid=3628 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890272.396:219): avc: denied { execute } for pid=3637 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890272.411:220): avc: denied { execute } for pid=3640 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file printk: 226 messages suppressed. type=1400 audit(1210890280.758:296): avc: denied { execute } for pid=3818 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file type=1400 audit(1210890280.793:297): avc: denied { execute } for pid=3822 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=32542974 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file printk: 36 messages suppressed. type=1400 audit(1210890308.692:310): avc: denied { execstack } for pid=4157 comm="nspluginscan" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process [olivares at localhost ~]$ ccd: to fedora-selinux-list at redhat.com Regards, Antonio From christian.lange3 at uni-rostock.de Fri May 16 06:28:09 2008 From: christian.lange3 at uni-rostock.de (Christian Lange) Date: Fri, 16 May 2008 08:28:09 +0200 Subject: tools that present a graphical abstraction of a SELinux policy Message-ID: Hi, I'm a student of the university of Rostock, In the scope of my master thesis I want to get an overview about existing graphical tools (commercial or free), abstracting from underlying SELinux details, helping users to define and maintain SELinux policies (TE & MCS). So far, I found the following tools: - SLIDE - VIRGIL - Tresys Brickwall Security Suite They only use masks for data input and don't abstract from the policy to show a graph. My questions are: - Is there any tool that creates a abstract view of a policy as a graph or something like that? - Is there any demand for such a tool? Thanks in advance From fdsubs at t-online.hu Fri May 16 08:10:34 2008 From: fdsubs at t-online.hu (Daniel Fazekas) Date: Fri, 16 May 2008 10:10:34 +0200 Subject: spamc not working from procmail in Fedora 9 Message-ID: SELinux appears to stop spamc from being called from procmail: type=1401 audit(1210924808.115:14): security_compute_sid: invalid context system_u:system_r:spamc_t:s0 for scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=process procmail logs: /usr/bin/spamc: /usr/bin/spamc: cannot execute binary file procmail: Error while writing to "/usr/bin/spamc" procmail: Rescue of unfiltered data succeeded In my .procmailrc I have this line: INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc Used to work fine in previous releases of Fedora. Is there anything I could set to allow this? I have already tried a full touch ./autorelabel && reboot, it didn't help. SELinux is using selinux-policy-targeted-3.3.1-42.fc9.noarch selinux-policy-3.3.1-42.fc9.noarch From dwalsh at redhat.com Fri May 16 11:56:24 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 May 2008 07:56:24 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210886427.3061.67.camel@localhost.localdomain> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> <1210883635.3061.46.camel@localhost.localdomain> <1210884438.28282.167.camel@moss-spartans.epoch.ncsc.mil> <1210886427.3061.67.camel@localhost.localdomain> Message-ID: <482D7668.6010107@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Paris wrote: | On Thu, 2008-05-15 at 16:47 -0400, Stephen Smalley wrote: |> On Thu, 2008-05-15 at 16:33 -0400, Eric Paris wrote: |>> #4 At the end of the rpm transaction when everything is installed it |>> calls restorecon and I get one for (I assume) every file almost all of |>> which look like: |>> |>> /sbin/restorecon reset /srv context system_u:object_r:var_t:s0->system_u:object_r:var_t:s0 |>> |>> Notice nothing changed? Again I assume its my hack of a /selinux which |>> causes it and I'll try to run down why, but maybe someone else sees that |>> quickly. |> That suggests it is being called with the -f (force) flag from |> e.g. /sbin/fixfiles. selinux-policy.spec does a |> fixfiles -C file_contexts.pre restore |> |> fixfiles -C does a diff between the old and new file contexts |> configurations and applies restorecon to the result. There is some |> serious magic in there, and it is all Dan's fault ;) | | ok, in the livecd-creator kickstart.py I see | | if os.path.exists(self.path("/sbin/restorecon")): | self.call(["/sbin/restorecon", "-l", "-v", "-r", "-F", "-e", "/proc", "-e", "/sys", "-e", "/dev", "-e", "/selinux", "/"]) | | So there is our -F. Is there a way to get it to fix "user" without | getting it to fix "things that aren't wrong" | | -Eric | Remove the -v Although this looks wrong and makes no sense in restorecon/setfiles. /* * Do not relabel the file if the matching specification is * <> or the file is already labeled according to the * specification. */ if ((strcmp(newcon, "<>") == 0) || (context && (strcmp(context, newcon) == 0) && !force)) { freecon(context); goto out; } The !force check should be removed. It makes no send to relabel in the case of the context being the same or the context being none. Should be /* * Do not relabel the file if the matching specification is * <> or the file is already labeled according to the * specification. */ if ((strcmp(newcon, "<>") == 0) || (context && (strcmp(context, newcon) == 0)) { freecon(context); goto out; } I will provide a patch and update. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgtdmgACgkQrlYvE4MpobOtqgCgq0rDD7Be3h4Vb5hJDrvMebsf 6bAAoKaeIQqTknhhKaZHRehxsLQU4i0u =0LXA -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Fri May 16 11:57:38 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 16 May 2008 07:57:38 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210886427.3061.67.camel@localhost.localdomain> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> <1210883635.3061.46.camel@localhost.localdomain> <1210884438.28282.167.camel@moss-spartans.epoch.ncsc.mil> <1210886427.3061.67.camel@localhost.localdomain> Message-ID: <1210939058.28282.183.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-05-15 at 17:20 -0400, Eric Paris wrote: > On Thu, 2008-05-15 at 16:47 -0400, Stephen Smalley wrote: > > On Thu, 2008-05-15 at 16:33 -0400, Eric Paris wrote: > > > #4 At the end of the rpm transaction when everything is installed it > > > calls restorecon and I get one for (I assume) every file almost all of > > > which look like: > > > > > > /sbin/restorecon reset /srv context system_u:object_r:var_t:s0->system_u:object_r:var_t:s0 > > > > > > Notice nothing changed? Again I assume its my hack of a /selinux which > > > causes it and I'll try to run down why, but maybe someone else sees that > > > quickly. > > > > That suggests it is being called with the -f (force) flag from > > e.g. /sbin/fixfiles. selinux-policy.spec does a > > fixfiles -C file_contexts.pre restore > > > > fixfiles -C does a diff between the old and new file contexts > > configurations and applies restorecon to the result. There is some > > serious magic in there, and it is all Dan's fault ;) > > ok, in the livecd-creator kickstart.py I see > > if os.path.exists(self.path("/sbin/restorecon")): > self.call(["/sbin/restorecon", "-l", "-v", "-r", "-F", "-e", "/proc", "-e", "/sys", "-e", "/dev", "-e", "/selinux", "/"]) > > So there is our -F. Is there a way to get it to fix "user" without > getting it to fix "things that aren't wrong" I think we should change setfiles/restorecon to just not do that even with -F. IIRC, changing it to always invoke setfilecon even if the contexts were the same was motivated by the problem we used to have where the in-core label and the on-disk xattr could get out of sync. Patch below. Note that restorecon is just a link to setfiles that presents a different default user interface and behaviors (ever since I coalesced them). Index: policycoreutils/setfiles/setfiles.c =================================================================== --- policycoreutils/setfiles/setfiles.c (revision 2879) +++ policycoreutils/setfiles/setfiles.c (working copy) @@ -495,7 +495,7 @@ * specification. */ if ((strcmp(newcon, "<>") == 0) || - (context && (strcmp(context, newcon) == 0) && !force)) { + (context && (strcmp(context, newcon) == 0))) { freecon(context); goto out; } -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri May 16 11:58:27 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 May 2008 07:58:27 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210939058.28282.183.camel@moss-spartans.epoch.ncsc.mil> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> <1210883635.3061.46.camel@localhost.localdomain> <1210884438.28282.167.camel@moss-spartans.epoch.ncsc.mil> <1210886427.3061.67.camel@localhost.localdomain> <1210939058.28282.183.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <482D76E3.2050305@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephen Smalley wrote: | On Thu, 2008-05-15 at 17:20 -0400, Eric Paris wrote: |> On Thu, 2008-05-15 at 16:47 -0400, Stephen Smalley wrote: |>> On Thu, 2008-05-15 at 16:33 -0400, Eric Paris wrote: |>>> #4 At the end of the rpm transaction when everything is installed it |>>> calls restorecon and I get one for (I assume) every file almost all of |>>> which look like: |>>> |>>> /sbin/restorecon reset /srv context system_u:object_r:var_t:s0->system_u:object_r:var_t:s0 |>>> |>>> Notice nothing changed? Again I assume its my hack of a /selinux which |>>> causes it and I'll try to run down why, but maybe someone else sees that |>>> quickly. |>> That suggests it is being called with the -f (force) flag from |>> e.g. /sbin/fixfiles. selinux-policy.spec does a |>> fixfiles -C file_contexts.pre restore |>> |>> fixfiles -C does a diff between the old and new file contexts |>> configurations and applies restorecon to the result. There is some |>> serious magic in there, and it is all Dan's fault ;) |> ok, in the livecd-creator kickstart.py I see |> |> if os.path.exists(self.path("/sbin/restorecon")): |> self.call(["/sbin/restorecon", "-l", "-v", "-r", "-F", "-e", "/proc", "-e", "/sys", "-e", "/dev", "-e", "/selinux", "/"]) |> |> So there is our -F. Is there a way to get it to fix "user" without |> getting it to fix "things that aren't wrong" | | I think we should change setfiles/restorecon to just not do that even | with -F. IIRC, changing it to always invoke setfilecon even if the | contexts were the same was motivated by the problem we used to have | where the in-core label and the on-disk xattr could get out of sync. | | Patch below. Note that restorecon is just a link to setfiles that | presents a different default user interface and behaviors (ever since I | coalesced them). | | Index: policycoreutils/setfiles/setfiles.c | =================================================================== | --- policycoreutils/setfiles/setfiles.c (revision 2879) | +++ policycoreutils/setfiles/setfiles.c (working copy) | @@ -495,7 +495,7 @@ | * specification. | */ | if ((strcmp(newcon, "<>") == 0) || | - (context && (strcmp(context, newcon) == 0) && !force)) { | + (context && (strcmp(context, newcon) == 0))) { | freecon(context); | goto out; | } | | Same patch almost simultaneous, it must be right. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgtduMACgkQrlYvE4MpobMn1gCg341q6CJQ2yDq7JPCcYVJn9ZQ /fcAn3I/rokQZcqP/S/ilO4fLFkTsRNB =ioXI -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri May 16 12:02:08 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 May 2008 08:02:08 -0400 Subject: lost gnome In-Reply-To: <357842.95897.qm@web52605.mail.re2.yahoo.com> References: <357842.95897.qm@web52605.mail.re2.yahoo.com> Message-ID: <482D77C0.5080004@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Olivares wrote: | --- "Clyde E. Kunkel" wrote: | |> Antonio Olivares wrote: |>> Dear all, |>> |>> After changing the repos to point back to rawhide. |> I |>> have lost gnome in the process. I cannot log into |>> gnome. Thankfully KDE does work :), However, I |> would |>> like to have both functioning if possible. |>> |>> I'll attach a text file which shows messages that |>> could be useful to fix this issue. |>> |>> Regards, |>> |>> Antonio |>> |>> |>> |>> |> Earlier thread discussed this and response from Tom |> London: |> |> "Reverting GConf2 packages "fixed this for me". (I |> noticed some new |> SELinux messages that may be causing this, and |> reported to dwalsh |> already.) |> |> I had other issues that reverting gnome-session and |> gnome-settings-daemon fixed..... |> |> tom" |> -- |> --------------------------------- |> Regards, |> |> Old Fart |> |> -- |> fedora-test-list mailing list |> fedora-test-list at redhat.com |> To unsubscribe: |> | https://www.redhat.com/mailman/listinfo/fedora-test-list | | Thank you very much Clyde, | | That is it! Selinux has its hands on it: | I'll run KDE in the meantime, the cure looks a bit | complicated :( | | | Part of dmesg: | | [olivares at localhost ~]$ uname -a | Linux localhost 2.6.25.2-5.fc10.i686 #1 SMP Wed May 7 | 18:06:55 EDT 2008 i686 athlon i386 GNU/Linux | | [olivares at localhost ~]$ cat /etc/fedora-release | | Fedora release 9.90 (Rawhide) | | [olivares at localhost ~]$ dmesg | | Initializing cgroup subsys cpuset | | Initializing cgroup subsys cpu | | Linux version 2.6.25.2-5.fc10.i686 (mockbuild@) (gcc | version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 | SMP Wed May 7 18:06:55 EDT 2008 | | BIOS-provided physical RAM map: | | BIOS-e820: 0000000000000000 - 000000000009fc00 | (usable) | BIOS-e820: 000000000009fc00 - 00000000000a0000 | (reserved) | BIOS-e820: 00000000000e0000 - 0000000000100000 | (reserved) | BIOS-e820: 0000000000100000 - 000000002ffd0000 | (usable) | BIOS-e820: 000000002ffd0000 - 000000002ffdf000 (ACPI | data) | BIOS-e820: 000000002ffdf000 - 0000000030000000 (ACPI | NVS) | BIOS-e820: 00000000fec00000 - 00000000fec01000 | (reserved) | BIOS-e820: 00000000fee00000 - 00000000fee01000 | (reserved) | BIOS-e820: 00000000ff7c0000 - 0000000100000000 | (reserved) | ***** removed to show relevant parts ***** | SELinux: initialized (dev rpc_pipefs, type | rpc_pipefs), uses genfs_contexts | SELinux: initialized (dev autofs, type autofs), uses | genfs_contexts | SELinux: initialized (dev autofs, type autofs), uses | genfs_contexts | SELinux: initialized (dev autofs, type autofs), uses | genfs_contexts | Bluetooth: Core ver 2.11 | | NET: Registered protocol family 31 | | Bluetooth: HCI device and connection manager | initialized | Bluetooth: HCI socket layer initialized | | Bluetooth: L2CAP ver 2.9 | | Bluetooth: L2CAP socket layer initialized | | Bluetooth: RFCOMM socket layer initialized | | Bluetooth: RFCOMM TTY layer initialized | | Bluetooth: RFCOMM ver 1.8 | | Bluetooth: BNEP (Ethernet Emulation) ver 1.2 | | Bluetooth: BNEP filters: protocol multicast | | Bridge firewalling registered | | pan0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM | feature. | serial8250: too much work for irq18 | | serial8250: too much work for irq18 | | type=1400 audit(1210890146.560:4): avc: denied { | execute } for pid=2337 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890146.610:5): avc: denied { | execute } for pid=2339 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890147.848:6): avc: denied { | execute } for pid=2350 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890147.850:7): avc: denied { | execute } for pid=2352 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890147.865:8): avc: denied { | execute } for pid=2354 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890147.877:9): avc: denied { | execute } for pid=2356 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890148.582:10): avc: denied { | execute } for pid=2363 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890148.632:11): avc: denied { | execute } for pid=2365 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890148.650:12): avc: denied { | execute } for pid=2367 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890148.662:13): avc: denied { | execute } for pid=2369 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | printk: 196 messages suppressed. | | type=1400 audit(1210890151.618:79): avc: denied { | execute } for pid=2505 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | printk: 57 messages suppressed. | | type=1400 audit(1210890163.178:99): avc: denied { | execute } for pid=2556 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890163.214:100): avc: denied { | execute } for pid=2560 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | printk: 33 messages suppressed. | | gnome-session[2618]: segfault at 0 ip 00d36187 sp | bfc554a4 error 4 in | libglib-2.0.so.0.1600.3[cdc000+e0000] | | type=1400 audit(1210890178.407:112): avc: denied { | execute } for pid=2831 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890178.421:113): avc: denied { | execute } for pid=2834 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | printk: 250 messages suppressed. | | type=1400 audit(1210890187.515:197): avc: denied { | execute } for pid=3058 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890187.562:198): avc: denied { | execute } for pid=3063 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | printk: 33 messages suppressed. | | type=1400 audit(1210890240.289:210): avc: denied { | read } for pid=3496 comm="nm-system-setti" | name="PolicyKit.reload" dev=dm-0 ino=3244718 | scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:system_crond_var_lib_t:s0 | tclass=file | | type=1400 audit(1210890240.432:211): avc: denied { | getattr } for pid=3496 comm="nm-system-setti" | path="/dev/root" dev=tmpfs ino=318 | scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:fixed_disk_device_t:s0 | tclass=blk_file | | type=1400 audit(1210890242.221:212): avc: denied { | execstack } for pid=3506 comm="nspluginscan" | scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 | tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 | tclass=process | klauncher[3388]: segfault at 8048814 ip 001c8da8 sp | bffe22c0 error 7 in libX11.so.6.2.0[1b3000+fd000] | | nepomukservices[3465] general protection ip:448adef | sp:bfdc34f0 error:0 in | libnepomuk.so.4.1.0[4460000+6d000] | | type=1400 audit(1210890272.055:213): avc: denied { | execute } for pid=3593 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890272.069:214): avc: denied { | execute } for pid=3596 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | | type=1400 audit(1210890272.314:215): avc: denied { | execute } for pid=3622 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | type=1400 audit(1210890272.317:216): avc: denied { | execute } for pid=3624 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | type=1400 audit(1210890272.319:217): avc: denied { | execute } for pid=3626 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | type=1400 audit(1210890272.321:218): avc: denied { | execute } for pid=3628 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | type=1400 audit(1210890272.396:219): avc: denied { | execute } for pid=3637 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | type=1400 audit(1210890272.411:220): avc: denied { | execute } for pid=3640 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | printk: 226 messages suppressed. | type=1400 audit(1210890280.758:296): avc: denied { | execute } for pid=3818 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | type=1400 audit(1210890280.793:297): avc: denied { | execute } for pid=3822 comm="dbus-daemon" | name="gconfd-2" dev=dm-0 ino=32542974 | scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 | tcontext=system_u:object_r:gconfd_exec_t:s0 | tclass=file | printk: 36 messages suppressed. | type=1400 audit(1210890308.692:310): avc: denied { | execstack } for pid=4157 comm="nspluginscan" | scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 | tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 | tclass=process | [olivares at localhost ~]$ | | ccd: to fedora-selinux-list at redhat.com | | Regards, | | Antonio | | | | | -- | fedora-selinux-list mailing list | fedora-selinux-list at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-selinux-list Antonio you are in rawhide correct? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgtd78ACgkQrlYvE4MpobOXiACg4pBprKvjo2JTb8Go39L11rbY HegAoKEGKbhQ4DXciILjUUS3T3E2Ms5o =PyvB -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri May 16 12:04:33 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 16 May 2008 08:04:33 -0400 Subject: tools that present a graphical abstraction of a SELinux policy In-Reply-To: References: Message-ID: <482D7851.4010207@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christian Lange wrote: | Hi, | | I'm a student of the university of Rostock, In the scope of my master | thesis I want to get an | overview about existing graphical tools (commercial or free), | abstracting from underlying SELinux | details, helping users to define and maintain SELinux policies (TE & | MCS). So far, I found the | following tools: | - SLIDE | - VIRGIL | - Tresys Brickwall Security Suite | They only use masks for data input and don't abstract from the policy | to show a graph. | | My questions are: | - Is there any tool that creates a abstract view of a policy as a | graph or something like that? | - Is there any demand for such a tool? | | Thanks in advance | | -- | fedora-selinux-list mailing list | fedora-selinux-list at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-selinux-list I have no idea, What do you think the graph would show? Please explain your ideas. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkgteFEACgkQrlYvE4MpobM3LQCgtn9wg0GYMWVBx89s6gBhaG1Z vL4AnijlN6lHsKE0/BhYkZx9L+1j1Fnc =065Y -----END PGP SIGNATURE----- From sds at tycho.nsa.gov Fri May 16 12:10:57 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 16 May 2008 08:10:57 -0400 Subject: livecd-creator + selinux In-Reply-To: <482CB989.803@vmware.com> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> <482CB989.803@vmware.com> Message-ID: <1210939857.28282.196.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-05-15 at 15:30 -0700, Douglas McClendon wrote: > Stephen Smalley wrote: > > On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote: > >> 3) When booting I get 3 messages that say: > >> inode_doinit_with_dentry: no dentry for dev=dm-0 ino=8345 > >> The 3 inodes in question correspond to > >> /etc/udev > >> /etc/udev/rules.d > >> /etc/udev/rules.d/50-udev-default.rules > > > > Happens when SELinux is setting up pre-existing inodes upon initial > > policy load and it cannot find a dentry for the inode and thus cannot > > invoke the ->getxattr method on it. Likely harmless. When/if the > > files are subsequently looked up, the inodes should get set up at that > > time upon the d_instantiate/d_splice_alias. > > I've seen these messages forever, though didn't realize till now that > they were an selinux related issue. If they are truly harmless, can > someone remove the code that spits out the message please? I'm ok with reducing them to KERN_DEBUG. They do represent a non-optimal aspect of the ->getxattr interface that we were hoping to resolve some day (requires passing a dentry even though it immediately extracts the inode and uses that for everything). The only thing really blocking us is CIFS reliance on pathname reconstruction ;) > FYI- note that what is going on with that file is that it is being > modified by the initramfs before policy is loaded- > > see do_live_from_base_loop in /usr/lib/livecd-creator/mayflower, i.e. > stuff like this- > > echo "KERNEL==\"hd[a-z]\", BUS==\"ide\", SYSFS{removable}==\"1\", > ATTRS{media}==\"cdrom\", PROGRAM=\"/lib/udev/vol_id -l %N\", > RESULT==\"\$CDLABEL\", SYMLINK+=\"live\"" >> > /sysroot/etc/udev/rules.d/50-udev* Ah, thanks - that makes sense. So the files get accessed before policy load, are left with the unlabeled SID for that period of time, but should get fixed up upon next lookup/d_instantiate. > > > >> no clues where this is coming from. I don't see it when I booted my > >> host system.... > >> > >> > >> > >> Anyway, at this point I want clues/help/suggestions on how to create my > >> hacked up /selinux inside the chroot. > > Out of curiosity, if someone feels like answering- are there any plans > for selinux to support chroots in the sense of policy and even > enabled/disabled being completely different between the host and the > chroot? Seems like "chroot /mnt/sysimage rpm " ought > to 'just work(tm)'. But maybe I'm expecting too much functionality from > a default fedora system. I've given that some thought, but it appears to be rather complex to support it, and it runs counter to our general goal of being able to specify and enforce security goals for the entire platform (which is the point of MAC). I was thinking of introducing per-process policy pointers that would initially all reference the same policy object, then provide an interface to "unshare" policy analogous to other forms of unshare(2) and clone(2), at which point a process could load a different policy that would only apply to itself and its descendants. However, that doesn't resolve how to handle objects, and it doesn't deal with accesses that cross the boundaries, especially as both processes (like rpm) and files (like the files installed into the chroot environment) will be accessible and accessed both from within the chroot and from without. In the end, I'm not sure it is worth it, and it certainly won't be trivial. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri May 16 12:14:49 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 16 May 2008 08:14:49 -0400 Subject: tools that present a graphical abstraction of a SELinux policy In-Reply-To: References: Message-ID: <1210940089.28282.201.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-05-16 at 08:28 +0200, Christian Lange wrote: > Hi, > > I'm a student of the university of Rostock, In the scope of my master > thesis I want to get an > overview about existing graphical tools (commercial or free), > abstracting from underlying SELinux > details, helping users to define and maintain SELinux policies (TE & > MCS). So far, I found the > following tools: > - SLIDE > - VIRGIL > - Tresys Brickwall Security Suite > They only use masks for data input and don't abstract from the policy > to show a graph. > > My questions are: > - Is there any tool that creates a abstract view of a policy as a > graph or something like that? > - Is there any demand for such a tool? Your question is better suited to the upstream selinux at tycho.nsa.gov mailing list than to this list, as it is not specific to Fedora. However, let me point you to this resource: http://selinuxproject.org/page/User_Resources#Tools In particular, the Cross Domain Solution Framework is graph-oriented, http://oss.tresys.com/projects/cdsframework -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri May 16 12:19:40 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 16 May 2008 08:19:40 -0400 Subject: spamc not working from procmail in Fedora 9 In-Reply-To: References: Message-ID: <1210940380.28282.206.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-05-16 at 10:10 +0200, Daniel Fazekas wrote: > SELinux appears to stop spamc from being called from procmail: > type=1401 audit(1210924808.115:14): security_compute_sid: invalid > context system_u:system_r:spamc_t:s0 for > scontext=system_u:system_r:procmail_t:s0 > tcontext=system_u:object_r:spamc_exec_t:s0 tclass=process Create a local policy module either via audit2allow or by hand to permit it. The rule in particular that is missing is "role system_r types spamc_t;". The audit2allow way: # grep spamc /var/log/audit/audit.log | audit2allow -M myspamc # semodule -i myspamc.pp The hand-written way: # cat myspamc.te policy_module(myspamc, 1.0) require { role system_r; type spamc_t; } role system_r types spamc_t; # make -f /usr/share/selinux/devel/Makefile myspamc.pp # semodule -i myspamc.pp > > procmail logs: > /usr/bin/spamc: /usr/bin/spamc: cannot execute binary file > procmail: Error while writing to "/usr/bin/spamc" > procmail: Rescue of unfiltered data succeeded > > In my .procmailrc I have this line: > INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc > > Used to work fine in previous releases of Fedora. > Is there anything I could set to allow this? > > I have already tried a full touch ./autorelabel && reboot, it didn't > help. > > SELinux is using > selinux-policy-targeted-3.3.1-42.fc9.noarch > selinux-policy-3.3.1-42.fc9.noarch > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri May 16 15:08:50 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 16 May 2008 11:08:50 -0400 Subject: Differences between openssh and pam_selinux In-Reply-To: <1210871514.20548.53.camel@vespa.frost.loc> References: <1210871514.20548.53.camel@vespa.frost.loc> Message-ID: <1210950530.28282.304.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-05-15 at 19:11 +0200, Tomas Mraz wrote: > There are some differences in how openssh and pam_selinux get the user's > context. As I want to replace part of the openssh's SELinux code with > pam_selinux I'd like to know which one is more correct. > > Here's the rough algorithm for both: > > OpenSSH > ======= > > 1. get selinux user & default level with getseuserbyname() > 2. obtain default ctx with get_default_context_with_level() > 3. obtain requested ctx for requested level with > get_default_context_with_level() > 4. set requested role to the requested ctx > 5. set type for the requested role to the requested ctx (obtained from > get_default_type(requested role)) > 6. copy the requested ctx and set the requested level in the copy > 7. compare the requested ctx with the copy - if not equal -> fail > 8. do the points 3. - 7. with the difference that the default level is > used instead of requested level > 9. do security_compute_av with CONTEXT__CONTAINS to check whether the > context from 7. is allowed for context from 8. if not allowed -> fail > 10. use the context from 7. as the user's context. > > pam_selinux > =========== > > 1. get selinux user & default level with getseuserbyname() > 2. use get_ordered_context_list_with_level() to obtain list of context > for the user & level, as the default user's context is taken the first > one on the list > 3. if this fails: > 3a. the level and role is obtained from user and combined into a > context with default type for the role and the selinux user > 3b. this ctx is checked with security_check_context() - if fails -> > fail else we have the user's context -> end > 4. if 2. succeeds and module is configured to allow asking user for > role/level then user is asked for requested role and level > 5. the requested ctx starts as copy of the default ctx > 6. the requested role is set to requested ctx, requested level is set > and the default type (get_default_type()) for the requested role is set > 7. the requested ctx is checked with security_check_context() - if fails > -> fail > 8. do security_compute_av with CONTEXT__CONTAINS to check whether the > context from 7. is allowed for default context if not allowed -> fail > 9. use the context from 7. as the user's context. > > So which one is correct if any? (cc'ing selinux at tycho.nsa.gov as this is an upstream issue as well) The logic has evolved or perhaps devolved over time (e.g. introduction of seusers as a further level of indirection between Linux users and SELinux users, introduction of support for requesting specific roles and levels), and we really ought to try to encapsulate more of it within a single libselinux helper function that can be used by all applications. As I recall, openssh had special logic introduced to preserve the desired LSPP behavior for labeled networking (ensuring that the client's level is preserved across the entire session as otherwise data would be downgraded from the server to the client). That may explain the difference. In that scenario, as I recall, xinetd would launch sshd in the level obtained for the client via getpeercon. Abstractly, we want the final context (user:role:type:level) that is used to: 1) use the SELinux user obtained from getseuserbyname(), 2) have valid user-role, role-type, and user-level pairs (this will in fact be checked by the kernel upon attempted use to setexeccon(), but we'd rather catch it early via security_check_context), 3) be bounded (via CONTEXT__CONTAINS check) by the MLS level or range for the Linux user obtained from getseuserbyname() as this may be a subset of the range authorized for the SELinux user, and 4) be bounded by the MLS range of the caller (this is especially for the labeled networking case, but is generally true and could be useful even for local logins e.g. to bind a specific range to one tty and a different range to another). get_default_context* internally just uses get_ordered_context* and then selects the first item, so there is no difference between using them if you are only selecting the first item. The only reason to use get_ordered_context* is if you want to present a list of options to the user for selection, which pam_selinux did at one time. Possibly we want a libselinux interface that takes the Linux username, an optional requested role and an optional requested level argument, and just returns an entire context that meets the criteria above. getseuserbyname() can be used to obtain the default values of the SELinux user and the range/level for the context. If no role was requested, it could be obtained via get_default_context although it would be nice to just provide a simpler mechanism specialized for that purpose, e.g. a policy config file that maps SELinux users to default roles (Chris cc'd). The type could always default to get_default_type() for the role in that case, thereby eliminating any chance of incorrectly getting any program types there. Thoughts? -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri May 16 15:25:15 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 16 May 2008 11:25:15 -0400 Subject: Differences between openssh and pam_selinux In-Reply-To: <1210950530.28282.304.camel@moss-spartans.epoch.ncsc.mil> References: <1210871514.20548.53.camel@vespa.frost.loc> <1210950530.28282.304.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210951515.28282.309.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-05-16 at 11:08 -0400, Stephen Smalley wrote: > On Thu, 2008-05-15 at 19:11 +0200, Tomas Mraz wrote: > > There are some differences in how openssh and pam_selinux get the user's > > context. As I want to replace part of the openssh's SELinux code with > > pam_selinux I'd like to know which one is more correct. > > > > Here's the rough algorithm for both: > > > > OpenSSH > > ======= > > > > 1. get selinux user & default level with getseuserbyname() > > 2. obtain default ctx with get_default_context_with_level() > > 3. obtain requested ctx for requested level with > > get_default_context_with_level() > > 4. set requested role to the requested ctx > > 5. set type for the requested role to the requested ctx (obtained from > > get_default_type(requested role)) > > 6. copy the requested ctx and set the requested level in the copy > > 7. compare the requested ctx with the copy - if not equal -> fail > > 8. do the points 3. - 7. with the difference that the default level is > > used instead of requested level > > 9. do security_compute_av with CONTEXT__CONTAINS to check whether the > > context from 7. is allowed for context from 8. if not allowed -> fail > > 10. use the context from 7. as the user's context. > > > > pam_selinux > > =========== > > > > 1. get selinux user & default level with getseuserbyname() > > 2. use get_ordered_context_list_with_level() to obtain list of context > > for the user & level, as the default user's context is taken the first > > one on the list > > 3. if this fails: > > 3a. the level and role is obtained from user and combined into a > > context with default type for the role and the selinux user > > 3b. this ctx is checked with security_check_context() - if fails -> > > fail else we have the user's context -> end > > 4. if 2. succeeds and module is configured to allow asking user for > > role/level then user is asked for requested role and level > > 5. the requested ctx starts as copy of the default ctx > > 6. the requested role is set to requested ctx, requested level is set > > and the default type (get_default_type()) for the requested role is set > > 7. the requested ctx is checked with security_check_context() - if fails > > -> fail > > 8. do security_compute_av with CONTEXT__CONTAINS to check whether the > > context from 7. is allowed for default context if not allowed -> fail > > 9. use the context from 7. as the user's context. > > > > So which one is correct if any? > > (cc'ing selinux at tycho.nsa.gov as this is an upstream issue as well) > > The logic has evolved or perhaps devolved over time (e.g. introduction > of seusers as a further level of indirection between Linux users and > SELinux users, introduction of support for requesting specific roles and > levels), and we really ought to try to encapsulate more of it within a > single libselinux helper function that can be used by all applications. > > As I recall, openssh had special logic introduced to preserve the > desired LSPP behavior for labeled networking (ensuring that the client's > level is preserved across the entire session as otherwise data would be > downgraded from the server to the client). That may explain the > difference. In that scenario, as I recall, xinetd would launch sshd in > the level obtained for the client via getpeercon. > > Abstractly, we want the final context (user:role:type:level) that is > used to: > 1) use the SELinux user obtained from getseuserbyname(), > 2) have valid user-role, role-type, and user-level pairs (this will in > fact be checked by the kernel upon attempted use to setexeccon(), but > we'd rather catch it early via security_check_context), > 3) be bounded (via CONTEXT__CONTAINS check) by the MLS level or range > for the Linux user obtained from getseuserbyname() as this may be a > subset of the range authorized for the SELinux user, and > 4) be bounded by the MLS range of the caller (this is especially for the > labeled networking case, but is generally true and could be useful even > for local logins e.g. to bind a specific range to one tty and a > different range to another). > > get_default_context* internally just uses get_ordered_context* and then > selects the first item, so there is no difference between using them if > you are only selecting the first item. The only reason to use > get_ordered_context* is if you want to present a list of options to the > user for selection, which pam_selinux did at one time. > > Possibly we want a libselinux interface that takes the Linux username, > an optional requested role and an optional requested level argument, and > just returns an entire context that meets the criteria above. > getseuserbyname() can be used to obtain the default values of the > SELinux user and the range/level for the context. If no role was > requested, it could be obtained via get_default_context although it > would be nice to just provide a simpler mechanism specialized for that > purpose, e.g. a policy config file that maps SELinux users to default > roles (Chris cc'd). The type could always default to get_default_type() > for the role in that case, thereby eliminating any chance of incorrectly > getting any program types there. Ah, a limitation of the "simpler" approach described above is that it doesn't allow the context-sensitive selection of default roles and types that is presently supported by get_default_context*. For example, at present, we can make root's default login role sysadm_r if on the console but staff_r if via gdm or sshd (based on the context of the caller/login process), and we can make the default type vary depending on the caller as well, such that we could use the derived domains for cron jobs. So perhaps in the short term we'll need to keep using get_default_context* internally but we might be able to replace it in the future. -- Stephen Smalley National Security Agency From eparis at redhat.com Fri May 16 18:25:39 2008 From: eparis at redhat.com (Eric Paris) Date: Fri, 16 May 2008 14:25:39 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1210962339.2717.8.camel@localhost.localdomain> On Thu, 2008-05-15 at 15:30 -0400, Stephen Smalley wrote: > On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote: > > So I'm still stumbling along in the dark trying to get livecd-creator to > > build me a nice new F10 image inside an F10 host. I've actually got an > > image that built and runs, but not without its issues. > > > > my kickstart file has: > > auth --enableshadow --enablemd5 > > rootpw redhat > > > > but the livecd always has x for the password in /etc/password and * for > > the password in /etc/shadow. No ideas here I must admit. I'm highly > > doubtful its selinux since it happens in permissive and enforcing. I > > have just been booting into single user, calling passwd, init 3, and > > logging in to play around in my live image.... > > No ideas here - hopefully the livecd folks can help you with that one. turns out it was an selinux issue. passwd does 2 different checks to see if selinux is going to allow it. Dan, what were you thinking? I see your name written all of this. Anyway selinux_check_passwd_access() calls security_getenforce() and allows things if it gets 0. Since security_getenforce can't open /selinux/enforce (it doesn't exist) it returned -1, we then proceeded to try to do the access check which obviously also bombed (do to another ENOENT) and passwd gave us that useless "Only root can do that" message. First try was to change selinux_check_passwd_access() to return a success if security_getenforce() < 1. Which then turned up that passwd has its own secondary check (WTF?) called check_selinux_access() which basically did the same thing as the libselinux function. I changed it to use < 1 and finally got passwd to run inside my chroot. I think the best solution here is to explicitly set a /selinux/enforce = 0 in the chroot rather than hack everything that could possibly call security_getenforce() what do others think? -Eric From sds at tycho.nsa.gov Fri May 16 18:41:59 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 16 May 2008 14:41:59 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210962339.2717.8.camel@localhost.localdomain> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> <1210962339.2717.8.camel@localhost.localdomain> Message-ID: <1210963319.28282.352.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-05-16 at 14:25 -0400, Eric Paris wrote: > On Thu, 2008-05-15 at 15:30 -0400, Stephen Smalley wrote: > > On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote: > > > So I'm still stumbling along in the dark trying to get livecd-creator to > > > build me a nice new F10 image inside an F10 host. I've actually got an > > > image that built and runs, but not without its issues. > > > > > > my kickstart file has: > > > auth --enableshadow --enablemd5 > > > rootpw redhat > > > > > > but the livecd always has x for the password in /etc/password and * for > > > the password in /etc/shadow. No ideas here I must admit. I'm highly > > > doubtful its selinux since it happens in permissive and enforcing. I > > > have just been booting into single user, calling passwd, init 3, and > > > logging in to play around in my live image.... > > > > No ideas here - hopefully the livecd folks can help you with that one. > > turns out it was an selinux issue. > > passwd does 2 different checks to see if selinux is going to allow it. > Dan, what were you thinking? I see your name written all of this. > > Anyway selinux_check_passwd_access() calls security_getenforce() and > allows things if it gets 0. Since security_getenforce can't > open /selinux/enforce (it doesn't exist) it returned -1, we then > proceeded to try to do the access check which obviously also bombed (do > to another ENOENT) and passwd gave us that useless "Only root can do > that" message. > > First try was to change selinux_check_passwd_access() to return a > success if security_getenforce() < 1. Which then turned up that passwd > has its own secondary check (WTF?) called check_selinux_access() which > basically did the same thing as the libselinux function. I changed it > to use < 1 and finally got passwd to run inside my chroot. > > I think the best solution here is to explicitly set a /selinux/enforce = > 0 in the chroot rather than hack everything that could possibly call > security_getenforce() what do others think? Given the approach being taken here, that is likely harmless, as all we care about within the chroot is that SELinux is seen as enabled (which is independent of enforce) and that files are labeled properly. -- Stephen Smalley National Security Agency From eparis at redhat.com Fri May 16 19:19:09 2008 From: eparis at redhat.com (Eric Paris) Date: Fri, 16 May 2008 15:19:09 -0400 Subject: livecd-creator and selinux, status at the end of week 1 Message-ID: <1210965549.2717.23.camel@localhost.localdomain> I've spent pretty much all week flailing around try to get livecd-creator working with selinux enforcing with F10 as both the host and the image. Next week begins the journey of working on making old composes work on F10. Where do I stand? Well, it seems to work! I booted an image and logged in. Changes I've made so far (doesn't look like a whole lot for basically a week of work....) policycoreutils got some updates to allow users to be created in the chroot (already built and in koji) and to make relabeling a little better. libselinux has no changes with my current approach. I do not want rpm running inside the chroot to transition to rpm_t, nor do I want scriptlets to run as rpm_script_t as then those scriptlets can cause transitions to things like depmod_t which isn't going to have permissions necessary to run with the possibly screwy labels inside the chroot. I added one rule to policy to allow hal to respond back to chroot allow hald_t unconfined_notrans_t:dbus send_msg; Create a fake /selinux inside the chroot it contains: mls -> copy from host poliyver -> copy from host enforce -> 0 load -> /dev/null This means that from the point of view of the inside of the chroot selinux is "on" but not enforcing. The not enforcing part is important because some programs (passwd for example) try to determine if selinux is going to permit something before it actually tries it. If passwd realizes that selinux is enforcing but then it doesn't have a real /selinux to make those decisions it gets mad. So I'm lieing to the chroot. Changes to livecd-creator: diff -Naupr imgcreate/creator.py imgcreate.new/creator.py --- imgcreate/creator.py 2008-05-06 12:16:08.000000000 -0400 +++ imgcreate.new/creator.py 2008-05-16 13:01:05.000000000 -0400 @@ -22,6 +22,7 @@ import stat import sys import tempfile import shutil +import selinux import yum import rpm @@ -427,7 +428,7 @@ class ImageCreator(object): self._mount_instroot(base_on) - for d in ("/dev/pts", "/etc", "/boot", "/var/log", "/var/cache/yum"): + for d in ("/dev/pts", "/etc", "/boot", "/var/log", "/var/cache/yum", "/sys", "/proc"): makedirs(self._instroot + d) cachesrc = cachedir or (self.__builddir + "/yum-cache") @@ -439,10 +440,6 @@ class ImageCreator(object): (cachesrc, "/var/cache/yum")]: self.__bindmounts.append(BindChrootMount(f, self._instroot, dest)) - # /selinux should only be mounted if selinux is enabled (enforcing or permissive) - if kickstart.selinux_enabled(self.ks): - self.__bindmounts.append(BindChrootMount("/selinux", self._instroot, None)) - # Create minimum /dev origumask = os.umask(0000) devices = [('null', 1, 3, 0666), @@ -460,6 +457,20 @@ class ImageCreator(object): os.symlink('/proc/self/fd/2', self._instroot + "/dev/stderr") os.umask(origumask) + # selinux whoo hooo + if kickstart.selinux_enabled(self.ks): + makedirs(self._instroot + "/selinux") + # this should actually create our new fake /selinux, not bind from the host, though i haven't decided how + self.__bindmounts.append(BindChrootMount("/selinux1", self._instroot, "/selinux")) + + # label the fs like it is a root before the bind mounting + cmd = "/sbin/setfiles -F -r %s %s %s" % (self._instroot, selinux.selinux_file_context_path(), self._instroot) + os.system(cmd) + # these dumb things don't get magically fixed, so make the user generic + for f in ["/proc", "/sys", "/selinux"]: + cmd = "chcon -u system_u %s" % (self._instroot + f) + os.system(cmd) + self._do_bindmounts() os.symlink("../proc/mounts", self._instroot + "/etc/mtab") diff -Naupr imgcreate/kickstart.py imgcreate.new/kickstart.py --- imgcreate/kickstart.py 2008-05-06 12:16:08.000000000 -0400 +++ imgcreate.new/kickstart.py 2008-05-15 10:10:40.000000000 -0400 @@ -372,11 +372,11 @@ class SelinuxConfig(KickstartConfig): if ksselinux.selinux == ksconstants.SELINUX_DISABLED: return - if not os.path.exists(self.path("/sbin/restorecon")): + if os.path.exists(self.path("/sbin/restorecon")): + self.call(["/sbin/restorecon", "-l", "-v", "-r", "-F", "-e", "/proc", "-e", "/sys", "-e", "/dev", "-e", "/selinux", "/"]) + else: return - self.call(["/sbin/restorecon", "-l", "-v", "-r", "/"]) - def apply(self, ksselinux): if os.path.exists(self.path("/usr/sbin/lokkit")): args = ["/usr/sbin/lokkit", "-f", "--quiet", "--nostart"] From eparis at redhat.com Mon May 19 13:34:46 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 19 May 2008 09:34:46 -0400 Subject: livecd-creator and selinux, status at the end of week 1 In-Reply-To: <48317C8C.7050606@redhat.com> References: <1210965549.2717.23.camel@localhost.localdomain> <48317C8C.7050606@redhat.com> Message-ID: <1211204086.3013.6.camel@localhost.localdomain> On Mon, 2008-05-19 at 09:11 -0400, David Huff wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Eric Paris wrote: > | I've spent pretty much all week flailing around try to get > | livecd-creator working with selinux enforcing with F10 as both the host > | and the image. Next week begins the journey of working on making old > | composes work on F10. Where do I stand? Well, it seems to work! I > | booted an image and logged in. > | > > > I have seen similar issues with the appliance-tools Im working on > (thincrust.net). On thing I have noticed is that kickstart.py only > likes crypted passwds, so make sure you use the --iscrytped option in > the ks file. > > I have also noticed another problem, if you set selinux disabled via the > kickstart and try to set no root passwd, by excluding a rootpw > line in the ks, you get an error similar too: > > "only root can do that" > > I think this is due to selinux context on the host you are > building the image on. I saw this running a F9 client on a F9 host, > from your post on Friday, I will try generating a rwahide image on a > rawhide host and see if I have similar results. If you wouldn't mind opening a BZ, for now lets open it against libselinux assign it to me and let me know all of the problems you have run into involving passwd. I think I understand all of that cruft now. -Eric From eparis at redhat.com Mon May 19 19:14:03 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 19 May 2008 15:14:03 -0400 Subject: livecd-creator and selinux, status at the end of week 1 In-Reply-To: <1210965549.2717.23.camel@localhost.localdomain> References: <1210965549.2717.23.camel@localhost.localdomain> Message-ID: <1211224443.2728.2.camel@localhost.localdomain> On Fri, 2008-05-16 at 15:19 -0400, Eric Paris wrote: > I've spent pretty much all week flailing around try to get > livecd-creator working with selinux enforcing with F10 as both the host > and the image. Next week begins the journey of working on making old > composes work on F10. Where do I stand? Well, it seems to work! I > booted an image and logged in. Today I tried flipped my repos to point at F7 and tried to build. Didn't see any selinux messages but crap still hit the fan on boot (eventual kernel panic complaining about no root and killing init) Anyway, I also decided to see what would happen if I flipped my kickstart file to selinux --disabled while leaving the system enforcing. Sorta boom. Installing selinux-policy-targeted got really pissed off: libsepol.policydb_write: Discarding booleans and conditional rules libsepol.policydb_write: Discarding booleans and conditional rules libsepol.context_read_and_validate: invalid security context libsepol.policydb_to_image: new policy image is invalid libsepol.policydb_to_image: could not create policy image /usr/sbin/load_policy: Can't load policy: No such file or directory libsemanage.semanage_reload_policy: load_policy returned error code 2. libsemanage.semanage_install_active: Could not copy /etc/selinux/targeted/modules/active/policy.kern to /etc/selinux/targeted/policy/policy.21. But something tells me its still going to work just fine once the build finishes. Anyway. -Eric From sds at tycho.nsa.gov Mon May 19 19:30:38 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 19 May 2008 15:30:38 -0400 Subject: livecd-creator and selinux, status at the end of week 1 In-Reply-To: <1211224443.2728.2.camel@localhost.localdomain> References: <1210965549.2717.23.camel@localhost.localdomain> <1211224443.2728.2.camel@localhost.localdomain> Message-ID: <1211225438.7486.69.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-05-19 at 15:14 -0400, Eric Paris wrote: > On Fri, 2008-05-16 at 15:19 -0400, Eric Paris wrote: > > I've spent pretty much all week flailing around try to get > > livecd-creator working with selinux enforcing with F10 as both the host > > and the image. Next week begins the journey of working on making old > > composes work on F10. Where do I stand? Well, it seems to work! I > > booted an image and logged in. > > Today I tried flipped my repos to point at F7 and tried to build. > Didn't see any selinux messages but crap still hit the fan on boot > (eventual kernel panic complaining about no root and killing init) So the interesting question there is whether the image was missing files or just mislabeled? > Anyway, I also decided to see what would happen if I flipped my > kickstart file to selinux --disabled while leaving the system enforcing. > Sorta boom. Installing selinux-policy-targeted got really pissed off: > > libsepol.policydb_write: Discarding booleans and conditional rules > libsepol.policydb_write: Discarding booleans and conditional rules > libsepol.context_read_and_validate: invalid security context > libsepol.policydb_to_image: new policy image is invalid > libsepol.policydb_to_image: could not create policy image > /usr/sbin/load_policy: Can't load policy: No such file or directory > libsemanage.semanage_reload_policy: load_policy returned error code 2. > libsemanage.semanage_install_active: Could not > copy /etc/selinux/targeted/modules/active/policy.kern > to /etc/selinux/targeted/policy/policy.21. If you are going to build a selinux disabled image, then I assume you'd want to fake the chroot into seeing SELinux as disabled too so that it doesn't try to do things like load policy (as above). Which would mean bind mounting a file over /proc/filesystems in the chroot to obscure the presence of selinuxfs. > But something tells me its still going to work just fine once the build > finishes. Anyway. -- Stephen Smalley National Security Agency From eparis at redhat.com Mon May 19 19:41:41 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 19 May 2008 15:41:41 -0400 Subject: livecd-creator and selinux, status at the end of week 1 In-Reply-To: <1211225438.7486.69.camel@moss-spartans.epoch.ncsc.mil> References: <1210965549.2717.23.camel@localhost.localdomain> <1211224443.2728.2.camel@localhost.localdomain> <1211225438.7486.69.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1211226101.2728.4.camel@localhost.localdomain> On Mon, 2008-05-19 at 15:30 -0400, Stephen Smalley wrote: > On Mon, 2008-05-19 at 15:14 -0400, Eric Paris wrote: > > On Fri, 2008-05-16 at 15:19 -0400, Eric Paris wrote: > > > I've spent pretty much all week flailing around try to get > > > livecd-creator working with selinux enforcing with F10 as both the host > > > and the image. Next week begins the journey of working on making old > > > composes work on F10. Where do I stand? Well, it seems to work! I > > > booted an image and logged in. > > > > Today I tried flipped my repos to point at F7 and tried to build. > > Didn't see any selinux messages but crap still hit the fan on boot > > (eventual kernel panic complaining about no root and killing init) > > So the interesting question there is whether the image was missing files > or just mislabeled? Well in the F8 example kickstart I see this bit of craziness: # make the initrd we care about rm -f /boot/initrd*.img cp /etc/sysconfig/mkinitrd /etc/mayflower.conf ver=`ls /boot/vmlinuz* |head -n 1 |sed -e 's;/boot/vmlinuz-;;'` /usr/lib/livecd-creator/mayflower -f /boot/initrd-$ver.img $ver rm -f /etc/mayflower.conf which leads me to believe F7 probably needs something similar that I don't have with my basically blank kickstart file. -Eric From dwalsh at redhat.com Mon May 19 23:07:28 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 19 May 2008 19:07:28 -0400 Subject: livecd-creator + selinux In-Reply-To: <1210962339.2717.8.camel@localhost.localdomain> References: <1210873808.3061.38.camel@localhost.localdomain> <1210879839.28282.145.camel@moss-spartans.epoch.ncsc.mil> <1210962339.2717.8.camel@localhost.localdomain> Message-ID: <48320830.4090208@redhat.com> Eric Paris wrote: > On Thu, 2008-05-15 at 15:30 -0400, Stephen Smalley wrote: >> On Thu, 2008-05-15 at 13:50 -0400, Eric Paris wrote: >>> So I'm still stumbling along in the dark trying to get livecd-creator to >>> build me a nice new F10 image inside an F10 host. I've actually got an >>> image that built and runs, but not without its issues. >>> >>> my kickstart file has: >>> auth --enableshadow --enablemd5 >>> rootpw redhat >>> >>> but the livecd always has x for the password in /etc/password and * for >>> the password in /etc/shadow. No ideas here I must admit. I'm highly >>> doubtful its selinux since it happens in permissive and enforcing. I >>> have just been booting into single user, calling passwd, init 3, and >>> logging in to play around in my live image.... >> No ideas here - hopefully the livecd folks can help you with that one. > > turns out it was an selinux issue. > > passwd does 2 different checks to see if selinux is going to allow it. > Dan, what were you thinking? I see your name written all of this. > > Anyway selinux_check_passwd_access() calls security_getenforce() and > allows things if it gets 0. Since security_getenforce can't > open /selinux/enforce (it doesn't exist) it returned -1, we then > proceeded to try to do the access check which obviously also bombed (do > to another ENOENT) and passwd gave us that useless "Only root can do > that" message. > > First try was to change selinux_check_passwd_access() to return a > success if security_getenforce() < 1. Which then turned up that passwd > has its own secondary check (WTF?) called check_selinux_access() which > basically did the same thing as the libselinux function. I changed it > to use < 1 and finally got passwd to run inside my chroot. > > I think the best solution here is to explicitly set a /selinux/enforce = > 0 in the chroot rather than hack everything that could possibly call > security_getenforce() what do others think? > > -Eric > Well the code was written 100 years ago or it feels that way anyways. I think the multiple checks are to see if you are root when changing a password and to check whether the domain executing passwd has the rootok passwd access. From eparis at redhat.com Tue May 20 19:12:00 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 20 May 2008 15:12:00 -0400 Subject: selinux + livecd-creator, May 20, 2008 Message-ID: <1211310720.2691.47.camel@localhost.localdomain> ***passwd: running a system with selinux enforcing/permissive (doesn't matter) and attempting to run livecd-creator with selinux --disabled results in passwd espoloding. passwd called is_selinux_enabled() which says yes since /proc/mounts has an selinuxfs and the passwd calls selinux_enforcing() which explodes when it can't find a /selinux/enforce. First discussion was to change /proc/mounts to hide the selinuxfs, sounds like a good plan until I realize /proc/mounts is actually link to /proc/self/mounts and that its getting way to complex tying to set up FS namespaces or whatever this is going to take. Right now I'm thinking of creating a /selinux with enforce=0 in all cases inside the chroot, anyone see a problem with that? (I could also work on fixing passwd, but i'm trying to be as 'backwards compatible' as possible.... ***restorecon: do we have an interface to see what is actually in security.xattr? Making use of the wonderful new deferred selinux context patch set from the kernel I get beautiful message like: /sbin/restorecon reset /sbin/dump context system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0 The file wasn't really "unlabeled_t" it just wasn't a valid label on the host machine. Since restorecon/fixfiles runs over the same files like 3 times during a livecd creation this gets rather annoying. Do we have an interface I could use to make restorecon do the right comparison here? ***allow unlabeled_t fs_t:filesystem associate: anyone have thoughts on how we want to handle this? I can probably do some sort of fscontext= mount magic once i figure out the right fs we are talking about and where the script does the mount. But then host policy is going to need rules to allow everything that can associate with fs_t with fs_allow_unlabeled_t. Is that hard? I assume Dan can help me out there. Does this sound like a good way to solve it? Is hard coding some 'fscontext=' line into livecd-creator a good idea? Should I just generically allow it? Should I make livecd-creator load a policy module to start off and unload it at the end? (I don't like this idea since I've learned livecd-creator can be pretty fragile and leave things half done/half undone...) ***Invalid prefix * On rawhide we just dropped that stuff altogether. Can we do the same on F8? Is it actually causing a problem? Dan, any hints on how I can make the system lie to you? Needless to say, I successfully built an F8 livecd with types not known tot he host system on rawhide today, booted, and logged in. tomorrow I spend more time typing to make the policy for livecd-creator a bit better..... -Eric From sds at tycho.nsa.gov Tue May 20 19:33:36 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 May 2008 15:33:36 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211310720.2691.47.camel@localhost.localdomain> References: <1211310720.2691.47.camel@localhost.localdomain> Message-ID: <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > ***passwd: > running a system with selinux enforcing/permissive (doesn't matter) and > attempting to run livecd-creator with selinux --disabled results in > passwd espoloding. passwd called is_selinux_enabled() which says yes > since /proc/mounts has an selinuxfs and the passwd calls > selinux_enforcing() which explodes when it can't find > a /selinux/enforce. First discussion was to change /proc/mounts to hide > the selinuxfs, sounds like a good plan until I realize /proc/mounts is > actually link to /proc/self/mounts and that its getting way to complex > tying to set up FS namespaces or whatever this is going to take. Right > now I'm thinking of creating a /selinux with enforce=0 in all cases > inside the chroot, anyone see a problem with that? (I could also work > on fixing passwd, but i'm trying to be as 'backwards compatible' as > possible.... Wait - you are confusing /proc/mounts and /proc/filesystems. IIUC, you are not mounting selinuxfs within the chroot and thus it does not appear in /proc/mounts regardless. But it does appear in /proc/filesystems, and that is why is_selinux_enabled() returns 1. If you bind mount a fake file over /proc/filesystems that excludes selinuxfs, it should cause is_selinux_enabled() to return 0. > ***restorecon: > do we have an interface to see what is actually in security.xattr? No - because we don't have separate interfaces for getting/setting MAC labels vs. getting/setting xattrs, unlike FreeBSD (where MAC labels are a first class construct and xattrs are just a storage mechanism that may or may not be used by the MAC module). We had talked about the possibility of allowing processes with CAP_MAC_ADMIN to get the raw context via getxattr in the deferred contexts thread on selinux list. But see my comments there. > Making use of the wonderful new deferred selinux context patch set from > the kernel I get beautiful message like: > > /sbin/restorecon reset /sbin/dump context > system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0 > > The file wasn't really "unlabeled_t" it just wasn't a valid label on the > host machine. Since restorecon/fixfiles runs over the same files like 3 > times during a livecd creation this gets rather annoying. Do we have an > interface I could use to make restorecon do the right comparison here? Well, could we instead avoid running restorecon/fixfiles multiple times on the same files? And ideally just get rpm to label the files correctly in the first place since that is why we added the kernel patch? > ***allow unlabeled_t fs_t:filesystem associate: > anyone have thoughts on how we want to handle this? I identified this in the deferred contexts patch description as needing to be allowed, along with a policy module to do it. See that. > I can probably do > some sort of fscontext= mount magic once i figure out the right fs we > are talking about and where the script does the mount. But then host > policy is going to need rules to allow everything that can associate > with fs_t with fs_allow_unlabeled_t. Is that hard? I assume Dan can > help me out there. Does this sound like a good way to solve it? Is > hard coding some 'fscontext=' line into livecd-creator a good idea? > Should I just generically allow it? Should I make livecd-creator load a > policy module to start off and unload it at the end? (I don't like > this idea since I've learned livecd-creator can be pretty fragile and > leave things half done/half undone...) I would tend to just allow it, either in the base policy or in a policy module used only for livecd-creator, possibly installed from its package if you don't want to load/remove it on each use. > ***Invalid prefix * > On rawhide we just dropped that stuff altogether. Can we do the same on > F8? Is it actually causing a problem? Dan, any hints on how I can make > the system lie to you? Do you mean just remove the security_check_context() call from seobject.py? Yes, I think you can just drop it. > Needless to say, I successfully built an F8 livecd with types not known > tot he host system on rawhide today, booted, and logged in. That sounds favorable. Now you just need to travel back in time before RHEL 5 was released, add the necessary support to it, and kill the person who will stop Skynet. > tomorrow I spend more time typing to make the policy for livecd-creator > a bit better..... -- Stephen Smalley National Security Agency From katzj at redhat.com Tue May 20 19:35:12 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 May 2008 15:35:12 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211310720.2691.47.camel@localhost.localdomain> References: <1211310720.2691.47.camel@localhost.localdomain> Message-ID: <1211312113.12052.20.camel@aglarond.local> On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > ***passwd: > running a system with selinux enforcing/permissive (doesn't matter) and > attempting to run livecd-creator with selinux --disabled results in > passwd espoloding. passwd called is_selinux_enabled() which says yes > since /proc/mounts has an selinuxfs and the passwd calls > selinux_enforcing() which explodes when it can't find > a /selinux/enforce. First discussion was to change /proc/mounts to hide > the selinuxfs, sounds like a good plan until I realize /proc/mounts is > actually link to /proc/self/mounts and that its getting way to complex > tying to set up FS namespaces or whatever this is going to take. Right > now I'm thinking of creating a /selinux with enforce=0 in all cases > inside the chroot, anyone see a problem with that? (I could also work > on fixing passwd, but i'm trying to be as 'backwards compatible' as > possible.... That seems pretty reasonable to me. The contortions of trying to get /proc/mounts right are definitely not worth it > ***restorecon: > do we have an interface to see what is actually in security.xattr? > Making use of the wonderful new deferred selinux context patch set from > the kernel I get beautiful message like: > The file wasn't really "unlabeled_t" it just wasn't a valid label on the > host machine. Since restorecon/fixfiles runs over the same files like 3 > times during a livecd creation this gets rather annoying. Do we have an > interface I could use to make restorecon do the right comparison here? If not, we could dump the output to /dev/null ;-) But, that seems a bit less than the ideal of really checking > ***allow unlabeled_t fs_t:filesystem associate: > anyone have thoughts on how we want to handle this? I can probably do > some sort of fscontext= mount magic once i figure out the right fs we > are talking about and where the script does the mount. But then host > policy is going to need rules to allow everything that can associate > with fs_t with fs_allow_unlabeled_t. So I'm not clear on exactly what the cause of this is or even what it's trying to say. > Needless to say, I successfully built an F8 livecd with types not known > tot he host system on rawhide today, booted, and logged in. Awesome! Jeremy From katzj at redhat.com Tue May 20 19:37:24 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 May 2008 15:37:24 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1211312244.12052.23.camel@aglarond.local> On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: > On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > > Making use of the wonderful new deferred selinux context patch set from > > the kernel I get beautiful message like: > > > > /sbin/restorecon reset /sbin/dump context > > system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0 > > > > The file wasn't really "unlabeled_t" it just wasn't a valid label on the > > host machine. Since restorecon/fixfiles runs over the same files like 3 > > times during a livecd creation this gets rather annoying. Do we have an > > interface I could use to make restorecon do the right comparison here? > > Well, could we instead avoid running restorecon/fixfiles multiple times > on the same files? And ideally just get rpm to label the files > correctly in the first place since that is why we added the kernel > patch? FWIW, we do a final pass with restorecon/fixfiles at the end of creating the files just so that we can ensure that any files that were created as the result of a %post script or anything else which doesn't transition correctly (... perhaps because the policy doesn't know it needs to) ends up with the right final label. This is pretty confined to just the livecd-creator case, though. Jeremy From dwalsh at redhat.com Tue May 20 19:43:07 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 20 May 2008 15:43:07 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211312244.12052.23.camel@aglarond.local> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211312244.12052.23.camel@aglarond.local> Message-ID: <483329CB.1030601@redhat.com> Jeremy Katz wrote: > On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: >> On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: >>> Making use of the wonderful new deferred selinux context patch set from >>> the kernel I get beautiful message like: >>> >>> /sbin/restorecon reset /sbin/dump context >>> system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0 >>> >>> The file wasn't really "unlabeled_t" it just wasn't a valid label on the >>> host machine. Since restorecon/fixfiles runs over the same files like 3 >>> times during a livecd creation this gets rather annoying. Do we have an >>> interface I could use to make restorecon do the right comparison here? >> Well, could we instead avoid running restorecon/fixfiles multiple times >> on the same files? And ideally just get rpm to label the files >> correctly in the first place since that is why we added the kernel >> patch? > > FWIW, we do a final pass with restorecon/fixfiles at the end of creating > the files just so that we can ensure that any files that were created as > the result of a %post script or anything else which doesn't transition > correctly (... perhaps because the policy doesn't know it needs to) ends > up with the right final label. This is pretty confined to just the > livecd-creator case, though. > > Jeremy > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Can we use fixfiles restore instead of restorecon. It will output a little "*" for every 10,000 files it relabels and we don't need to see thousands of useless restorecon lines. From dwalsh at redhat.com Tue May 20 19:43:47 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 20 May 2008 15:43:47 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211310720.2691.47.camel@localhost.localdomain> References: <1211310720.2691.47.camel@localhost.localdomain> Message-ID: <483329F3.6060804@redhat.com> Eric Paris wrote: > ***passwd: > running a system with selinux enforcing/permissive (doesn't matter) and > attempting to run livecd-creator with selinux --disabled results in > passwd espoloding. passwd called is_selinux_enabled() which says yes > since /proc/mounts has an selinuxfs and the passwd calls > selinux_enforcing() which explodes when it can't find > a /selinux/enforce. First discussion was to change /proc/mounts to hide > the selinuxfs, sounds like a good plan until I realize /proc/mounts is > actually link to /proc/self/mounts and that its getting way to complex > tying to set up FS namespaces or whatever this is going to take. Right > now I'm thinking of creating a /selinux with enforce=0 in all cases > inside the chroot, anyone see a problem with that? (I could also work > on fixing passwd, but i'm trying to be as 'backwards compatible' as > possible.... > > ***restorecon: > do we have an interface to see what is actually in security.xattr? > Making use of the wonderful new deferred selinux context patch set from > the kernel I get beautiful message like: > > /sbin/restorecon reset /sbin/dump context > system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0 > > The file wasn't really "unlabeled_t" it just wasn't a valid label on the > host machine. Since restorecon/fixfiles runs over the same files like 3 > times during a livecd creation this gets rather annoying. Do we have an > interface I could use to make restorecon do the right comparison here? > > ***allow unlabeled_t fs_t:filesystem associate: > anyone have thoughts on how we want to handle this? I can probably do > some sort of fscontext= mount magic once i figure out the right fs we > are talking about and where the script does the mount. But then host > policy is going to need rules to allow everything that can associate > with fs_t with fs_allow_unlabeled_t. Is that hard? I assume Dan can > help me out there. Does this sound like a good way to solve it? Is > hard coding some 'fscontext=' line into livecd-creator a good idea? > Should I just generically allow it? Should I make livecd-creator load a > policy module to start off and unload it at the end? (I don't like > this idea since I've learned livecd-creator can be pretty fragile and > leave things half done/half undone...) > > ***Invalid prefix * > On rawhide we just dropped that stuff altogether. Can we do the same on > F8? Is it actually causing a problem? Dan, any hints on how I can make > the system lie to you? Can't you just mount /dev/null on /selinux/context to get this to always succeed? > > Needless to say, I successfully built an F8 livecd with types not known > tot he host system on rawhide today, booted, and logged in. > > tomorrow I spend more time typing to make the policy for livecd-creator > a bit better..... > > -Eric > From katzj at redhat.com Tue May 20 19:43:15 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 20 May 2008 15:43:15 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <483329CB.1030601@redhat.com> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211312244.12052.23.camel@aglarond.local> <483329CB.1030601@redhat.com> Message-ID: <1211312595.12052.25.camel@aglarond.local> On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote: > Can we use fixfiles restore instead of restorecon. It will output a > little "*" for every 10,000 files it relabels and we don't need to see > thousands of useless restorecon lines. Sure -- I can even conditionalize it being restorecon vs fixfiles based on whether you've asked for verbose output or not Jeremy From sds at tycho.nsa.gov Tue May 20 19:46:34 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 May 2008 15:46:34 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <483329CB.1030601@redhat.com> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211312244.12052.23.camel@aglarond.local> <483329CB.1030601@redhat.com> Message-ID: <1211312794.7486.236.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote: > Jeremy Katz wrote: > > On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: > >> On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > >>> Making use of the wonderful new deferred selinux context patch set from > >>> the kernel I get beautiful message like: > >>> > >>> /sbin/restorecon reset /sbin/dump context > >>> system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0 > >>> > >>> The file wasn't really "unlabeled_t" it just wasn't a valid label on the > >>> host machine. Since restorecon/fixfiles runs over the same files like 3 > >>> times during a livecd creation this gets rather annoying. Do we have an > >>> interface I could use to make restorecon do the right comparison here? > >> Well, could we instead avoid running restorecon/fixfiles multiple times > >> on the same files? And ideally just get rpm to label the files > >> correctly in the first place since that is why we added the kernel > >> patch? > > > > FWIW, we do a final pass with restorecon/fixfiles at the end of creating > > the files just so that we can ensure that any files that were created as > > the result of a %post script or anything else which doesn't transition > > correctly (... perhaps because the policy doesn't know it needs to) ends > > up with the right final label. This is pretty confined to just the > > livecd-creator case, though. > > > > Jeremy > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Can we use fixfiles restore instead of restorecon. It will output a > little "*" for every 10,000 files it relabels and we don't need to see > thousands of useless restorecon lines. Isn't that just the same as calling restorecon with -p rather than -v? -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue May 20 19:52:27 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 May 2008 15:52:27 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1211313147.7486.240.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: > On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > > ***restorecon: > > do we have an interface to see what is actually in security.xattr? > > No - because we don't have separate interfaces for getting/setting MAC > labels vs. getting/setting xattrs, unlike FreeBSD (where MAC labels are > a first class construct and xattrs are just a storage mechanism that may > or may not be used by the MAC module). > > We had talked about the possibility of allowing processes with > CAP_MAC_ADMIN to get the raw context via getxattr in the deferred > contexts thread on selinux list. But see my comments there. In particular, see: http://marc.info/?l=selinux&m=121016477203440&w=2 http://marc.info/?l=selinux&m=121016814610025&w=2 http://marc.info/?l=selinux&m=121017332919586&w=2 It is possible, but we have to figure out how we want to handle it; we don't want every getxattr call to trigger a full capable() check along with auditing. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue May 20 19:54:27 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 May 2008 15:54:27 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211312595.12052.25.camel@aglarond.local> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211312244.12052.23.camel@aglarond.local> <483329CB.1030601@redhat.com> <1211312595.12052.25.camel@aglarond.local> Message-ID: <1211313267.7486.243.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-20 at 15:43 -0400, Jeremy Katz wrote: > On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote: > > Can we use fixfiles restore instead of restorecon. It will output a > > little "*" for every 10,000 files it relabels and we don't need to see > > thousands of useless restorecon lines. > > Sure -- I can even conditionalize it being restorecon vs fixfiles based > on whether you've asked for verbose output or not I think all you need to do is omit the -v from restorecon if they didn't ask for verbose output (or use -p instead if you want some indication of progress). fixfiles is just a wrapper script around setfiles and restorecon with some additional functionality, but in this case I'm not sure it adds anything. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue May 20 19:56:19 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 May 2008 15:56:19 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <483329F3.6060804@redhat.com> References: <1211310720.2691.47.camel@localhost.localdomain> <483329F3.6060804@redhat.com> Message-ID: <1211313379.7486.246.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote: > Eric Paris wrote: > > ***passwd: > > running a system with selinux enforcing/permissive (doesn't matter) and > > attempting to run livecd-creator with selinux --disabled results in > > passwd espoloding. passwd called is_selinux_enabled() which says yes > > since /proc/mounts has an selinuxfs and the passwd calls > > selinux_enforcing() which explodes when it can't find > > a /selinux/enforce. First discussion was to change /proc/mounts to hide > > the selinuxfs, sounds like a good plan until I realize /proc/mounts is > > actually link to /proc/self/mounts and that its getting way to complex > > tying to set up FS namespaces or whatever this is going to take. Right > > now I'm thinking of creating a /selinux with enforce=0 in all cases > > inside the chroot, anyone see a problem with that? (I could also work > > on fixing passwd, but i'm trying to be as 'backwards compatible' as > > possible.... > > > > ***restorecon: > > do we have an interface to see what is actually in security.xattr? > > Making use of the wonderful new deferred selinux context patch set from > > the kernel I get beautiful message like: > > > > /sbin/restorecon reset /sbin/dump context > > system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0 > > > > The file wasn't really "unlabeled_t" it just wasn't a valid label on the > > host machine. Since restorecon/fixfiles runs over the same files like 3 > > times during a livecd creation this gets rather annoying. Do we have an > > interface I could use to make restorecon do the right comparison here? > > > > ***allow unlabeled_t fs_t:filesystem associate: > > anyone have thoughts on how we want to handle this? I can probably do > > some sort of fscontext= mount magic once i figure out the right fs we > > are talking about and where the script does the mount. But then host > > policy is going to need rules to allow everything that can associate > > with fs_t with fs_allow_unlabeled_t. Is that hard? I assume Dan can > > help me out there. Does this sound like a good way to solve it? Is > > hard coding some 'fscontext=' line into livecd-creator a good idea? > > Should I just generically allow it? Should I make livecd-creator load a > > policy module to start off and unload it at the end? (I don't like > > this idea since I've learned livecd-creator can be pretty fragile and > > leave things half done/half undone...) > > > > ***Invalid prefix * > > On rawhide we just dropped that stuff altogether. Can we do the same on > > F8? Is it actually causing a problem? Dan, any hints on how I can make > > the system lie to you? > Can't you just mount /dev/null on /selinux/context to get this to always > succeed? I don't believe so, no. Remember that /selinux/context is a transaction-based interface where the caller writes the context and then reads back the canonicalized context. Omitting /selinux/context altogether makes matchpathcon() happy, but not explicit security_check_context() calls unless they also choose to ignore ENOENT. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue May 20 20:08:41 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 May 2008 16:08:41 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211313147.7486.240.camel@moss-spartans.epoch.ncsc.mil> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211313147.7486.240.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1211314121.7486.251.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-20 at 15:52 -0400, Stephen Smalley wrote: > On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: > > On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > > > ***restorecon: > > > do we have an interface to see what is actually in security.xattr? > > > > No - because we don't have separate interfaces for getting/setting MAC > > labels vs. getting/setting xattrs, unlike FreeBSD (where MAC labels are > > a first class construct and xattrs are just a storage mechanism that may > > or may not be used by the MAC module). > > > > We had talked about the possibility of allowing processes with > > CAP_MAC_ADMIN to get the raw context via getxattr in the deferred > > contexts thread on selinux list. But see my comments there. > > In particular, see: > http://marc.info/?l=selinux&m=121016477203440&w=2 > http://marc.info/?l=selinux&m=121016814610025&w=2 > http://marc.info/?l=selinux&m=121017332919586&w=2 > > It is possible, but we have to figure out how we want to handle it; we > don't want every getxattr call to trigger a full capable() check along > with auditing. Patch below is un-tested and may eat your brain. But might be worth trying out. If it helps, I can take it up on selinux list. Return the raw context value for getxattr if the caller has CAP_MAC_ADMIN and mac_admin in policy. Use non-auditing forms of the permission checks as getxattr may be called by unprivileged processes commonly and lack of permission just means that we fall back to the in-core context value, not a denial. diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 4be1563..fe4f9ad 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2765,12 +2765,24 @@ static int selinux_inode_getsecurity(const struct inode *inode, const char *name u32 size; int error; char *context = NULL; + struct task_security_struct *tsec = current->security; struct inode_security_struct *isec = inode->i_security; if (strcmp(name, XATTR_SELINUX_SUFFIX)) return -EOPNOTSUPP; - error = security_sid_to_context(isec->sid, &context, &size); + error = secondary_ops->capable(current, CAP_MAC_ADMIN); + if (!error) + error = avc_has_perm_noaudit(tsec->sid, tsec->sid, + SECCLASS_CAPABILITY2, + CAPABILITY2__MAC_ADMIN, + 0, + NULL); + if (!error) + error = security_sid_to_context_force(isec->sid, &context, + &size); + else + error = security_sid_to_context(isec->sid, &context, &size); if (error) return error; error = size; -- Stephen Smalley National Security Agency From eparis at redhat.com Tue May 20 20:10:16 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 20 May 2008 16:10:16 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1211314216.2691.59.camel@localhost.localdomain> On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: > On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > > ***passwd: > > running a system with selinux enforcing/permissive (doesn't matter) and > > attempting to run livecd-creator with selinux --disabled results in > > passwd espoloding. passwd called is_selinux_enabled() which says yes > > since /proc/mounts has an selinuxfs and the passwd calls > > selinux_enforcing() which explodes when it can't find > > a /selinux/enforce. First discussion was to change /proc/mounts to hide > > the selinuxfs, sounds like a good plan until I realize /proc/mounts is > > actually link to /proc/self/mounts and that its getting way to complex > > tying to set up FS namespaces or whatever this is going to take. Right > > now I'm thinking of creating a /selinux with enforce=0 in all cases > > inside the chroot, anyone see a problem with that? (I could also work > > on fixing passwd, but i'm trying to be as 'backwards compatible' as > > possible.... > > Wait - you are confusing /proc/mounts and /proc/filesystems. You are (once again) correct. Should be a lot easier to lie to :) > > ***restorecon: > > do we have an interface to see what is actually in security.xattr? > > No - because we don't have separate interfaces for getting/setting MAC > labels vs. getting/setting xattrs, unlike FreeBSD (where MAC labels are > a first class construct and xattrs are just a storage mechanism that may > or may not be used by the MAC module). > > We had talked about the possibility of allowing processes with > CAP_MAC_ADMIN to get the raw context via getxattr in the deferred > contexts thread on selinux list. But see my comments there. I remember the performance question, just not how it ended. Thanks for the refresh. > > > Making use of the wonderful new deferred selinux context patch set from > > the kernel I get beautiful message like: > > > > /sbin/restorecon reset /sbin/dump context > > system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0 > > > > The file wasn't really "unlabeled_t" it just wasn't a valid label on the > > host machine. Since restorecon/fixfiles runs over the same files like 3 > > times during a livecd creation this gets rather annoying. Do we have an > > interface I could use to make restorecon do the right comparison here? > > Well, could we instead avoid running restorecon/fixfiles multiple times > on the same files? And ideally just get rpm to label the files > correctly in the first place since that is why we added the kernel > patch? At this point no. A large portion of the files are going to be laid down by rpm long before the selinux-policy rpm is installed in the chroot (for whatever reason selinux-policy-targeted tends to be in the last 5 or so rpms installed in every livecd creation I do), so we can't get labels for rpm to use for the vast majority of the files. I think the only valid user of this deferred mapping stuff for these purposes is restorecon (or whatever equivalent) at the end. > > ***allow unlabeled_t fs_t:filesystem associate: > > anyone have thoughts on how we want to handle this? > > I identified this in the deferred contexts patch description as needing > to be allowed, along with a policy module to do it. See that. Yes, I was just suggesting a new fstype to use in situation where we expect these. If you think just let it go, I'll just let it go :) > > ***Invalid prefix * > > On rawhide we just dropped that stuff altogether. Can we do the same on > > F8? Is it actually causing a problem? Dan, any hints on how I can make > > the system lie to you? > > Do you mean just remove the security_check_context() call from > seobject.py? Yes, I think you can just drop it. dan wants me to (re)explore using /dev/null for /selinux/context I see that is going to cause some sort of issue in security_canonicalize_context_raw(). I guess I'll keep poking this monster with a stick (as of right now I'm not looking back at O_TRUNC, so calm down Stephen.) > Now you just need to travel back in time before RHEL 5 was released, add > the necessary support to it, and kill the person who will stop Skynet. Yeah, completely changing the security model like this is rather scary. /me goes to create /proc/sys/kernel/go_go_crazy_security_labels so LSPP/govt security nuts can keep their current code paths... From eparis at redhat.com Tue May 20 20:13:04 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 20 May 2008 16:13:04 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211314121.7486.251.camel@moss-spartans.epoch.ncsc.mil> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211313147.7486.240.camel@moss-spartans.epoch.ncsc.mil> <1211314121.7486.251.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1211314384.2691.62.camel@localhost.localdomain> On Tue, 2008-05-20 at 16:08 -0400, Stephen Smalley wrote: > Use non-auditing forms of the > permission checks as getxattr may be called by unprivileged processes > commonly and lack of permission just means that we fall back to the > in-core context value, not a denial. If we do put this on list, lets make this an in code comment so its easy to remember in another 100 years when the next poor sap has to figure out what I am doing these days :) > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c > index 4be1563..fe4f9ad 100644 > --- a/security/selinux/hooks.c > +++ b/security/selinux/hooks.c > @@ -2765,12 +2765,24 @@ static int selinux_inode_getsecurity(const struct inode *inode, const char *name > u32 size; > int error; > char *context = NULL; > + struct task_security_struct *tsec = current->security; > struct inode_security_struct *isec = inode->i_security; > > if (strcmp(name, XATTR_SELINUX_SUFFIX)) > return -EOPNOTSUPP; > > - error = security_sid_to_context(isec->sid, &context, &size); > + error = secondary_ops->capable(current, CAP_MAC_ADMIN); > + if (!error) > + error = avc_has_perm_noaudit(tsec->sid, tsec->sid, > + SECCLASS_CAPABILITY2, > + CAPABILITY2__MAC_ADMIN, > + 0, > + NULL); > + if (!error) > + error = security_sid_to_context_force(isec->sid, &context, > + &size); > + else > + error = security_sid_to_context(isec->sid, &context, &size); > if (error) > return error; > error = size; > From sds at tycho.nsa.gov Tue May 20 20:33:48 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 20 May 2008 16:33:48 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211314384.2691.62.camel@localhost.localdomain> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211313147.7486.240.camel@moss-spartans.epoch.ncsc.mil> <1211314121.7486.251.camel@moss-spartans.epoch.ncsc.mil> <1211314384.2691.62.camel@localhost.localdomain> Message-ID: <1211315628.7486.256.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-20 at 16:13 -0400, Eric Paris wrote: > On Tue, 2008-05-20 at 16:08 -0400, Stephen Smalley wrote: > > > > Use non-auditing forms of the > > permission checks as getxattr may be called by unprivileged processes > > commonly and lack of permission just means that we fall back to the > > in-core context value, not a denial. > > If we do put this on list, lets make this an in code comment so its easy > to remember in another 100 years when the next poor sap has to figure > out what I am doing these days :) Changed accordingly, and lightly tested. --- Enable processes with CAP_MAC_ADMIN + mac_admin permission in policy to get undefined contexts on inodes. This extends the support for deferred mapping of security contexts in order to permit restorecon and similar programs to see the raw file contexts unknown to the system policy in order to check them. --- security/selinux/hooks.c | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-) diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index 4be1563..91b666a 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -2754,9 +2754,7 @@ static int selinux_inode_removexattr(struct dentry *dentry, const char *name) } /* - * Copy the in-core inode security context value to the user. If the - * getxattr() prior to this succeeded, check to see if we need to - * canonicalize the value to be finally returned to the user. + * Copy the inode security context value to the user. * * Permission check is handled by selinux_inode_getxattr hook. */ @@ -2765,12 +2763,33 @@ static int selinux_inode_getsecurity(const struct inode *inode, const char *name u32 size; int error; char *context = NULL; + struct task_security_struct *tsec = current->security; struct inode_security_struct *isec = inode->i_security; if (strcmp(name, XATTR_SELINUX_SUFFIX)) return -EOPNOTSUPP; - error = security_sid_to_context(isec->sid, &context, &size); + /* + * If the caller has CAP_MAC_ADMIN, then get the raw context + * value even if it is not defined by current policy; otherwise, + * use the in-core value under current policy. + * Use the non-auditing forms of the permission checks since + * getxattr may be called by unprivileged processes commonly + * and lack of permission just means that we fall back to the + * in-core context value, not a denial. + */ + error = secondary_ops->capable(current, CAP_MAC_ADMIN); + if (!error) + error = avc_has_perm_noaudit(tsec->sid, tsec->sid, + SECCLASS_CAPABILITY2, + CAPABILITY2__MAC_ADMIN, + 0, + NULL); + if (!error) + error = security_sid_to_context_force(isec->sid, &context, + &size); + else + error = security_sid_to_context(isec->sid, &context, &size); if (error) return error; error = size; -- Stephen Smalley National Security Agency From paul at pixellab.co.uk Wed May 21 08:42:26 2008 From: paul at pixellab.co.uk (Paul Lauria) Date: Wed, 21 May 2008 09:42:26 +0100 Subject: setroubleshootd high memory usage Message-ID: <002301c8bb1e$99422100$cbc66300$@co.uk> Hi, I have been tracking an issue with regard to setroubleshootd for a month or so now, and am trying to work out why memory usage is so high. I have followed this issue that was also discussed: http://www.redhat.com/archives/fedora-selinux-list/2007-September/msg00000.h tml Top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2253 root 15 0 585m 472m 3304 S 0 46.7 3:55.34 setroubleshootd I use Webmin and this shows the following as 'Running Processes' : 2253 root 600020 kB /usr/bin/python -E /usr/sbin/setroubleshootd Obviously this is extremely high memory usage for a process (I only have 1 GB of RAM installed!) WC: wc /var/lib/setroubleshoot/audit_listener_database.xml 1313352 4320305 66032275 /var/lib/setroubleshoot/audit_listener_database.xml I have run audit2allow and pretty much cleared up the AVC denials that were appearing, but I am still receiving one or two from ClamAV SELAERT: sealert -a /var/log/audit/audit.log 100% done found 2 alerts in /var/log/audit/audit.log First Alert: SELinux is preventing /usr/bin/clamdscan (clamscan_t) "write" access to /var/webmin/sessiondb.pag (var_t). Second Alert: SELinux is preventing /usr/bin/clamdscan (clamscan_t) "connectto" access to /tmp/clamd.socket (initrc_t). Thanks for any assistance, Regards, Paul -- Paul Lauria -------------- next part -------------- An HTML attachment was scrubbed... URL: From visser.rob at gmail.com Wed May 21 10:01:33 2008 From: visser.rob at gmail.com (Rob Visser) Date: Wed, 21 May 2008 12:01:33 +0200 Subject: SELINUX admin with LDAP Message-ID: <869100480805210301s6ddfa47bl5b6b1e603a68acdd@mail.gmail.com> Hello, Is it possible to administer SELINUX users and RBAC stuff in LDAP? With RH directory server? It would be nice, since all the other stuff can be administered in LDAP. Rob Visser -------------- next part -------------- An HTML attachment was scrubbed... URL: From sds at tycho.nsa.gov Wed May 21 11:50:44 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 21 May 2008 07:50:44 -0400 Subject: SELINUX admin with LDAP In-Reply-To: <869100480805210301s6ddfa47bl5b6b1e603a68acdd@mail.gmail.com> References: <869100480805210301s6ddfa47bl5b6b1e603a68acdd@mail.gmail.com> Message-ID: <1211370644.7486.272.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-05-21 at 12:01 +0200, Rob Visser wrote: > Hello, > > Is it possible to administer SELINUX users and RBAC stuff in LDAP? > With RH directory server? > It would be nice, since all the other stuff can be administered in > LDAP. Not yet, but known as a need. Likely would take the form of moving seusers management out of libsemanage and adding a LDAP lookup back end to libselinux getseuserbyname(). Then you could manage at least the Linux user -> (SELinux user, MLS range) authorizations in LDAP. -- Stephen Smalley National Security Agency From jdennis at redhat.com Wed May 21 12:09:52 2008 From: jdennis at redhat.com (John Dennis) Date: Wed, 21 May 2008 08:09:52 -0400 Subject: setroubleshootd high memory usage In-Reply-To: <002301c8bb1e$99422100$cbc66300$@co.uk> References: <002301c8bb1e$99422100$cbc66300$@co.uk> Message-ID: <48341110.1040809@redhat.com> Paul Lauria wrote: > Hi, > > > > I have been tracking an issue with regard to setroubleshootd for a month > or so now, and am trying to work out why memory usage is so high. Please supply the setroubleshoot version. There have been many fixes over the last year, I wonder if you're using an old version. -- John Dennis From paul at pixellab.co.uk Wed May 21 12:41:41 2008 From: paul at pixellab.co.uk (Paul Lauria) Date: Wed, 21 May 2008 13:41:41 +0100 Subject: setroubleshootd high memory usage In-Reply-To: <48341110.1040809@redhat.com> References: <002301c8bb1e$99422100$cbc66300$@co.uk> <48341110.1040809@redhat.com> Message-ID: <005801c8bb40$05285710$0f790530$@co.uk> setroubleshoot version: 1.8.11-4 -- Paul Lauria -----Original Message----- From: John Dennis [mailto:jdennis at redhat.com] Sent: 21 May 2008 13:10 To: paul at pixellab.co.uk Cc: fedora-selinux-list at redhat.com Subject: Re: setroubleshootd high memory usage Paul Lauria wrote: > Hi, > > > > I have been tracking an issue with regard to setroubleshootd for a month > or so now, and am trying to work out why memory usage is so high. Please supply the setroubleshoot version. There have been many fixes over the last year, I wonder if you're using an old version. -- John Dennis From dwalsh at redhat.com Wed May 21 13:57:08 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 21 May 2008 09:57:08 -0400 Subject: SELINUX admin with LDAP In-Reply-To: <869100480805210301s6ddfa47bl5b6b1e603a68acdd@mail.gmail.com> References: <869100480805210301s6ddfa47bl5b6b1e603a68acdd@mail.gmail.com> Message-ID: <48342A34.4060907@redhat.com> Rob Visser wrote: > Hello, > > Is it possible to administer SELINUX users and RBAC stuff in LDAP? With RH > directory server? > It would be nice, since all the other stuff can be administered in LDAP. > > Rob Visser > We are working toward this goal. seusers is now used with libselinux which I believe is a mistake. I want to move the selection of the SELinux user and MLS Role into the login programs pam_selinux and sshd. RedHat is looking into integration with FreeIPA. The biggest problem we have now is how to select the correct seuser for a a machine. The following is a potential format for a seusers distributed file # Format # loginname;machine;service;selinuxuser;level # +name == group name system_u;*;*;system_u;s0-s0:c0.c1023 root;redsox.boston.redhat.com;*;unconfined_u;s0-s0:c0.c1023 dwalsh;people.redhat.com;*;xguest_u;s0 dwalsh;people.fedoraproject.com;*;xguest_u;s0 dwalsh;redline.boston.redhat.com;*;user_u;s0 dwalsh;redsox.boston.redhat.com;*;unconfined_u;s0-s0:c0.c1023 dwalsh;redsox.boston.redhat.com;ssh;guest_u;s0-s0:c0.c1023 +engineering;redsox;ssh;staff_u;s0-s0:c0.c1023 +engineering;*;ssh;staff_u;s0-s0:c0.c1023 +engineering;*;*;staff_u;s0-s0:c0.c1023 *;*;xdm;xguest_u;s0 *;*;*;guest_u;s0 We have come up with a couple of formats for the "best match", but this has to be easily understood by an administrator. Anyways this conversation should take place on the selinux developer list > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Wed May 21 14:06:35 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 21 May 2008 10:06:35 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211312794.7486.236.camel@moss-spartans.epoch.ncsc.mil> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211312244.12052.23.camel@aglarond.local> <483329CB.1030601@redhat.com> <1211312794.7486.236.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <48342C6B.9050305@redhat.com> Stephen Smalley wrote: > On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote: >> Jeremy Katz wrote: >>> On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: >>>> On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: >>>>> Making use of the wonderful new deferred selinux context patch set from >>>>> the kernel I get beautiful message like: >>>>> >>>>> /sbin/restorecon reset /sbin/dump context >>>>> system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0 >>>>> >>>>> The file wasn't really "unlabeled_t" it just wasn't a valid label on the >>>>> host machine. Since restorecon/fixfiles runs over the same files like 3 >>>>> times during a livecd creation this gets rather annoying. Do we have an >>>>> interface I could use to make restorecon do the right comparison here? >>>> Well, could we instead avoid running restorecon/fixfiles multiple times >>>> on the same files? And ideally just get rpm to label the files >>>> correctly in the first place since that is why we added the kernel >>>> patch? >>> FWIW, we do a final pass with restorecon/fixfiles at the end of creating >>> the files just so that we can ensure that any files that were created as >>> the result of a %post script or anything else which doesn't transition >>> correctly (... perhaps because the policy doesn't know it needs to) ends >>> up with the right final label. This is pretty confined to just the >>> livecd-creator case, though. >>> >>> Jeremy >>> >>> -- >>> fedora-selinux-list mailing list >>> fedora-selinux-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> Can we use fixfiles restore instead of restorecon. It will output a >> little "*" for every 10,000 files it relabels and we don't need to see >> thousands of useless restorecon lines. > > Isn't that just the same as calling restorecon with -p rather than -v? > I believe fixfiles restore only labels file systems that support labels while restorecon -R -v / Will walk all file systems. so fixfiles might be a little faster. /usr/bin/find "$FILEPATH" \ ! \( -fstype ext2 -o -fstype ext3 -o -fstype ext4 -o -fstype ext4dev -o -fstype gfs2 -o -fstype jfs -o -fstype xfs \) -prune -o -print0 | \ ${RESTORECON} ${OUTFILES} ${FORCEFLAG} $* -0 -f - 2>&1 >> $LOGFILE From jdennis at redhat.com Wed May 21 14:10:35 2008 From: jdennis at redhat.com (John Dennis) Date: Wed, 21 May 2008 10:10:35 -0400 Subject: setroubleshootd high memory usage In-Reply-To: <005801c8bb40$05285710$0f790530$@co.uk> References: <002301c8bb1e$99422100$cbc66300$@co.uk> <48341110.1040809@redhat.com> <005801c8bb40$05285710$0f790530$@co.uk> Message-ID: <48342D5B.9000409@redhat.com> Paul Lauria wrote: > setroubleshoot version: 1.8.11-4 > You didn't say what OS you were running on, but I suggest you upgrade to the newer 2.x version. -- John Dennis From sds at tycho.nsa.gov Wed May 21 14:19:53 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 21 May 2008 10:19:53 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <48342C6B.9050305@redhat.com> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211312244.12052.23.camel@aglarond.local> <483329CB.1030601@redhat.com> <1211312794.7486.236.camel@moss-spartans.epoch.ncsc.mil> <48342C6B.9050305@redhat.com> Message-ID: <1211379593.7486.310.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-05-21 at 10:06 -0400, Daniel J Walsh wrote: > Stephen Smalley wrote: > > On Tue, 2008-05-20 at 15:43 -0400, Daniel J Walsh wrote: > >> Jeremy Katz wrote: > >>> On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: > >>>> On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > >>>>> Making use of the wonderful new deferred selinux context patch set from > >>>>> the kernel I get beautiful message like: > >>>>> > >>>>> /sbin/restorecon reset /sbin/dump context > >>>>> system_u:object_r:unlabeled_t:s0->system_u:object_r:eparis_exec_t:s0 > >>>>> > >>>>> The file wasn't really "unlabeled_t" it just wasn't a valid label on the > >>>>> host machine. Since restorecon/fixfiles runs over the same files like 3 > >>>>> times during a livecd creation this gets rather annoying. Do we have an > >>>>> interface I could use to make restorecon do the right comparison here? > >>>> Well, could we instead avoid running restorecon/fixfiles multiple times > >>>> on the same files? And ideally just get rpm to label the files > >>>> correctly in the first place since that is why we added the kernel > >>>> patch? > >>> FWIW, we do a final pass with restorecon/fixfiles at the end of creating > >>> the files just so that we can ensure that any files that were created as > >>> the result of a %post script or anything else which doesn't transition > >>> correctly (... perhaps because the policy doesn't know it needs to) ends > >>> up with the right final label. This is pretty confined to just the > >>> livecd-creator case, though. > >>> > >>> Jeremy > >>> > >>> -- > >>> fedora-selinux-list mailing list > >>> fedora-selinux-list at redhat.com > >>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list > >> Can we use fixfiles restore instead of restorecon. It will output a > >> little "*" for every 10,000 files it relabels and we don't need to see > >> thousands of useless restorecon lines. > > > > Isn't that just the same as calling restorecon with -p rather than -v? > > > I believe fixfiles restore only labels file systems that support labels > while restorecon -R -v / Will walk all file systems. so fixfiles might > be a little faster. > > /usr/bin/find "$FILEPATH" \ > ! \( -fstype ext2 -o -fstype ext3 -o -fstype ext4 -o -fstype > ext4dev -o -fstype gfs2 -o -fstype jfs -o -fstype xfs \) -prune -o > -print0 | \ > ${RESTORECON} ${OUTFILES} ${FORCEFLAG} $* -0 -f - 2>&1 >> > $LOGFILE I see. I'm not sure how much of a problem that is for the chroot environment, and restorecon does have the -e option for excluding parts of the tree, although it is non-optimal in implementation (ideally we could prune the tree walk itself, but I think that would require converting restorecon from using nftw to using fts, which has long been a todo item). However, if they were to use fixfiles restore, is there a way to enable verbose mode there? /sbin/fixfiles restore -v doesn't work. -- Stephen Smalley National Security Agency From paul at pixellab.co.uk Wed May 21 14:32:39 2008 From: paul at pixellab.co.uk (Paul Lauria) Date: Wed, 21 May 2008 15:32:39 +0100 Subject: setroubleshootd high memory usage In-Reply-To: <48342D5B.9000409@redhat.com> References: <002301c8bb1e$99422100$cbc66300$@co.uk> <48341110.1040809@redhat.com> <005801c8bb40$05285710$0f790530$@co.uk> <48342D5B.9000409@redhat.com> Message-ID: <007501c8bb4f$85dd4320$9197c960$@co.uk> Its EL5. Where can I get the newer 2.x version? Thanks, Paul -----Original Message----- From: John Dennis [mailto:jdennis at redhat.com] Sent: 21 May 2008 15:11 To: paul at pixellab.co.uk Cc: fedora-selinux-list at redhat.com Subject: Re: setroubleshootd high memory usage Paul Lauria wrote: > setroubleshoot version: 1.8.11-4 > You didn't say what OS you were running on, but I suggest you upgrade to the newer 2.x version. -- John Dennis From jdennis at redhat.com Wed May 21 15:05:13 2008 From: jdennis at redhat.com (John Dennis) Date: Wed, 21 May 2008 11:05:13 -0400 Subject: setroubleshootd high memory usage In-Reply-To: <007501c8bb4f$85dd4320$9197c960$@co.uk> References: <002301c8bb1e$99422100$cbc66300$@co.uk> <48341110.1040809@redhat.com> <005801c8bb40$05285710$0f790530$@co.uk> <48342D5B.9000409@redhat.com> <007501c8bb4f$85dd4320$9197c960$@co.uk> Message-ID: <48343A29.6000200@redhat.com> Paul Lauria wrote: > Its EL5. > > Where can I get the newer 2.x version? > For RHEL 5 you'll find it in the 5.2 update, which was recently released. -- John Dennis From adam.huffman at gmail.com Wed May 21 15:20:52 2008 From: adam.huffman at gmail.com (Adam Huffman) Date: Wed, 21 May 2008 16:20:52 +0100 Subject: Root unable to change services on F8 Message-ID: <608c44bf0805210820j1f9200sb64d9d536a11d1d2@mail.gmail.com> Recently I've been unable to start/stop services when running su - root in a terminal of an X session. The error I see is: service certmaster status env: /etc/init.d/certmaster: Permission denied In permissive mode, the command succeeds. In that terminal root is: unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh If I login as root on the console, the command succeeds. However, I prefer not to do that too often as it sometimes causes X to crash. On the console, root is system_u:system_r:unconfined_t From dwalsh at redhat.com Wed May 21 15:48:42 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 21 May 2008 11:48:42 -0400 Subject: Root unable to change services on F8 In-Reply-To: <608c44bf0805210820j1f9200sb64d9d536a11d1d2@mail.gmail.com> References: <608c44bf0805210820j1f9200sb64d9d536a11d1d2@mail.gmail.com> Message-ID: <4834445A.50206@redhat.com> Adam Huffman wrote: > Recently I've been unable to start/stop services when running su - > root in a terminal of an X session. > > The error I see is: > > service certmaster status > env: /etc/init.d/certmaster: Permission denied > > In permissive mode, the command succeeds. In that terminal root is: > > unconfined_u:unconfined_r:unconfined_t:SystemLow-SystemHigh > > If I login as root on the console, the command succeeds. However, I > prefer not to do that too often as it sometimes causes X to crash. > On the console, root is > > system_u:system_r:unconfined_t > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Check the context on /etc/init.d/certmaster restorecon -R -v /etc/init.d/certmaster From olivares14031 at yahoo.com Thu May 22 16:52:45 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 22 May 2008 09:52:45 -0700 (PDT) Subject: avc denials: nspluginscan, file_t, gconfd? Message-ID: <157262.55465.qm@web52611.mail.re2.yahoo.com> Dear all, I got a setroubleshoot popop on the laptop. I am attaching them here: Advice/suggestions/comments greatly appreciated. TIA, Antonio Summary: SELinux is preventing nspluginscan from making the program stack executable. Detailed Description: The nspluginscan application attempted to make its stack executable. This is a potential security problem. This should never ever be necessary. Stack memory is not executable on most OSes these days and this will not change. Executable stack memory is one of the biggest security problems. An execstack error might in fact be most likely raised by malicious code. Applications are sometimes coded incorrectly and request this permission. The SELinux Memory Protection Tests (http://people.redhat.com/drepper/selinux-mem.html) web page explains how to remove this requirement. If nspluginscan does not work and you need it to work, you can configure SELinux temporarily to allow this access until the application is fixed. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Allowing Access: Sometimes a library is accidentally marked with the execstack flag, if you find a library with this flag you can clear it with the execstack -c LIBRARY_PATH. Then retry your application. If the app continues to not work, you can turn the flag back on with execstack -s LIBRARY_PATH. Otherwise, if you trust nspluginscan to run correctly, you can change the context of the executable to unconfined_execmem_exec_t. "chcon -t unconfined_execmem_exec_t '/usr/bin/nspluginscan'" You must also change the default file context files on the system in order to preserve them even on a full relabel. "semanage fcontext -a -t unconfined_execmem_exec_t '/usr/bin/nspluginscan'" Fix Command: chcon -t unconfined_execmem_exec_t '/usr/bin/nspluginscan' Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:SystemLow- SystemHigh Target Context unconfined_u:unconfined_r:unconfined_t:SystemLow- SystemHigh Target Objects None [ process ] Source nspluginscan Source Path /usr/bin/nspluginscan Port Host localhost.localdomain Source RPM Packages kdebase-4.0.3-9.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-45.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_execstack Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.17.rc3.fc10.i686 #1 SMP Sun May 18 19:05:03 EDT 2008 i686 i686 Alert Count 11 First Seen Tue 05 Feb 2008 07:13:02 AM CST Last Seen Wed 21 May 2008 08:23:12 AM CDT Local ID 7afb3a36-5b69-486c-a93b-02e714040250 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211376192.783:89): avc: denied { execstack } for pid=3177 comm="nspluginscan" scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process host=localhost.localdomain type=SYSCALL msg=audit(1211376192.783:89): arch=40000003 syscall=125 success=no exit=-13 a0=bfeee000 a1=1000 a2=1000007 a3=fffff000 items=0 ppid=3166 pid=3177 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="nspluginscan" exe="/usr/bin/nspluginscan" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Summary: SELinux is preventing nm-system-setti (NetworkManager_t) "read" to ./PolicyKit.reload (system_crond_var_lib_t). Detailed Description: SELinux denied access requested by nm-system-setti. It is not expected that this access is required by nm-system-setti and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./PolicyKit.reload, restorecon -v './PolicyKit.reload' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:NetworkManager_t:SystemLow- SystemHigh Target Context system_u:object_r:system_crond_var_lib_t Target Objects ./PolicyKit.reload [ file ] Source nm-system-setti Source Path /usr/sbin/nm-system-settings Port Host localhost.localdomain Source RPM Packages NetworkManager-0.7.0-0.9.3.svn3675.fc10 Target RPM Packages Policy RPM selinux-policy-3.3.1-45.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.17.rc3.fc10.i686 #1 SMP Sun May 18 19:05:03 EDT 2008 i686 i686 Alert Count 3 First Seen Wed 21 May 2008 08:21:22 AM CDT Last Seen Thu 22 May 2008 06:51:05 AM CDT Local ID 842c746b-258d-45ad-bb2e-22c271d0b9ef Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211457065.391:7): avc: denied { read } for pid=2501 comm="nm-system-setti" name="PolicyKit.reload" dev=dm-0 ino=443096 scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 tcontext=system_u:object_r:system_crond_var_lib_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1211457065.391:7): arch=40000003 syscall=292 success=no exit=-13 a0=6 a1=75d620 a2=106 a3=9b81f20 items=0 ppid=2500 pid=2501 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nm-system-setti" exe="/usr/sbin/nm-system-settings" subj=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 key=(null) Summary: SELinux is preventing nm-system-setti (NetworkManager_t) "getattr" to /dev/root (fixed_disk_device_t). Detailed Description: SELinux denied access requested by nm-system-setti. It is not expected that this access is required by nm-system-setti and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /dev/root, restorecon -v '/dev/root' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:NetworkManager_t:SystemLow- SystemHigh Target Context system_u:object_r:fixed_disk_device_t Target Objects /dev/root [ blk_file ] Source nm-system-setti Source Path /usr/sbin/nm-system-settings Port Host localhost.localdomain Source RPM Packages NetworkManager-0.7.0-0.9.3.svn3675.fc10 Target RPM Packages Policy RPM selinux-policy-3.3.1-45.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.17.rc3.fc10.i686 #1 SMP Sun May 18 19:05:03 EDT 2008 i686 i686 Alert Count 3 First Seen Wed 21 May 2008 08:21:23 AM CDT Last Seen Thu 22 May 2008 06:51:07 AM CDT Local ID 12a9ceb6-2b80-406f-86ce-eddd56016c6b Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211457067.143:8): avc: denied { getattr } for pid=2501 comm="nm-system-setti" path="/dev/root" dev=tmpfs ino=402 scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=blk_file host=localhost.localdomain type=SYSCALL msg=audit(1211457067.143:8): arch=40000003 syscall=195 success=no exit=-13 a0=415283d a1=bff720ec a2=3d8fff4 a3=415283d items=0 ppid=1 pid=2501 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="nm-system-setti" exe="/usr/sbin/nm-system-settings" subj=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 key=(null) Summary: SELinux is preventing dbus-daemon (xdm_dbusd_t) "execute" to ./gconfd-2 (gconfd_exec_t). Detailed Description: SELinux denied access requested by dbus-daemon. It is not expected that this access is required by dbus-daemon and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./gconfd-2, restorecon -v './gconfd-2' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:system_r:xdm_dbusd_t:SystemLow-SystemHigh Target Context system_u:object_r:gconfd_exec_t Target Objects ./gconfd-2 [ file ] Source dbus-daemon Source Path /bin/dbus-daemon Port Host localhost.localdomain Source RPM Packages dbus-1.2.1-3.fc10 Target RPM Packages Policy RPM selinux-policy-3.3.1-45.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.17.rc3.fc10.i686 #1 SMP Sun May 18 19:05:03 EDT 2008 i686 i686 Alert Count 401 First Seen Wed 21 May 2008 08:21:39 AM CDT Last Seen Thu 22 May 2008 06:55:49 AM CDT Local ID 3d366e28-6abd-4740-b078-7ec3f331bce5 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211457349.146:165): avc: denied { execute } for pid=3544 comm="dbus-daemon" name="gconfd-2" dev=dm-0 ino=125235 scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gconfd_exec_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1211457349.146:165): arch=40000003 syscall=11 success=no exit=-13 a0=b8ed76f0 a1=b8edffa8 a2=b8ede8f8 a3=b8edbb58 items=0 ppid=3543 pid=3544 auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 comm="dbus-daemon" exe="/bin/dbus-daemon" subj=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 key=(null) Summary: SELinux is preventing access to files with the label, file_t. Detailed Description: SELinux permission checks on files labeled file_t are being denied. file_t is the context the SELinux kernel gives to files that do not have a label. This indicates a serious labeling problem. No files on an SELinux box should ever be labeled file_t. If you have just added a new disk drive to the system you can relabel it using the restorecon command. Otherwise you should relabel the entire files system. Allowing Access: You can execute the following command as root to relabel your computer system: "touch /.autorelabel; reboot" Additional Information: Source Context system_u:system_r:tmpreaper_t Target Context system_u:object_r:file_t Target Objects ./kpc [ dir ] Source tmpwatch Source Path /usr/sbin/tmpwatch Port Host localhost.localdomain Source RPM Packages tmpwatch-2.9.13-2 Target RPM Packages Policy RPM selinux-policy-3.3.1-45.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.26-0.17.rc3.fc10.i686 #1 SMP Sun May 18 19:05:03 EDT 2008 i686 i686 Alert Count 12 First Seen Thu 28 Feb 2008 08:12:12 AM CST Last Seen Thu 22 May 2008 08:15:01 AM CDT Local ID 78c39dd1-e417-40e6-8056-ac3a90e9e235 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211462101.317:204): avc: denied { read } for pid=14967 comm="tmpwatch" name="kpc" dev=dm-0 ino=885859 scontext=system_u:system_r:tmpreaper_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1211462101.317:204): arch=40000003 syscall=5 success=no exit=-13 a0=804ac62 a1=98800 a2=0 a3=0 items=0 ppid=14964 pid=14967 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="tmpwatch" exe="/usr/sbin/tmpwatch" subj=system_u:system_r:tmpreaper_t:s0 key=(null) From olivares14031 at yahoo.com Fri May 23 00:24:45 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 22 May 2008 17:24:45 -0700 (PDT) Subject: selinux denials for new Fedora 9 install Message-ID: <686028.62717.qm@web52612.mail.re2.yahoo.com> Dear all, I have installed Fedora 9 unto a new machine x86_64, it was working beautifully, I am at this time putting in updates. However I got some selinux denials from setroubleshoot deamon Tomboy Notes shows this error in box \begin{box} "Tomboy Notes" has quit unexpectedly If you reload a panel object, it will automatically be added back to the panel. \end{box} The selinux denials follow: Advice/Suggestions/Comments are welcome :) Regards, Antonio Summary: SELinux is preventing tomboy (unlabeled_t) "read" to socket (unlabeled_t). Detailed Description: SELinux denied access requested by tomboy. It is not expected that this access is required by tomboy and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:object_r:unlabeled_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects socket [ unix_stream_socket ] Source tomboy Source Path /usr/bin/mono Port Host localhost.localdomain Source RPM Packages mono-core-1.9.1-2.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 Alert Count 1 First Seen Thu 22 May 2008 02:18:36 PM CDT Last Seen Thu 22 May 2008 02:18:36 PM CDT Local ID e22208e0-0d5a-43aa-a57d-ca251e71c7f0 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211483916.963:40): avc: denied { read } for pid=2664 comm="tomboy" path="socket:[19661]" dev=sockfs ino=19661 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=unix_stream_socket host=localhost.localdomain type=SYSCALL msg=audit(1211483916.963:40): arch=c000003e syscall=0 success=no exit=-13 a0=3 a1=e69c24 a2=1000 a3=1 items=0 ppid=1 pid=2664 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="tomboy" exe="/usr/bin/mono" subj=system_u:object_r:unlabeled_t:s0 key=(null) Summary: SELinux is preventing tomboy (unlabeled_t) "write" to socket (unlabeled_t). Detailed Description: SELinux denied access requested by tomboy. It is not expected that this access is required by tomboy and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:object_r:unlabeled_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects socket [ unix_stream_socket ] Source tomboy Source Path /usr/bin/mono Port Host localhost.localdomain Source RPM Packages mono-core-1.9.1-2.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 Alert Count 5 First Seen Thu 22 May 2008 02:18:37 PM CDT Last Seen Thu 22 May 2008 02:18:37 PM CDT Local ID 125d1844-fea9-4203-9bde-2f6582a25bec Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211483917.148:46): avc: denied { write } for pid=2664 comm="tomboy" path="socket:[19778]" dev=sockfs ino=19778 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=unix_stream_socket host=localhost.localdomain type=SYSCALL msg=audit(1211483917.148:46): arch=c000003e syscall=20 success=no exit=-13 a0=14 a1=ef21e0 a2=1 a3=a0 items=0 ppid=1 pid=2664 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="tomboy" exe="/usr/bin/mono" subj=system_u:object_r:unlabeled_t:s0 key=(null) Summary: SELinux is preventing tomboy (unlabeled_t) "search" to / (root_t). Detailed Description: SELinux denied access requested by tomboy. It is not expected that this access is required by tomboy and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: Sometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for /, restorecon -v '/' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:object_r:unlabeled_t:s0 Target Context system_u:object_r:root_t:s0 Target Objects / [ dir ] Source tomboy Source Path /usr/bin/mono Port Host localhost.localdomain Source RPM Packages mono-core-1.9.1-2.fc9 Target RPM Packages filesystem-2.4.13-1.fc9 Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall_file Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 Alert Count 1 First Seen Thu 22 May 2008 02:18:37 PM CDT Last Seen Thu 22 May 2008 02:18:37 PM CDT Local ID dc21e5d6-47fb-47f9-97de-31a1009d6922 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211483917.148:47): avc: denied { search } for pid=2664 comm="tomboy" name="/" dev=dm-0 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir host=localhost.localdomain type=SYSCALL msg=audit(1211483917.148:47): arch=c000003e syscall=87 success=no exit=-13 a0=ef24a0 a1=ef1cd0 a2=ef24a0 a3=7ffff6f6ede0 items=0 ppid=1 pid=2664 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="tomboy" exe="/usr/bin/mono" subj=system_u:object_r:unlabeled_t:s0 key=(null) Summary: SELinux is preventing tomboy (unlabeled_t) "unix_write" to (unlabeled_t). Detailed Description: SELinux denied access requested by tomboy. It is not expected that this access is required by tomboy and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:object_r:unlabeled_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects None [ sem ] Source tomboy Source Path /usr/bin/mono Port Host localhost.localdomain Source RPM Packages mono-core-1.9.1-2.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 Alert Count 1 First Seen Thu 22 May 2008 02:18:37 PM CDT Last Seen Thu 22 May 2008 02:18:37 PM CDT Local ID be7c4e58-a211-4d65-b643-49e9315ba3a6 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211483917.148:48): avc: denied { unix_write } for pid=2664 comm="tomboy" key=1291903136 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=sem host=localhost.localdomain type=SYSCALL msg=audit(1211483917.148:48): arch=c000003e syscall=65 success=no exit=-13 a0=0 a1=7ffff6f6f0d0 a2=1 a3=700 items=0 ppid=1 pid=2664 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="tomboy" exe="/usr/bin/mono" subj=system_u:object_r:unlabeled_t:s0 key=(null) Summary: SELinux is preventing tomboy (unlabeled_t) "signal" to (unlabeled_t). Detailed Description: SELinux denied access requested by tomboy. It is not expected that this access is required by tomboy and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:object_r:unlabeled_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects None [ process ] Source tomboy Source Path /usr/bin/mono Port Host localhost.localdomain Source RPM Packages mono-core-1.9.1-2.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 Alert Count 2 First Seen Thu 22 May 2008 02:18:37 PM CDT Last Seen Thu 22 May 2008 02:18:37 PM CDT Local ID 8a1b1271-3864-4af1-90f6-b050cca48dd5 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211483917.266:51): avc: denied { signal } for pid=2664 comm="tomboy" scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=process host=localhost.localdomain type=SYSCALL msg=audit(1211483917.266:51): arch=c000003e syscall=234 success=no exit=-13 a0=a68 a1=a68 a2=6 a3=8 items=0 ppid=1 pid=2664 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="tomboy" exe="/usr/bin/mono" subj=system_u:object_r:unlabeled_t:s0 key=(null) Summary: SELinux is preventing tomboy (unlabeled_t) "fork" to (unlabeled_t). Detailed Description: SELinux denied access requested by tomboy. It is not expected that this access is required by tomboy and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:object_r:unlabeled_t:s0 Target Context system_u:object_r:unlabeled_t:s0 Target Objects None [ process ] Source tomboy Source Path /usr/bin/mono Port Host localhost.localdomain Source RPM Packages mono-core-1.9.1-2.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 Alert Count 1 First Seen Thu 22 May 2008 02:18:37 PM CDT Last Seen Thu 22 May 2008 02:18:37 PM CDT Local ID 25c06d10-f06e-4883-a58b-65a70df67409 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211483917.499:84): avc: denied { fork } for pid=2664 comm="tomboy" scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=process host=localhost.localdomain type=SYSCALL msg=audit(1211483917.499:84): arch=c000003e syscall=56 success=no exit=-13 a0=1200011 a1=0 a2=0 a3=7f0aede2d840 items=0 ppid=1 pid=2664 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="tomboy" exe="/usr/bin/mono" subj=system_u:object_r:unlabeled_t:s0 key=(null) Summary: SELinux is preventing tomboy (unlabeled_t) "use" to /dev/null (unconfined_t). Detailed Description: SELinux denied access requested by tomboy. It is not expected that this access is required by tomboy and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package. Additional Information: Source Context system_u:object_r:unlabeled_t:s0 Target Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Objects /dev/null [ fd ] Source tomboy Source Path /usr/bin/mono Port Host localhost.localdomain Source RPM Packages mono-core-1.9.1-2.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-42.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name catchall Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.25-14.fc9.x86_64 #1 SMP Thu May 1 06:06:21 EDT 2008 x86_64 x86_64 Alert Count 35 First Seen Thu 22 May 2008 02:18:36 PM CDT Last Seen Thu 22 May 2008 02:18:37 PM CDT Local ID a83681c0-d977-4078-83ad-3ffe26691266 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211483917.499:85): avc: denied { use } for pid=2664 comm="tomboy" path="/dev/null" dev=tmpfs ino=1898 scontext=system_u:object_r:unlabeled_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=fd host=localhost.localdomain type=SYSCALL msg=audit(1211483917.499:85): arch=c000003e syscall=1 success=no exit=-13 a0=2 a1=13d570 a2=124 a3=7f0aede2d7b0 items=0 ppid=1 pid=2664 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1 comm="tomboy" exe="/usr/bin/mono" subj=system_u:object_r:unlabeled_t:s0 key=(null) From olivares14031 at yahoo.com Fri May 23 01:54:23 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Thu, 22 May 2008 18:54:23 -0700 (PDT) Subject: SELinux prevented umount from mounting on the file or directory "/media/.hal-mtab-lock" (type "mnt_t"). Message-ID: <688541.27312.qm@web52612.mail.re2.yahoo.com> Dear all, I have gotten a new avc., after applying the updates, the other ones disappeared :) Hope that was just it. Regards, Antonio Summary: SELinux prevented umount from mounting on the file or directory "/media/.hal-mtab-lock" (type "mnt_t"). Detailed Description: SELinux prevented umount from mounting a filesystem on the file or directory "/media/.hal-mtab-lock" of type "mnt_t". By default SELinux limits the mounting of filesystems to only some files or directories (those with types that have the mountpoint attribute). The type "mnt_t" does not have this attribute. You can either relabel the file or directory or set the boolean "allow_mount_anyfile" to true to allow mounting on any file or directory. Allowing Access: Changing the "allow_mount_anyfile" boolean to true will allow this access: "setsebool -P allow_mount_anyfile=1." Fix Command: setsebool -P allow_mount_anyfile=1 Additional Information: Source Context system_u:system_r:mount_t:s0 Target Context system_u:object_r:mnt_t:s0 Target Objects /media/.hal-mtab-lock [ file ] Source umount Source Path /bin/umount Port Host localhost.localdomain Source RPM Packages util-linux-ng-2.13.1-6.fc9 Target RPM Packages Policy RPM selinux-policy-3.3.1-51.fc9 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_mount_anyfile Host Name localhost.localdomain Platform Linux localhost.localdomain 2.6.25.3-18.fc9.x86_64 #1 SMP Tue May 13 04:54:47 EDT 2008 x86_64 x86_64 Alert Count 1 First Seen Thu 22 May 2008 03:52:14 PM CDT Last Seen Thu 22 May 2008 03:52:14 PM CDT Local ID b4ecd96d-7c1b-4016-84f4-b9edb6aa30c9 Line Numbers Raw Audit Messages host=localhost.localdomain type=AVC msg=audit(1211489534.822:146): avc: denied { read write } for pid=16678 comm="umount" path="/media/.hal-mtab-lock" dev=dm-0 ino=1785858 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=file host=localhost.localdomain type=SYSCALL msg=audit(1211489534.822:146): arch=c000003e syscall=59 success=yes exit=0 a0=403665 a1=7fff62ce68d0 a2=7fff62ce6f58 a3=0 items=0 ppid=16677 pid=16678 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="umount" exe="/bin/umount" subj=system_u:system_r:mount_t:s0 key=(null) From tmz at pobox.com Fri May 23 02:16:05 2008 From: tmz at pobox.com (Todd Zullinger) Date: Thu, 22 May 2008 22:16:05 -0400 Subject: SELinux prevented umount from mounting on the file or directory "/media/.hal-mtab-lock" (type "mnt_t"). In-Reply-To: <688541.27312.qm@web52612.mail.re2.yahoo.com> References: <688541.27312.qm@web52612.mail.re2.yahoo.com> Message-ID: <20080523021605.GD3216@inocybe.teonanacatl.org> Antonio Olivares wrote: > SELinux prevented umount from mounting on the file or directory > "/media/.hal-mtab-lock" (type "mnt_t"). I just started seeing this in the past day or so as well (on F-9). It happens anytime I unmount removable media, like usb sticks or an ipod. This is with selinux-policy-3.3.1-51.fc9.noarch -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Money frees you from doing things you dislike. Since I dislike doing nearly everything, money is handy. -- Groucho Marx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From sds at tycho.nsa.gov Fri May 23 12:23:51 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 23 May 2008 08:23:51 -0400 Subject: selinux denials for new Fedora 9 install In-Reply-To: <686028.62717.qm@web52612.mail.re2.yahoo.com> References: <686028.62717.qm@web52612.mail.re2.yahoo.com> Message-ID: <1211545431.7486.572.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2008-05-22 at 17:24 -0700, Antonio Olivares wrote: > Dear all, > > I have installed Fedora 9 unto a new machine x86_64, it was working beautifully, I am at this time putting in updates. However I got some selinux denials from setroubleshoot deamon > > Tomboy Notes shows this error in box > \begin{box} > > "Tomboy Notes" has quit unexpectedly > > If you reload a panel object, it will automatically be added back to the panel. > > \end{box} > > The selinux denials follow: > > Advice/Suggestions/Comments are welcome :) The unlabeled_t indicates that whatever context tomboy was running in was made invalid by a policy update. You should have seen messages in /var/log/messages about invalidating contexts upon the policy load. Re-starting the process should get it into a valid context again. -- Stephen Smalley National Security Agency From olivares14031 at yahoo.com Fri May 23 13:30:37 2008 From: olivares14031 at yahoo.com (Antonio Olivares) Date: Fri, 23 May 2008 06:30:37 -0700 (PDT) Subject: selinux denials for new Fedora 9 install In-Reply-To: <1211545431.7486.572.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <958662.91871.qm@web52610.mail.re2.yahoo.com> --- Stephen Smalley wrote: > > On Thu, 2008-05-22 at 17:24 -0700, Antonio Olivares > wrote: > > Dear all, > > > > I have installed Fedora 9 unto a new machine > x86_64, it was working beautifully, I am at this > time putting in updates. However I got some selinux > denials from setroubleshoot deamon > > > > Tomboy Notes shows this error in box > > \begin{box} > > > > "Tomboy Notes" has quit unexpectedly > > > > If you reload a panel object, it will > automatically be added back to the panel. > > > > \end{box} > > > > The selinux denials follow: > > > > Advice/Suggestions/Comments are welcome :) > > The unlabeled_t indicates that whatever context > tomboy was running in > was made invalid by a policy update. You should > have seen messages > in /var/log/messages about invalidating contexts > upon the policy load. > > Re-starting the process should get it into a valid > context again. > > -- > Stephen Smalley > National Security Agency > > The updates fixed it :) Thanks! Antonio From dwalsh at redhat.com Fri May 23 19:03:35 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 23 May 2008 15:03:35 -0400 Subject: avc denials: nspluginscan, file_t, gconfd? In-Reply-To: <157262.55465.qm@web52611.mail.re2.yahoo.com> References: <157262.55465.qm@web52611.mail.re2.yahoo.com> Message-ID: <48371507.4000204@redhat.com> Antonio Olivares wrote: > Dear all, > > I got a setroubleshoot popop on the laptop. I am > attaching them here: > > Advice/suggestions/comments greatly appreciated. > > TIA, > > Antonio > > > Summary: > > SELinux is preventing nspluginscan from making the > program stack executable. > > Detailed Description: > > The nspluginscan application attempted to make its > stack executable. This is a > potential security problem. This should never ever be > necessary. Stack memory is > not executable on most OSes these days and this will > not change. Executable > stack memory is one of the biggest security problems. > An execstack error might > in fact be most likely raised by malicious code. > Applications are sometimes > coded incorrectly and request this permission. The > SELinux Memory Protection > Tests > (http://people.redhat.com/drepper/selinux-mem.html) > web page explains how > to remove this requirement. If nspluginscan does not > work and you need it to > work, you can configure SELinux temporarily to allow > this access until the > application is fixed. Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Allowing Access: > > Sometimes a library is accidentally marked with the > execstack flag, if you find > a library with this flag you can clear it with the > execstack -c LIBRARY_PATH. > Then retry your application. If the app continues to > not work, you can turn the > flag back on with execstack -s LIBRARY_PATH. > Otherwise, if you trust > nspluginscan to run correctly, you can change the > context of the executable to > unconfined_execmem_exec_t. "chcon -t > unconfined_execmem_exec_t > '/usr/bin/nspluginscan'" You must also change the > default file context files on > the system in order to preserve them even on a full > relabel. "semanage fcontext > -a -t unconfined_execmem_exec_t > '/usr/bin/nspluginscan'" > > Fix Command: > > chcon -t unconfined_execmem_exec_t > '/usr/bin/nspluginscan' > > Additional Information: > > Source Context > unconfined_u:unconfined_r:unconfined_t:SystemLow- > SystemHigh > Target Context > unconfined_u:unconfined_r:unconfined_t:SystemLow- > SystemHigh > Target Objects None [ process ] > Source nspluginscan > Source Path /usr/bin/nspluginscan > Port > Host localhost.localdomain > Source RPM Packages kdebase-4.0.3-9.fc9 > Target RPM Packages > Policy RPM > selinux-policy-3.3.1-45.fc10 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name allow_execstack > Host Name localhost.localdomain > Platform Linux > localhost.localdomain > > 2.6.26-0.17.rc3.fc10.i686 #1 SMP Sun May 18 > 19:05:03 EDT 2008 i686 > i686 > Alert Count 11 > First Seen Tue 05 Feb 2008 07:13:02 > AM CST > Last Seen Wed 21 May 2008 08:23:12 > AM CDT > Local ID > 7afb3a36-5b69-486c-a93b-02e714040250 > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC > msg=audit(1211376192.783:89): avc: denied { > execstack } for pid=3177 comm="nspluginscan" > scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > tclass=process > > host=localhost.localdomain type=SYSCALL > msg=audit(1211376192.783:89): arch=40000003 > syscall=125 success=no exit=-13 a0=bfeee000 a1=1000 > a2=1000007 a3=fffff000 items=0 ppid=3166 pid=3177 > auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 > egid=500 sgid=500 fsgid=500 tty=(none) ses=1 > comm="nspluginscan" exe="/usr/bin/nspluginscan" > subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > key=(null) > > You choice here is to first report a bug to who ever supplies the plugin. Then you can either do as the setroubleshoot tells you and turn on the allow_execstack boolean or you can confine nsplugin using allow_unconfined_nsplugin_transition. If you turn on nsplugin confinement you probably need to relabel your homedir restorecon -R -v ~ > > Summary: > > SELinux is preventing nm-system-setti > (NetworkManager_t) "read" to > ./PolicyKit.reload (system_crond_var_lib_t). > > Detailed Description: > > SELinux denied access requested by nm-system-setti. It > is not expected that this > access is required by nm-system-setti and this access > may signal an intrusion > attempt. It is also possible that the specific version > or configuration of the > application is causing it to require additional > access. > > Allowing Access: > > Sometimes labeling problems can cause SELinux denials. > You could try to restore > the default system file context for > ./PolicyKit.reload, > > restorecon -v './PolicyKit.reload' > > If this does not work, there is currently no automatic > way to allow this access. > Instead, you can generate a local policy module to > allow this access - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) > Or you can disable > SELinux protection altogether. Disabling SELinux > protection is not recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context > system_u:system_r:NetworkManager_t:SystemLow- > SystemHigh > Target Context > system_u:object_r:system_crond_var_lib_t > Target Objects ./PolicyKit.reload [ > file ] > Source nm-system-setti > Source Path > /usr/sbin/nm-system-settings > Port > Host localhost.localdomain > Source RPM Packages > NetworkManager-0.7.0-0.9.3.svn3675.fc10 > Target RPM Packages > Policy RPM > selinux-policy-3.3.1-45.fc10 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name localhost.localdomain > Platform Linux > localhost.localdomain > > 2.6.26-0.17.rc3.fc10.i686 #1 SMP Sun May 18 > 19:05:03 EDT 2008 i686 > i686 > Alert Count 3 > First Seen Wed 21 May 2008 08:21:22 > AM CDT > Last Seen Thu 22 May 2008 06:51:05 > AM CDT > Local ID > 842c746b-258d-45ad-bb2e-22c271d0b9ef > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC > msg=audit(1211457065.391:7): avc: denied { read } > for pid=2501 comm="nm-system-setti" > name="PolicyKit.reload" dev=dm-0 ino=443096 > scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:system_crond_var_lib_t:s0 > tclass=file > > host=localhost.localdomain type=SYSCALL > msg=audit(1211457065.391:7): arch=40000003 syscall=292 > success=no exit=-13 a0=6 a1=75d620 a2=106 a3=9b81f20 > items=0 ppid=2500 pid=2501 auid=4294967295 uid=0 gid=0 > euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) > ses=4294967295 comm="nm-system-setti" > exe="/usr/sbin/nm-system-settings" > subj=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 > key=(null) > > This is a bug which is fixed in F9 policy, but we have not been able to build policy for F10. It probably can be ignored. > > Summary: > > SELinux is preventing nm-system-setti > (NetworkManager_t) "getattr" to /dev/root > (fixed_disk_device_t). > > Detailed Description: > > SELinux denied access requested by nm-system-setti. It > is not expected that this > access is required by nm-system-setti and this access > may signal an intrusion > attempt. It is also possible that the specific version > or configuration of the > application is causing it to require additional > access. > > Allowing Access: > > Sometimes labeling problems can cause SELinux denials. > You could try to restore > the default system file context for /dev/root, > > restorecon -v '/dev/root' > > If this does not work, there is currently no automatic > way to allow this access. > Instead, you can generate a local policy module to > allow this access - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) > Or you can disable > SELinux protection altogether. Disabling SELinux > protection is not recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context > system_u:system_r:NetworkManager_t:SystemLow- > SystemHigh > Target Context > system_u:object_r:fixed_disk_device_t > Target Objects /dev/root [ blk_file ] > Source nm-system-setti > Source Path > /usr/sbin/nm-system-settings > Port > Host localhost.localdomain > Source RPM Packages > NetworkManager-0.7.0-0.9.3.svn3675.fc10 > Target RPM Packages > Policy RPM > selinux-policy-3.3.1-45.fc10 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name localhost.localdomain > Platform Linux > localhost.localdomain > > 2.6.26-0.17.rc3.fc10.i686 #1 SMP Sun May 18 > 19:05:03 EDT 2008 i686 > i686 > Alert Count 3 > First Seen Wed 21 May 2008 08:21:23 > AM CDT > Last Seen Thu 22 May 2008 06:51:07 > AM CDT > Local ID > 12a9ceb6-2b80-406f-86ce-eddd56016c6b > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC > msg=audit(1211457067.143:8): avc: denied { getattr } > for pid=2501 comm="nm-system-setti" path="/dev/root" > dev=tmpfs ino=402 > scontext=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:fixed_disk_device_t:s0 > tclass=blk_file > > host=localhost.localdomain type=SYSCALL > msg=audit(1211457067.143:8): arch=40000003 syscall=195 > success=no exit=-13 a0=415283d a1=bff720ec a2=3d8fff4 > a3=415283d items=0 ppid=1 pid=2501 auid=4294967295 > uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 > fsgid=0 tty=(none) ses=4294967295 > comm="nm-system-setti" > exe="/usr/sbin/nm-system-settings" > subj=system_u:system_r:NetworkManager_t:s0-s0:c0.c1023 > key=(null) > > Also can be ignored > > Summary: > > SELinux is preventing dbus-daemon (xdm_dbusd_t) > "execute" to ./gconfd-2 > (gconfd_exec_t). > > Detailed Description: > > SELinux denied access requested by dbus-daemon. It is > not expected that this > access is required by dbus-daemon and this access may > signal an intrusion > attempt. It is also possible that the specific version > or configuration of the > application is causing it to require additional > access. > > Allowing Access: > > Sometimes labeling problems can cause SELinux denials. > You could try to restore > the default system file context for ./gconfd-2, > > restorecon -v './gconfd-2' > > If this does not work, there is currently no automatic > way to allow this access. > Instead, you can generate a local policy module to > allow this access - see FAQ > (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) > Or you can disable > SELinux protection altogether. Disabling SELinux > protection is not recommended. > Please file a bug report > (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) > against this package. > > Additional Information: > > Source Context > system_u:system_r:xdm_dbusd_t:SystemLow-SystemHigh > Target Context > system_u:object_r:gconfd_exec_t > Target Objects ./gconfd-2 [ file ] > Source dbus-daemon > Source Path /bin/dbus-daemon > Port > Host localhost.localdomain > Source RPM Packages dbus-1.2.1-3.fc10 > Target RPM Packages > Policy RPM > selinux-policy-3.3.1-45.fc10 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name catchall_file > Host Name localhost.localdomain > Platform Linux > localhost.localdomain > > 2.6.26-0.17.rc3.fc10.i686 #1 SMP Sun May 18 > 19:05:03 EDT 2008 i686 > i686 > Alert Count 401 > First Seen Wed 21 May 2008 08:21:39 > AM CDT > Last Seen Thu 22 May 2008 06:55:49 > AM CDT > Local ID > 3d366e28-6abd-4740-b078-7ec3f331bce5 > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC > msg=audit(1211457349.146:165): avc: denied { execute > } for pid=3544 comm="dbus-daemon" name="gconfd-2" > dev=dm-0 ino=125235 > scontext=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:gconfd_exec_t:s0 > tclass=file > > host=localhost.localdomain type=SYSCALL > msg=audit(1211457349.146:165): arch=40000003 > syscall=11 success=no exit=-13 a0=b8ed76f0 a1=b8edffa8 > a2=b8ede8f8 a3=b8edbb58 items=0 ppid=3543 pid=3544 > auid=4294967295 uid=42 gid=42 euid=42 suid=42 fsuid=42 > egid=42 sgid=42 fsgid=42 tty=(none) ses=4294967295 > comm="dbus-daemon" exe="/bin/dbus-daemon" > subj=system_u:system_r:xdm_dbusd_t:s0-s0:c0.c1023 > key=(null) > > > > > > Summary: > > SELinux is preventing access to files with the label, > file_t. > > Detailed Description: > > SELinux permission checks on files labeled file_t are > being denied. file_t is > the context the SELinux kernel gives to files that do > not have a label. This > indicates a serious labeling problem. No files on an > SELinux box should ever be > labeled file_t. If you have just added a new disk > drive to the system you can > relabel it using the restorecon command. Otherwise you > should relabel the entire > files system. > > Allowing Access: > > You can execute the following command as root to > relabel your computer system: > "touch /.autorelabel; reboot" > > Additional Information: > > Source Context > system_u:system_r:tmpreaper_t > Target Context system_u:object_r:file_t > Target Objects ./kpc [ dir ] > Source tmpwatch > Source Path /usr/sbin/tmpwatch > Port > Host localhost.localdomain > Source RPM Packages tmpwatch-2.9.13-2 > Target RPM Packages > Policy RPM > selinux-policy-3.3.1-45.fc10 > Selinux Enabled True > Policy Type targeted > MLS Enabled True > Enforcing Mode Enforcing > Plugin Name file > Host Name localhost.localdomain > Platform Linux > localhost.localdomain > > 2.6.26-0.17.rc3.fc10.i686 #1 SMP Sun May 18 > 19:05:03 EDT 2008 i686 > i686 > Alert Count 12 > First Seen Thu 28 Feb 2008 08:12:12 > AM CST > Last Seen Thu 22 May 2008 08:15:01 > AM CDT > Local ID > 78c39dd1-e417-40e6-8056-ac3a90e9e235 > Line Numbers > > Raw Audit Messages > > host=localhost.localdomain type=AVC > msg=audit(1211462101.317:204): avc: denied { read } > for pid=14967 comm="tmpwatch" name="kpc" dev=dm-0 > ino=885859 scontext=system_u:system_r:tmpreaper_t:s0 > tcontext=system_u:object_r:file_t:s0 tclass=dir > > host=localhost.localdomain type=SYSCALL > msg=audit(1211462101.317:204): arch=40000003 syscall=5 > success=no exit=-13 a0=804ac62 a1=98800 a2=0 a3=0 > items=0 ppid=14964 pid=14967 auid=4294967295 uid=0 > gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 > tty=(none) ses=4294967295 comm="tmpwatch" > exe="/usr/sbin/tmpwatch" > subj=system_u:system_r:tmpreaper_t:s0 key=(null) > > > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list We will fix these as soon as we can update Rawhide Policy. From dwalsh at redhat.com Fri May 23 19:07:53 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 23 May 2008 15:07:53 -0400 Subject: selinux denials for new Fedora 9 install In-Reply-To: <958662.91871.qm@web52610.mail.re2.yahoo.com> References: <958662.91871.qm@web52610.mail.re2.yahoo.com> Message-ID: <48371609.30203@redhat.com> Antonio Olivares wrote: > --- Stephen Smalley wrote: > >> On Thu, 2008-05-22 at 17:24 -0700, Antonio Olivares >> wrote: >>> Dear all, >>> >>> I have installed Fedora 9 unto a new machine >> x86_64, it was working beautifully, I am at this >> time putting in updates. However I got some selinux >> denials from setroubleshoot deamon >>> Tomboy Notes shows this error in box >>> \begin{box} >>> >>> "Tomboy Notes" has quit unexpectedly >>> >>> If you reload a panel object, it will >> automatically be added back to the panel. >>> \end{box} >>> >>> The selinux denials follow: >>> >>> Advice/Suggestions/Comments are welcome :) >> The unlabeled_t indicates that whatever context >> tomboy was running in >> was made invalid by a policy update. You should >> have seen messages >> in /var/log/messages about invalidating contexts >> upon the policy load. >> >> Re-starting the process should get it into a valid >> context again. >> >> -- >> Stephen Smalley >> National Security Agency >> >> > > The updates fixed it :) > > Thanks! > > Antonio > > There is a bug in policy where mono_t is changed to unconfined_mono_t, So on upgrade mono_t becomes unlabeled_t. Tough to fix at this point. Only will happen if you upgrade while logged in. Starting tomboy again will work and run as unconfined_mono_t. > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From paul at city-fan.org Sun May 25 15:20:34 2008 From: paul at city-fan.org (Paul Howarth) Date: Sun, 25 May 2008 16:20:34 +0100 Subject: mock context Message-ID: <20080525162034.580251ef@metropolis.intra.city-fan.org> Is there some reason why the context type of /usr/sbin/mock has reverted to bin_t in F9 from unconfined_notrans_exec_t in F8? The latter still seems to work OK for me in F9 and significantly reduces the number of spurious AVCs when using mock. Paul. From eparis at redhat.com Tue May 27 00:53:10 2008 From: eparis at redhat.com (Eric Paris) Date: Mon, 26 May 2008 20:53:10 -0400 Subject: mock context In-Reply-To: <20080525162034.580251ef@metropolis.intra.city-fan.org> References: <20080525162034.580251ef@metropolis.intra.city-fan.org> Message-ID: <1211849590.3079.11.camel@localhost.localdomain> On Sun, 2008-05-25 at 16:20 +0100, Paul Howarth wrote: > Is there some reason why the context type of /usr/sbin/mock has reverted > to bin_t in F9 from unconfined_notrans_exec_t in F8? The latter still > seems to work OK for me in F9 and significantly reduces the number of > spurious AVCs when using mock. I think Dan did it after reading some of my messages about getting livecd's to work. I've since reverted it on my local livecd building systems and just haven't told dan I think unconfined_notrans_exec_t is the right way to go after all... Sorry, just still so much in progress with livecd and eventually mock... Dan, I think leave it as notrans for now and eventually i'm going to want a custom mock/livecd type to be determined at a later date... (at least that's my guess...) -Eric From paul at city-fan.org Tue May 27 12:19:38 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 27 May 2008 13:19:38 +0100 Subject: /tmp/lost+found on F9 Message-ID: <20080527131938.3cbcd970@metropolis.intra.city-fan.org> Being an old-fashioned sort of guy, I always create a separate partition (well, logical volume these days) for /tmp and various other top-level directories. Hence I have a directory /tmp/lost+found and every day I get an email from cron like this: Subject: Cron run-parts /etc/cron.daily Date: Tue, 27 May 2008 04:17:12 +0100 /etc/cron.daily/tmpwatch: error: failed to lstat /tmp/lost+found: Permission denied The following policy fixes this: policy_module(localmisc, 0.0.1) require { type tmpreaper_t; } # Allow tmpwatch to stat /tmp/lost+found files_getattr_lost_found_dirs(tmpreaper_t) Paul. From eparis at redhat.com Tue May 27 20:25:17 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 27 May 2008 16:25:17 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211314216.2691.59.camel@localhost.localdomain> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211314216.2691.59.camel@localhost.localdomain> Message-ID: <1211919917.3079.48.camel@localhost.localdomain> On Tue, 2008-05-20 at 16:10 -0400, Eric Paris wrote: > On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: > > On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > > > ***passwd: > > > running a system with selinux enforcing/permissive (doesn't matter) and > > > attempting to run livecd-creator with selinux --disabled results in > > > passwd espoloding. passwd called is_selinux_enabled() which says yes > > > since /proc/mounts has an selinuxfs and the passwd calls > > > selinux_enforcing() which explodes when it can't find > > > a /selinux/enforce. First discussion was to change /proc/mounts to hide > > > the selinuxfs, sounds like a good plan until I realize /proc/mounts is > > > actually link to /proc/self/mounts and that its getting way to complex > > > tying to set up FS namespaces or whatever this is going to take. Right > > > now I'm thinking of creating a /selinux with enforce=0 in all cases > > > inside the chroot, anyone see a problem with that? (I could also work > > > on fixing passwd, but i'm trying to be as 'backwards compatible' as > > > possible.... > > > > Wait - you are confusing /proc/mounts and /proc/filesystems. > > You are (once again) correct. Should be a lot easier to lie to :) I feel vindicated, I knew I saw that /proc/mounts was part of it.... init_selinuxmnt() is going to go through /proc/mounts inside the chroot and find an selinuxfs mounted back out on the host system. I think this in turn is going to cause is_selinux_enabled() to return that selinux is in fact enabled. No proof but what i know for sure is that cat /proc/filesystems | grep -v selinux > /tmp.filesystems mount -o bind /tmp.filesystems /chroot/proc/filesystems still caused passwd to fail because it thought selinux was enabled.... -Eric From sds at tycho.nsa.gov Tue May 27 20:48:22 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 27 May 2008 16:48:22 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211919917.3079.48.camel@localhost.localdomain> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211314216.2691.59.camel@localhost.localdomain> <1211919917.3079.48.camel@localhost.localdomain> Message-ID: <1211921302.19360.128.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-05-27 at 16:25 -0400, Eric Paris wrote: > On Tue, 2008-05-20 at 16:10 -0400, Eric Paris wrote: > > On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: > > > On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > > > > ***passwd: > > > > running a system with selinux enforcing/permissive (doesn't matter) and > > > > attempting to run livecd-creator with selinux --disabled results in > > > > passwd espoloding. passwd called is_selinux_enabled() which says yes > > > > since /proc/mounts has an selinuxfs and the passwd calls > > > > selinux_enforcing() which explodes when it can't find > > > > a /selinux/enforce. First discussion was to change /proc/mounts to hide > > > > the selinuxfs, sounds like a good plan until I realize /proc/mounts is > > > > actually link to /proc/self/mounts and that its getting way to complex > > > > tying to set up FS namespaces or whatever this is going to take. Right > > > > now I'm thinking of creating a /selinux with enforce=0 in all cases > > > > inside the chroot, anyone see a problem with that? (I could also work > > > > on fixing passwd, but i'm trying to be as 'backwards compatible' as > > > > possible.... > > > > > > Wait - you are confusing /proc/mounts and /proc/filesystems. > > > > You are (once again) correct. Should be a lot easier to lie to :) > > I feel vindicated, I knew I saw that /proc/mounts was part of it.... > > init_selinuxmnt() is going to go through /proc/mounts inside the chroot > and find an selinuxfs mounted back out on the host system. I think this > in turn is going to cause is_selinux_enabled() to return that selinux is > in fact enabled. No proof but what i know for sure is that > > cat /proc/filesystems | grep -v selinux > /tmp.filesystems > mount -o bind /tmp.filesystems /chroot/proc/filesystems > > still caused passwd to fail because it thought selinux was enabled.... Ah, yes - the optimization by Steve G changed is_selinux_enabled() to first check for a selinux_mnt previously set upon library init and uses that as indication of being enabled if present; otherwise, it falls back to checking /proc/filesystems. Regardless, as long as you create /selinux/enforce == 0, you're ok with passwd, right? -- Stephen Smalley National Security Agency From eparis at redhat.com Tue May 27 20:54:42 2008 From: eparis at redhat.com (Eric Paris) Date: Tue, 27 May 2008 16:54:42 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211921302.19360.128.camel@moss-spartans.epoch.ncsc.mil> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211314216.2691.59.camel@localhost.localdomain> <1211919917.3079.48.camel@localhost.localdomain> <1211921302.19360.128.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1211921682.3079.49.camel@localhost.localdomain> On Tue, 2008-05-27 at 16:48 -0400, Stephen Smalley wrote: > On Tue, 2008-05-27 at 16:25 -0400, Eric Paris wrote: > > On Tue, 2008-05-20 at 16:10 -0400, Eric Paris wrote: > > > On Tue, 2008-05-20 at 15:33 -0400, Stephen Smalley wrote: > > > > On Tue, 2008-05-20 at 15:12 -0400, Eric Paris wrote: > > > > > ***passwd: > > > > > running a system with selinux enforcing/permissive (doesn't matter) and > > > > > attempting to run livecd-creator with selinux --disabled results in > > > > > passwd espoloding. passwd called is_selinux_enabled() which says yes > > > > > since /proc/mounts has an selinuxfs and the passwd calls > > > > > selinux_enforcing() which explodes when it can't find > > > > > a /selinux/enforce. First discussion was to change /proc/mounts to hide > > > > > the selinuxfs, sounds like a good plan until I realize /proc/mounts is > > > > > actually link to /proc/self/mounts and that its getting way to complex > > > > > tying to set up FS namespaces or whatever this is going to take. Right > > > > > now I'm thinking of creating a /selinux with enforce=0 in all cases > > > > > inside the chroot, anyone see a problem with that? (I could also work > > > > > on fixing passwd, but i'm trying to be as 'backwards compatible' as > > > > > possible.... > > > > > > > > Wait - you are confusing /proc/mounts and /proc/filesystems. > > > > > > You are (once again) correct. Should be a lot easier to lie to :) > > > > I feel vindicated, I knew I saw that /proc/mounts was part of it.... > > > > init_selinuxmnt() is going to go through /proc/mounts inside the chroot > > and find an selinuxfs mounted back out on the host system. I think this > > in turn is going to cause is_selinux_enabled() to return that selinux is > > in fact enabled. No proof but what i know for sure is that > > > > cat /proc/filesystems | grep -v selinux > /tmp.filesystems > > mount -o bind /tmp.filesystems /chroot/proc/filesystems > > > > still caused passwd to fail because it thought selinux was enabled.... > > Ah, yes - the optimization by Steve G changed is_selinux_enabled() to > first check for a selinux_mnt previously set upon library init and uses > that as indication of being enabled if present; otherwise, it falls back > to checking /proc/filesystems. > > Regardless, as long as you create /selinux/enforce == 0, you're ok with > passwd, right? not sure, don't know how to get python to write a 0 without a null terminator or EOL or anything like that yet. docs.python.org FTW. -Eric From jdennis at redhat.com Tue May 27 21:13:48 2008 From: jdennis at redhat.com (John Dennis) Date: Tue, 27 May 2008 17:13:48 -0400 Subject: selinux + livecd-creator, May 20, 2008 In-Reply-To: <1211921682.3079.49.camel@localhost.localdomain> References: <1211310720.2691.47.camel@localhost.localdomain> <1211312016.7486.234.camel@moss-spartans.epoch.ncsc.mil> <1211314216.2691.59.camel@localhost.localdomain> <1211919917.3079.48.camel@localhost.localdomain> <1211921302.19360.128.camel@moss-spartans.epoch.ncsc.mil> <1211921682.3079.49.camel@localhost.localdomain> Message-ID: <483C798C.3040905@redhat.com> > not sure, don't know how to get python to write a 0 without a null > terminator or EOL or anything like that yet. docs.python.org FTW. > import os # open a file for writing f = os.open('/tmp/foobar', os.O_WRONLY) # create a string with a single NULL byte s = '\0' # write the string f.write(s) # close the file f.close() -- John Dennis From tibbs at math.uh.edu Wed May 28 01:33:50 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 27 May 2008 20:33:50 -0500 Subject: Confused about /var/www contexts Message-ID: I'm trying to understand why, on an updated F8 machine with selinux-policy-3.0.8-101.fc8.noarch and selinux-policy-targeted-3.0.8-101.fc8.noarch, /var/www/blah/cgi-bin doesn't end up as httpd_sys_script_exec_t. semanage fcontext -l says (among many other lines, of course): /var/www/[^/]*/cgi-bin(/.*)? all files system_u:object_r:httpd_sys_script_exec_t:s0 and yet: > sudo restorecon -R -v /var/www > ls -lZ /var/www/blah drwxr-xr-x root root unconfined_u:object_r:httpd_sys_content_t:s0 cgi-bin/ Am I misinterpreting the semanage output above? Is it possible that the following line, which appears earlier in the semanage output, is overriding? /var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0 - J< From paul at city-fan.org Wed May 28 07:59:10 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 28 May 2008 08:59:10 +0100 Subject: Confused about /var/www contexts In-Reply-To: References: Message-ID: <483D10CE.5070709@city-fan.org> Jason L Tibbitts III wrote: > I'm trying to understand why, on an updated F8 machine with > selinux-policy-3.0.8-101.fc8.noarch and > selinux-policy-targeted-3.0.8-101.fc8.noarch, /var/www/blah/cgi-bin > doesn't end up as httpd_sys_script_exec_t. > > semanage fcontext -l says (among many other lines, of course): > /var/www/[^/]*/cgi-bin(/.*)? all files system_u:object_r:httpd_sys_script_exec_t:s0 > > and yet: > > sudo restorecon -R -v /var/www > > ls -lZ /var/www/blah > drwxr-xr-x root root unconfined_u:object_r:httpd_sys_content_t:s0 cgi-bin/ > > Am I misinterpreting the semanage output above? Is it possible that > the following line, which appears earlier in the semanage output, is overriding? > /var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0 httpd_sys_content_t is a customizable type and will be left alone by restorecon unless you use -F. This may change before much longer though, given that it's easier to manage file contexts using semanage than it was when customizable types were introduced. Paul. From extremoburo at gmail.com Wed May 28 11:25:37 2008 From: extremoburo at gmail.com (Fabrizio Buratta) Date: Wed, 28 May 2008 13:25:37 +0200 Subject: Postfix pipe command and python scripts Message-ID: <48e871f70805280425o33bcf281u34b66e11fd21781a@mail.gmail.com> Hi everybody. This problem with selinux is exhausting my little head: I wrote a python script in order to provide out of office mail system to my postfix mailserver on Centos5. This script use sqlite module to connect to a db file and store some information about email replies, users etc. I invoke my script from /etc/postfix/master.cf : autoreply unix - n n - - pipe flags= user=vacation argv=/etc/config_files/postfix/autoresponder/vacation.py --deliver ${sender} -- ${recipient} whose permissions are: (ls -Z /etc/config_files/postfix/autoresponder/) -rwxrwxrwx vacation vacation system_u:object_r:etc_t database.db -rwxrwxrwx vacation vacation system_u:object_r:postfix_pipe_exec_t vacation.py The latter context was set by me to allow /urs/libexec/postfix/pipe to be able to execute my script (i wouldn't use this kind of dirty "tricks"). If i leave with its canonical context , postfix will complain saying it has not permission to execute vacation.py. Assuming this configuration right, my script is able to connect and retrieve information by the database (select statement ) but cannot write on it (database.db) . Take a look at audit log: type=SYSCALL msg=audit(1211975254.056:1341): arch=c000003e syscall=2 success=no exit=-13 a0=27f4ec0 a1=42 a2=1a4 a3=1 items=0 ppid=7203 pi\ d=7212 auid=0 uid=514 gid=514 euid=514 suid=514 fsuid=514 egid=514 sgid=514 fsgid=514 tty=(none) comm="python" exe="/usr/bin/python" subj=\ root:system_r:postfix_pipe_t:s0 key=(null) type=AVC msg=audit(1211975254.060:1342): avc: denied { write } for pid=7206 comm="python" name="localUsers.db" dev=dm-0 ino=262646 scon\ text=root:system_r:postfix_pipe_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=file I Guess python sqlite function cannot create journaling files which is required by sqlite to modify a database (i've also tried to add a PRAGMA statement fo change the temporary directory and python complains that it is not writable .....even /tmp dir) . Actually if i disable selinux everyhing works, but i don't want to do it at all. I have no ideas anymore to solve it out. If i create a new policy package form my audit.log using : audit2allow -i /var/log/audit/audit.log -m vacation > vacation.te etc.... and loading it with semodule the issue doesn't run away. Any help will be really appreciated Fabrizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at seekline.net Wed May 28 16:32:38 2008 From: stefan at seekline.net (Stefan Schulze Frielinghaus) Date: Wed, 28 May 2008 18:32:38 +0200 Subject: selinux-policy-3.3.1-51 and browser_confine_unconfined Message-ID: <1211992358.3150.7.camel@vogon> In policy version 3.3.1-42 a boolean browser_confine_unconfined exists to control firefox. Since version 3.3.1-51 it's gone and only one for guest exists. I checked the RPM changelog but nothing helpful. What happened to the other one? Does there also exist one for staff_t etc.? Best regards Stefan From stefan.schleifer at gmail.com Wed May 28 18:18:47 2008 From: stefan.schleifer at gmail.com (Stefan Schleifer) Date: Wed, 28 May 2008 20:18:47 +0200 Subject: Selfmade policy not getting enforced on Fedora9 Message-ID: <53D9B0EC-41BA-4DFA-ABD3-76C861CC11CD@gmail.com> Hey guys, As you might guess, I've a problem with my SELinux-policy under Fedora 9. I created a little test application 'demo' which reads some text from stdin and writes it in a config file /etc/hackbar/config.txt. Afterwarts, I developed a policy with types demo_t, demo_exec_t und demo_etc_t and allowed demo_exec_to to read/write demo_etc_t. Everything's fine. For testing purposes I changed /etc/hackbar/config.txt to type etc_t which demo_exec_t shouldn't be able to access as there doesn't exist an allow demo_exec_t r/w etc_t. [stefan at localhost policy]$ ls -Z /usr/local/bin/demo -rwsr-sr-x root root system_u:object_r:demo_exec_t:s0 /usr/local/ bin/demo [stefan at localhost policy]$ ls -Z /etc/hackbar/config.txt -rwxr-xr-x root root system_u:object_r:etc_t:s0 /etc/hackbar/ config.txt Again I ran the application but it is still allowed to change that file?! [stefan at localhost policy]$ /usr/local/bin/demo Enter text: foobar Read from file: foobar Regarding to standard UNIX permissions access should be granted as the demo-app has suid set, but shouldn't SELinux permitt access anyway in this case? SELinux is in enforcing mode. [stefan at localhost policy]$ /usr/sbin/sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 22 Policy from config file: targeted I'm rather confused... best regards, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From eparis at redhat.com Wed May 28 18:28:32 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 28 May 2008 14:28:32 -0400 Subject: Selfmade policy not getting enforced on Fedora9 In-Reply-To: <53D9B0EC-41BA-4DFA-ABD3-76C861CC11CD@gmail.com> References: <53D9B0EC-41BA-4DFA-ABD3-76C861CC11CD@gmail.com> Message-ID: <1211999312.3079.78.camel@localhost.localdomain> On Wed, 2008-05-28 at 20:18 +0200, Stefan Schleifer wrote: > Hey guys, > > As you might guess, I've a problem with my SELinux-policy under Fedora > 9. > > I created a little test application 'demo' which reads some text from > stdin and writes it in a config file /etc/hackbar/config.txt. > > Afterwarts, I developed a policy with types demo_t, demo_exec_t und > demo_etc_t and allowed demo_exec_to to read/write demo_etc_t. > Everything's fine. > > For testing purposes I changed /etc/hackbar/config.txt to type etc_t > which demo_exec_t shouldn't be able to access as there doesn't exist > an allow demo_exec_t r/w etc_t. > > > [stefan at localhost policy]$ ls -Z /usr/local/bin/demo > -rwsr-sr-x root root system_u:object_r:demo_exec_t:s0 /usr/local/ > bin/demo > [stefan at localhost policy]$ ls -Z /etc/hackbar/config.txt > -rwxr-xr-x root root system_u:object_r:etc_t:s0 /etc/hackbar/ > config.txt > > > Again I ran the application but it is still allowed to change that > file?! > > > [stefan at localhost policy]$ /usr/local/bin/demo > Enter text: foobar > Read from file: foobar > > > Regarding to standard UNIX permissions access should be granted as the > demo-app has suid set, but shouldn't SELinux permitt access anyway in > this case? > > SELinux is in enforcing mode. > > > [stefan at localhost policy]$ /usr/sbin/sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: enforcing > Policy version: 22 > Policy from config file: targeted > > > I'm rather confused... Are you sure you have the right transition rule from whatever you shell runs as ?unconfined_t? to demo_t if you run a demo_exec_t binary? What to you see from ps -efZ | grep demo while your program is running?? -Eric From dpquigl at tycho.nsa.gov Wed May 28 18:21:43 2008 From: dpquigl at tycho.nsa.gov (Dave Quigley) Date: Wed, 28 May 2008 14:21:43 -0400 Subject: Selfmade policy not getting enforced on Fedora9 In-Reply-To: <53D9B0EC-41BA-4DFA-ABD3-76C861CC11CD@gmail.com> References: <53D9B0EC-41BA-4DFA-ABD3-76C861CC11CD@gmail.com> Message-ID: <1211998903.5756.225.camel@moss-terrapins.epoch.ncsc.mil> On Wed, 2008-05-28 at 20:18 +0200, Stefan Schleifer wrote: > Hey guys, > > As you might guess, I've a problem with my SELinux-policy under Fedora > 9. > > I created a little test application 'demo' which reads some text from > stdin and writes it in a config file /etc/hackbar/config.txt. > > Afterwarts, I developed a policy with types demo_t, demo_exec_t und > demo_etc_t and allowed demo_exec_to to read/write demo_etc_t. > Everything's fine. > > For testing purposes I changed /etc/hackbar/config.txt to type etc_t > which demo_exec_t shouldn't be able to access as there doesn't exist > an allow demo_exec_t r/w etc_t. > > > [stefan at localhost policy]$ ls -Z /usr/local/bin/demo > -rwsr-sr-x root root system_u:object_r:demo_exec_t:s0 /usr/local/ > bin/demo > [stefan at localhost policy]$ ls -Z /etc/hackbar/config.txt > -rwxr-xr-x root root system_u:object_r:etc_t:s0 /etc/hackbar/ > config.txt > > > Again I ran the application but it is still allowed to change that > file?! > > > [stefan at localhost policy]$ /usr/local/bin/demo > Enter text: foobar > Read from file: foobar > > > Regarding to standard UNIX permissions access should be granted as the > demo-app has suid set, but shouldn't SELinux permitt access anyway in > this case? > > SELinux is in enforcing mode. > > > [stefan at localhost policy]$ /usr/sbin/sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: enforcing > Policy version: 22 > Policy from config file: targeted > > > I'm rather confused... > > best regards, > Stefan > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list If possible could you post your policy? Also are you sure that your program is running in demo_t? Dave From dwalsh at redhat.com Wed May 28 18:44:39 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 28 May 2008 14:44:39 -0400 Subject: Selfmade policy not getting enforced on Fedora9 In-Reply-To: <53D9B0EC-41BA-4DFA-ABD3-76C861CC11CD@gmail.com> References: <53D9B0EC-41BA-4DFA-ABD3-76C861CC11CD@gmail.com> Message-ID: <483DA817.8010401@redhat.com> Stefan Schleifer wrote: > Hey guys, > > As you might guess, I've a problem with my SELinux-policy under Fedora 9. > > I created a little test application 'demo' which reads some text from > stdin and writes it in a config file /etc/hackbar/config.txt. > > Afterwarts, I developed a policy with types demo_t, demo_exec_t und > demo_etc_t and allowed demo_exec_to to read/write demo_etc_t. > Everything's fine. > > For testing purposes I changed /etc/hackbar/config.txt to type etc_t > which demo_exec_t shouldn't be able to access as there doesn't exist an > allow demo_exec_t r/w etc_t. > > > [stefan at localhost policy]$ ls -Z /usr/local/bin/demo > -rwsr-sr-x root root system_u:object_r:demo_exec_t:s0 > /usr/local/bin/demo > [stefan at localhost policy]$ ls -Z /etc/hackbar/config.txt > -rwxr-xr-x root root system_u:object_r:etc_t:s0 > /etc/hackbar/config.txt > > > Again I ran the application but it is still allowed to change that file?! > > > [stefan at localhost policy]$ /usr/local/bin/demo > Enter text: foobar > Read from file: foobar > > > Regarding to standard UNIX permissions access should be granted as the > demo-app has suid set, but shouldn't SELinux permitt access anyway in > this case? > > SELinux is in enforcing mode. > > > [stefan at localhost policy]$ /usr/sbin/sestatus > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: enforcing > Mode from config file: enforcing > Policy version: 22 > Policy from config file: targeted > > > I'm rather confused... > > best regards, > Stefan > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list You need to define a transition rule from the domain that is executing the demo application. So if you are running as unconfined_t you will need a rule like domtrans_pattern(unconfined_t, demo_exec_t, demo_t) role unconfined_r types demo_t; From dwalsh at redhat.com Wed May 28 18:46:42 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 28 May 2008 14:46:42 -0400 Subject: selinux-policy-3.3.1-51 and browser_confine_unconfined In-Reply-To: <1211992358.3150.7.camel@vogon> References: <1211992358.3150.7.camel@vogon> Message-ID: <483DA892.4080707@redhat.com> Stefan Schulze Frielinghaus wrote: > In policy version 3.3.1-42 a boolean browser_confine_unconfined exists > to control firefox. Since version 3.3.1-51 it's gone and only one for > guest exists. I checked the RPM changelog but nothing helpful. What > happened to the other one? Does there also exist one for staff_t etc.? > > Best regards > Stefan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list No only for domains that explicitly call the mozilla_per_role_template() interface. Currently only xguest has this. So if you wanted to add it back for unconfined_t you could build a policy module with mozilla_per_role_template(unconfined, unconfined_t, unconfined_r) From dwalsh at redhat.com Wed May 28 18:56:16 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 28 May 2008 14:56:16 -0400 Subject: Postfix pipe command and python scripts In-Reply-To: <48e871f70805280425o33bcf281u34b66e11fd21781a@mail.gmail.com> References: <48e871f70805280425o33bcf281u34b66e11fd21781a@mail.gmail.com> Message-ID: <483DAAD0.6080300@redhat.com> Fabrizio Buratta wrote: > Hi everybody. > > This problem with selinux is exhausting my little head: > > I wrote a python script in order to provide out of office mail system to my > postfix mailserver on Centos5. This script use sqlite module to connect to a > db file and store some information about email replies, users etc. I invoke > my script from /etc/postfix/master.cf : > > autoreply unix - n n - - pipe > flags= user=vacation > argv=/etc/config_files/postfix/autoresponder/vacation.py --deliver ${sender} > -- ${recipient} > > whose permissions are: (ls -Z /etc/config_files/postfix/autoresponder/) > > -rwxrwxrwx vacation vacation system_u:object_r:etc_t database.db > -rwxrwxrwx vacation vacation system_u:object_r:postfix_pipe_exec_t > vacation.py > > The latter context was set by me to allow /urs/libexec/postfix/pipe to be > able to execute my script (i wouldn't use this kind of dirty "tricks"). If i > leave with its canonical context , postfix will > complain saying it has not permission to execute vacation.py. > > Assuming this configuration right, my script is able to connect and > retrieve information by the database (select statement ) but cannot write on > it (database.db) . Take a look at audit log: > > type=SYSCALL msg=audit(1211975254.056:1341): arch=c000003e syscall=2 > success=no exit=-13 a0=27f4ec0 a1=42 a2=1a4 a3=1 items=0 ppid=7203 pi\ > d=7212 auid=0 uid=514 gid=514 euid=514 suid=514 fsuid=514 egid=514 sgid=514 > fsgid=514 tty=(none) comm="python" exe="/usr/bin/python" subj=\ > root:system_r:postfix_pipe_t:s0 key=(null) > type=AVC msg=audit(1211975254.060:1342): avc: denied { write } for > pid=7206 comm="python" name="localUsers.db" dev=dm-0 ino=262646 scon\ > text=root:system_r:postfix_pipe_t:s0 tcontext=system_u:object_r:etc_t:s0 > tclass=file > > I Guess python sqlite function cannot create journaling files which is > required by sqlite to modify a database (i've also tried to add a PRAGMA > statement fo change the temporary directory and python complains that it is > not writable .....even /tmp dir) . Actually if i disable selinux everyhing > works, but i don't want to do it at all. > > I have no ideas anymore to solve it out. If i create a new policy package > form my audit.log using : > > audit2allow -i /var/log/audit/audit.log -m vacation > vacation.te etc.... > > and loading it with semodule the issue doesn't run away. > > Any help will be really appreciated > > Fabrizio > > > > ------------------------------------------------------------------------ > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Looking at the policy postfix_pipe_t is able to write to postfix_spool_t or postfix_var_run_t, So you could change the labeling of the file to one of those context. chcon -t postfix_var_run_t /etc/config_files/postfix/autoresponder/database.db To make this permanent semanage fcontext -a t postfix_var_run_t /etc/config_files/postfix/autoresponder/database.db Or you could move the database file to a directory that is already labeled postfix_spool_t or postfix_var_run_t. Or you can define a new type postfix_db_t and allow postfix_pipe to write to the file. From dwalsh at redhat.com Wed May 28 19:00:21 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 28 May 2008 15:00:21 -0400 Subject: /tmp/lost+found on F9 In-Reply-To: <20080527131938.3cbcd970@metropolis.intra.city-fan.org> References: <20080527131938.3cbcd970@metropolis.intra.city-fan.org> Message-ID: <483DABC5.70609@redhat.com> Paul Howarth wrote: > Being an old-fashioned sort of guy, I always create a separate > partition (well, logical volume these days) for /tmp and various other > top-level directories. Hence I have a directory /tmp/lost+found and > every day I get an email from cron like this: > > Subject: Cron run-parts /etc/cron.daily > Date: Tue, 27 May 2008 04:17:12 +0100 > > /etc/cron.daily/tmpwatch: > > error: failed to lstat /tmp/lost+found: Permission denied > > The following policy fixes this: > > policy_module(localmisc, 0.0.1) > > require { > type tmpreaper_t; > } > > # Allow tmpwatch to stat /tmp/lost+found > files_getattr_lost_found_dirs(tmpreaper_t) > > Paul. That is funny because the policy has files_dontaudit_getattr_lost_found_dirs(tmpreaper_t) So in order to get rid of the error, we need to allow it, which seems reasonable. > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From stefan.schleifer at gmail.com Wed May 28 19:23:53 2008 From: stefan.schleifer at gmail.com (Stefan Schleifer) Date: Wed, 28 May 2008 21:23:53 +0200 Subject: Selfmade policy not getting enforced on Fedora9 In-Reply-To: <483DA817.8010401@redhat.com> References: <53D9B0EC-41BA-4DFA-ABD3-76C861CC11CD@gmail.com> <483DA817.8010401@redhat.com> Message-ID: <845C290D-3C6E-411B-9665-7CF058DEF570@gmail.com> On May 28, 2008, at 8:44 PM, Daniel J Walsh wrote: > You need to define a transition rule from the domain that is executing > the demo application. > > So if you are running as unconfined_t you will need a rule like > > domtrans_pattern(unconfined_t, demo_exec_t, demo_t) > role unconfined_r types demo_t; Hey, You folks rock, thx a bunch. I forget the transition rule. As suggested, I added: domain_auto_trans(unconfined_t, demo_exec_t, demo_t); and now the app runs as demo_t: [stefan at localhost policy]$ ps -efZ | grep demo unconfined_u:unconfined_r:demo_t:s0-s0:c0.c1023 root 2856 2510 0 20:56 pts/2 00:00:00 /usr/local/bin/demo However, when I set SELinux to enforcing mode again, the app produces a seg fault, doesn't even coming to the point, where it writes to the file. Furthermore, the SELinux Troubleshooter doesn't alert me about having blocked something.. May I dare to ask, what's still missing? The policy as a whole: policy_module(demo,1.0.0) ######################################## # # Declarations # type demo_t; type demo_exec_t; application_domain(demo_t, demo_exec_t); domain_auto_trans(unconfined_t, demo_exec_t, demo_t); role unconfined_r types demo_t; role system_r types demo_t; require { type unconfined_t; role unconfined_r; } type demo_tmp_t; files_tmp_file(demo_tmp_t) type demo_etc_rw_t; files_type(demo_etc_rw_t) ######################################## # # demo local policy # ## internal communication is often done using fifo and unix sockets. allow demo_t self:fifo_file rw_file_perms; allow demo_t self:unix_stream_socket create_stream_socket_perms; files_read_etc_files(demo_t) libs_use_ld_so(demo_t) libs_use_shared_libs(demo_t) miscfiles_read_localization(demo_t) allow demo_t demo_tmp_t:file manage_file_perms; allow demo_t demo_tmp_t:dir create_dir_perms; files_tmp_filetrans(demo_t,demo_tmp_t, { file dir }) allow demo_t demo_etc_rw_t:file manage_file_perms; allow demo_t demo_etc_rw_t:dir manage_dir_perms; files_etc_filetrans(demo_t,demo_etc_rw_t, { file dir }) optional_policy(` gen_require(` type user_t; type user_devpts_t; type user_tty_device_t; role user_r; ') demo_run(user_t, user_r, { user_tty_device_t user_devpts_t }) ') Many thanks, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From stefan at seekline.net Wed May 28 19:37:41 2008 From: stefan at seekline.net (Stefan Schulze Frielinghaus) Date: Wed, 28 May 2008 21:37:41 +0200 Subject: selinux-policy-3.3.1-51 and browser_confine_unconfined In-Reply-To: <483DA892.4080707@redhat.com> References: <1211992358.3150.7.camel@vogon> <483DA892.4080707@redhat.com> Message-ID: <1212003461.2641.6.camel@vogon> On Wed, 2008-05-28 at 14:46 -0400, Daniel J Walsh wrote: [...] > So if you wanted to add it back for unconfined_t you could build a > policy module with > > mozilla_per_role_template(unconfined, unconfined_t, unconfined_r) That's it. Thanks! From eparis at redhat.com Wed May 28 19:51:01 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 28 May 2008 15:51:01 -0400 Subject: [RFC] Livecd-creator and selinux, we can play nice Message-ID: <1212004261.3079.87.camel@localhost.localdomain> So I've spent a fair bit of time the last 2 weeks trying to get livecd-creator and an selinux enforcing machine to play nicely together. It doesn't look like much, but from the point of view of the livecd creator I think the following patch is all we need. Working with rawhide as the host system I was able to build F8, F9 and rawhide livecd's with an enforcing machine. I wouldn't suggest jumping into enfocing builds just yet as there are still some policy issues I need to work out with the selinux people but I would like comments. Basically its quite simple, if selinux is on the host we create a fake /selinux which tells the install chroot lies. I've had to make some changes to some selinux libraries to support all this, but I think we are just about there. I'll probably backport some of the kernel changes to F9 after they are all tested and better settled but for now I'd like input on my livecd changes.... --- diff -Naupr /usr/lib/python2.5/site-packages/imgcreate/creator.py /root/imgcreate-5-28-08/creator.py --- /usr/lib/python2.5/site-packages/imgcreate/creator.py 2008-05-06 12:16:08.000000000 -0400 +++ /root/imgcreate-5-28-08/creator.py 2008-05-28 15:48:30.000000000 -0400 @@ -23,6 +23,7 @@ import sys import tempfile import shutil +import selinux import yum import rpm @@ -427,7 +428,7 @@ class ImageCreator(object): self._mount_instroot(base_on) - for d in ("/dev/pts", "/etc", "/boot", "/var/log", "/var/cache/yum"): + for d in ("/dev/pts", "/etc", "/boot", "/var/log", "/var/cache/yum", "/sys", "/proc", "/selinux"): makedirs(self._instroot + d) cachesrc = cachedir or (self.__builddir + "/yum-cache") @@ -439,10 +440,6 @@ class ImageCreator(object): (cachesrc, "/var/cache/yum")]: self.__bindmounts.append(BindChrootMount(f, self._instroot, dest)) - # /selinux should only be mounted if selinux is enabled (enforcing or permissive) - if kickstart.selinux_enabled(self.ks): - self.__bindmounts.append(BindChrootMount("/selinux", self._instroot, None)) - # Create minimum /dev origumask = os.umask(0000) devices = [('null', 1, 3, 0666), @@ -460,6 +457,37 @@ class ImageCreator(object): os.symlink('/proc/self/fd/2', self._instroot + "/dev/stderr") os.umask(origumask) + # if selinux exists on the host we need to lie to the chroot + if os.path.exists("/selinux/enforce"): + selinux_dir = self._instroot + "/selinux" + + # enforce=0 tells the chroot selinux is not enforcing + # policyvers=99 tell the chroot to make the highest version of policy it can + files = [('/enforce', '0'), + ('/policyvers', '99')] + for (file, value) in files: + fd = os.open(selinux_dir + file, os.O_WRONLY | os.O_TRUNC | os.O_CREAT) + os.write(fd, value) + os.close(fd) + + # we steal mls from the host system for now, might be best to always set it to 1???? + files = ["/selinux/mls"] + for file in files: + shutil.copyfile(file, self._instroot + file) + + # make /load -> /dev/null so chroot policy loads don't hurt anything + os.mknod(selinux_dir + "/load", 0666 | stat.S_IFCHR, os.makedev(1, 3)) + + # selinux is on whoo hooo + if kickstart.selinux_enabled(self.ks): + # label the fs like it is a root before the bind mounting + cmd = "/sbin/setfiles -F -r %s %s %s" % (self._instroot, selinux.selinux_file_context_path(), self._instroot) + os.system(cmd) + # these dumb things don't get magically fixed, so make the user generic + for f in ["/proc", "/sys", "/selinux"]: + cmd = "chcon -u system_u %s" % (self._instroot + f) + os.system(cmd) + self._do_bindmounts() os.symlink("../proc/mounts", self._instroot + "/etc/mtab") @@ -853,6 +881,18 @@ class LoopImageCreator(ImageCreator): (self._image, e)) def _unmount_instroot(self): + # if the system was running selinux clean up our lies + if os.path.exists("/selinux/enforce"): + files = ['/enforce', + '/policyvers', + '/mls', + '/load'] + for file in files: + try: + os.unlink(self._instroot + "/selinux" + file) + except OSError: + pass + if not self.__instloop is None: self.__instloop.cleanup() diff -Naupr /usr/lib/python2.5/site-packages/imgcreate/kickstart.py /root/imgcreate-5-28-08/kickstart.py --- /usr/lib/python2.5/site-packages/imgcreate/kickstart.py 2008-05-06 12:16:08.000000000 -0400 +++ /root/imgcreate-5-28-08/kickstart.py 2008-05-19 11:22:41.000000000 -0400 @@ -372,11 +372,11 @@ class SelinuxConfig(KickstartConfig): if ksselinux.selinux == ksconstants.SELINUX_DISABLED: return - if not os.path.exists(self.path("/sbin/restorecon")): + if os.path.exists(self.path("/sbin/restorecon")): + self.call(["/sbin/restorecon", "-l", "-v", "-r", "-F", "-e", "/proc", "-e", "/sys", "-e", "/dev", "-e", "/selinux", "/"]) + else: return - self.call(["/sbin/restorecon", "-l", "-v", "-r", "/"]) - def apply(self, ksselinux): if os.path.exists(self.path("/usr/sbin/lokkit")): args = ["/usr/sbin/lokkit", "-f", "--quiet", "--nostart"] From stefan.schleifer at gmail.com Wed May 28 20:03:33 2008 From: stefan.schleifer at gmail.com (Stefan Schleifer) Date: Wed, 28 May 2008 22:03:33 +0200 Subject: Selfmade policy not getting enforced on Fedora9 In-Reply-To: <845C290D-3C6E-411B-9665-7CF058DEF570@gmail.com> References: <53D9B0EC-41BA-4DFA-ABD3-76C861CC11CD@gmail.com> <483DA817.8010401@redhat.com> <845C290D-3C6E-411B-9665-7CF058DEF570@gmail.com> Message-ID: <05093F18-D011-46EE-A57B-4D5D330877A3@gmail.com> On May 28, 2008, at 9:23 PM, Stefan Schleifer wrote: > > Hey, > > You folks rock, thx a bunch. I forget the transition rule. As > suggested, I added: > > > domain_auto_trans(unconfined_t, demo_exec_t, demo_t); > > > and now the app runs as demo_t: > > > [stefan at localhost policy]$ ps -efZ | grep demo > unconfined_u:unconfined_r:demo_t:s0-s0:c0.c1023 root 2856 2510 0 > 20:56 pts/2 00:00:00 /usr/local/bin/demo > > (...) Hi, After running semodule -DB & semodule -B (as suggested by Daniel), I got a few messages in /var/log/audit/audit.log and managed to modify the policy in a way it works now. Closing, many many thanks to your quick and, of course, very helpful answers. Thx a lot! Best regards, Stefan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From notting at redhat.com Wed May 28 20:04:43 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 28 May 2008 16:04:43 -0400 Subject: [RFC] Livecd-creator and selinux, we can play nice In-Reply-To: <1212004261.3079.87.camel@localhost.localdomain> References: <1212004261.3079.87.camel@localhost.localdomain> Message-ID: <20080528200443.GA16939@nostromo.devel.redhat.com> Eric Paris (eparis at redhat.com) said: > So I've spent a fair bit of time the last 2 weeks trying to get > livecd-creator and an selinux enforcing machine to play nicely together. > It doesn't look like much, but from the point of view of the livecd > creator I think the following patch is all we need. Working with > rawhide as the host system I was able to build F8, F9 and rawhide > livecd's with an enforcing machine. > > I wouldn't suggest jumping into enfocing builds just yet as there are > still some policy issues I need to work out with the selinux people but > I would like comments. Basically its quite simple, if selinux is on the > host we create a fake /selinux which tells the install chroot lies. > I've had to make some changes to some selinux libraries to support all > this, but I think we are just about there. > > I'll probably backport some of the kernel changes to F9 after they are > all tested and better settled but for now I'd like input on my livecd > changes.... My concern is this is a normal occurence (needing a chroot) that you're only patching in one place. Do we code this same logic into mock? Into pungi? Into yum --installroot? Into the documentation for admins on how to set up a chroot? (Also, for general use, we need this in a RHEL 5 kernel. Fun!) Bill From eparis at redhat.com Wed May 28 20:11:23 2008 From: eparis at redhat.com (Eric Paris) Date: Wed, 28 May 2008 16:11:23 -0400 Subject: [RFC] Livecd-creator and selinux, we can play nice In-Reply-To: <20080528200443.GA16939@nostromo.devel.redhat.com> References: <1212004261.3079.87.camel@localhost.localdomain> <20080528200443.GA16939@nostromo.devel.redhat.com> Message-ID: <1212005483.3079.92.camel@localhost.localdomain> On Wed, 2008-05-28 at 16:04 -0400, Bill Nottingham wrote: > Eric Paris (eparis at redhat.com) said: > > So I've spent a fair bit of time the last 2 weeks trying to get > > livecd-creator and an selinux enforcing machine to play nicely together. > > It doesn't look like much, but from the point of view of the livecd > > creator I think the following patch is all we need. Working with > > rawhide as the host system I was able to build F8, F9 and rawhide > > livecd's with an enforcing machine. > > > > I wouldn't suggest jumping into enfocing builds just yet as there are > > still some policy issues I need to work out with the selinux people but > > I would like comments. Basically its quite simple, if selinux is on the > > host we create a fake /selinux which tells the install chroot lies. > > I've had to make some changes to some selinux libraries to support all > > this, but I think we are just about there. > > > > I'll probably backport some of the kernel changes to F9 after they are > > all tested and better settled but for now I'd like input on my livecd > > changes.... > > My concern is this is a normal occurence (needing a chroot) Yes and no.... > that you're > only patching in one place. Do we code this same logic into mock? Mock doesn't need any special labeling knowledge, mock just has to have policy that doesn't get in the way.... But mock is the next thing I'm going to start trying to find issues with. > Into > pungi? don't know pungi... > Into yum --installroot? possibly.... > Into the documentation for admins on > how to set up a chroot? where is this documentation? usually, no, but if the chroot is supposed to be drastically different than the host policy maybe... > (Also, for general use, we need this in a RHEL 5 kernel. Fun!) Yeah, I've heard that, and its likely to not be possible.... Once we all agree on how to make it work going forward we can talk about RHEL5. From paul at city-fan.org Wed May 28 22:02:33 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 28 May 2008 23:02:33 +0100 Subject: /tmp/lost+found on F9 In-Reply-To: <483DABC5.70609@redhat.com> References: <20080527131938.3cbcd970@metropolis.intra.city-fan.org> <483DABC5.70609@redhat.com> Message-ID: <20080528230233.14a85fc0@metropolis.intra.city-fan.org> On Wed, 28 May 2008 15:00:21 -0400 Daniel J Walsh wrote: > Paul Howarth wrote: > > Being an old-fashioned sort of guy, I always create a separate > > partition (well, logical volume these days) for /tmp and various > > other top-level directories. Hence I have a > > directory /tmp/lost+found and every day I get an email from cron > > like this: > > > > Subject: Cron run-parts /etc/cron.daily > > Date: Tue, 27 May 2008 04:17:12 +0100 > > > > /etc/cron.daily/tmpwatch: > > > > error: failed to lstat /tmp/lost+found: Permission denied > > > > The following policy fixes this: > > > > policy_module(localmisc, 0.0.1) > > > > require { > > type tmpreaper_t; > > } > > > > # Allow tmpwatch to stat /tmp/lost+found > > files_getattr_lost_found_dirs(tmpreaper_t) > > > > Paul. > That is funny because the policy has > > files_dontaudit_getattr_lost_found_dirs(tmpreaper_t) > > So in order to get rid of the error, we need to allow it, which seems > reasonable. Yes, the dontaudit made it that much harder to figure out what was going on but "semodule -BD" came to the rescue there. Paul. From skvidal at fedoraproject.org Wed May 28 22:14:55 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 28 May 2008 18:14:55 -0400 Subject: [RFC] Livecd-creator and selinux, we can play nice In-Reply-To: <1212005483.3079.92.camel@localhost.localdomain> References: <1212004261.3079.87.camel@localhost.localdomain> <20080528200443.GA16939@nostromo.devel.redhat.com> <1212005483.3079.92.camel@localhost.localdomain> Message-ID: <1212012895.3563.3.camel@cutter> On Wed, 2008-05-28 at 16:11 -0400, Eric Paris wrote: > > My concern is this is a normal occurence (needing a chroot) > > Yes and no.... > sure looks like we'd need to make sure: yum, mock and rpm all know how to set this up given how it would impact chroot creation. We may want to drop this back to the lowest level chroot creation. -sv From katzj at redhat.com Thu May 29 12:41:31 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 29 May 2008 08:41:31 -0400 Subject: [RFC] Livecd-creator and selinux, we can play nice In-Reply-To: <1212012895.3563.3.camel@cutter> References: <1212004261.3079.87.camel@localhost.localdomain> <20080528200443.GA16939@nostromo.devel.redhat.com> <1212005483.3079.92.camel@localhost.localdomain> <1212012895.3563.3.camel@cutter> Message-ID: <483EA47B.6080905@redhat.com> seth vidal wrote: > On Wed, 2008-05-28 at 16:11 -0400, Eric Paris wrote: >>> My concern is this is a normal occurence (needing a chroot) >> Yes and no.... > > sure looks like we'd need to make sure: > > yum, mock and rpm all know how to set this up given how it would impact > chroot creation. If we do so, then we should also make sure that all do things consistently wrt /dev for creating a chroot as well. And /proc and /sys. The reality is that the different applications do have a somewhat different idea of what they need/want out of their chroots and do things (or don't) accordingly. > We may want to drop this back to the lowest level chroot creation. Which isn't to say that we might not decide down the road to push it down the stack, but I don't know that livecd-creator is a bad place in the short to medium term as Eric continues looking at SELinux and chroot interactions (Right Eric? :-) Jeremy From katzj at redhat.com Thu May 29 12:51:12 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 29 May 2008 08:51:12 -0400 Subject: [RFC] Livecd-creator and selinux, we can play nice In-Reply-To: <1212004261.3079.87.camel@localhost.localdomain> References: <1212004261.3079.87.camel@localhost.localdomain> Message-ID: <483EA6C0.2090009@redhat.com> Eric Paris wrote: > So I've spent a fair bit of time the last 2 weeks trying to get > livecd-creator and an selinux enforcing machine to play nicely together. > It doesn't look like much, but from the point of view of the livecd > creator I think the following patch is all we need. Working with > rawhide as the host system I was able to build F8, F9 and rawhide > livecd's with an enforcing machine. > > I wouldn't suggest jumping into enfocing builds just yet as there are > still some policy issues I need to work out with the selinux people but > I would like comments. Basically its quite simple, if selinux is on the > host we create a fake /selinux which tells the install chroot lies. > I've had to make some changes to some selinux libraries to support all > this, but I think we are just about there. Very cool and definitely long needed. Thanks for taking the time to really dive into this. And this is far simpler than the approach I had started looking at once upon a time (... which involved fuse) A few comments on the patch > diff -Naupr /usr/lib/python2.5/site-packages/imgcreate/creator.py /root/imgcreate-5-28-08/creator.py > --- /usr/lib/python2.5/site-packages/imgcreate/creator.py 2008-05-06 12:16:08.000000000 -0400 > +++ /root/imgcreate-5-28-08/creator.py 2008-05-28 15:48:30.000000000 -0400 > @@ -460,6 +457,37 @@ class ImageCreator(object): > os.symlink('/proc/self/fd/2', self._instroot + "/dev/stderr") > os.umask(origumask) > > + # if selinux exists on the host we need to lie to the chroot > + if os.path.exists("/selinux/enforce"): > + selinux_dir = self._instroot + "/selinux" > + > + # enforce=0 tells the chroot selinux is not enforcing > + # policyvers=99 tell the chroot to make the highest version of policy it can > + files = [('/enforce', '0'), > + ('/policyvers', '99')] Does the kernel guarantee that 99 will be the highest version of policy? Not that it likely matters much. Also, having this as a tuple rather than a list makes it marginally faster since we're never going to modify it > + for (file, value) in files: > + fd = os.open(selinux_dir + file, os.O_WRONLY | os.O_TRUNC | os.O_CREAT) > + os.write(fd, value) > + os.close(fd) > + > + # we steal mls from the host system for now, might be best to always set it to 1???? > + files = ["/selinux/mls"] > + for file in files: > + shutil.copyfile(file, self._instroot + file) > + > + # make /load -> /dev/null so chroot policy loads don't hurt anything > + os.mknod(selinux_dir + "/load", 0666 | stat.S_IFCHR, os.makedev(1, 3)) This being the big win :) > + # selinux is on whoo hooo > + if kickstart.selinux_enabled(self.ks): > + # label the fs like it is a root before the bind mounting > + cmd = "/sbin/setfiles -F -r %s %s %s" % (self._instroot, selinux.selinux_file_context_path(), self._instroot) > + os.system(cmd) > + # these dumb things don't get magically fixed, so make the user generic > + for f in ["/proc", "/sys", "/selinux"]: > + cmd = "chcon -u system_u %s" % (self._instroot + f) > + os.system(cmd) os.system is generally not preferred -- using the subprocess module is a lot safer. Also, overall it might be nice to encapsulate the /selinux creation here into its own __create_selinuxfs() method that gets called. /me makes a note to do that to the /dev creation too. > @@ -853,6 +881,18 @@ class LoopImageCreator(ImageCreator): > (self._image, e)) > > def _unmount_instroot(self): > + # if the system was running selinux clean up our lies > + if os.path.exists("/selinux/enforce"): > + files = ['/enforce', > + '/policyvers', > + '/mls', > + '/load'] Again a tuple versus a list > + for file in files: > + try: > + os.unlink(self._instroot + "/selinux" + file) > + except OSError: > + pass And again having it in a method is probably the nice thing to do. And I know I said to stick it into _unmount_instroot, but seeing where you've put the mount side, it probably makes more sense in unmount() instead Jeremy From dwalsh at redhat.com Thu May 29 14:56:39 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 29 May 2008 10:56:39 -0400 Subject: [RFC] Livecd-creator and selinux, we can play nice In-Reply-To: <20080528200443.GA16939@nostromo.devel.redhat.com> References: <1212004261.3079.87.camel@localhost.localdomain> <20080528200443.GA16939@nostromo.devel.redhat.com> Message-ID: <483EC427.4060009@redhat.com> Bill Nottingham wrote: > Eric Paris (eparis at redhat.com) said: >> So I've spent a fair bit of time the last 2 weeks trying to get >> livecd-creator and an selinux enforcing machine to play nicely together. >> It doesn't look like much, but from the point of view of the livecd >> creator I think the following patch is all we need. Working with >> rawhide as the host system I was able to build F8, F9 and rawhide >> livecd's with an enforcing machine. >> >> I wouldn't suggest jumping into enfocing builds just yet as there are >> still some policy issues I need to work out with the selinux people but >> I would like comments. Basically its quite simple, if selinux is on the >> host we create a fake /selinux which tells the install chroot lies. >> I've had to make some changes to some selinux libraries to support all >> this, but I think we are just about there. >> >> I'll probably backport some of the kernel changes to F9 after they are >> all tested and better settled but for now I'd like input on my livecd >> changes.... > > My concern is this is a normal occurence (needing a chroot) that you're > only patching in one place. Do we code this same logic into mock? Into > pungi? Into yum --installroot? Into the documentation for admins on > how to set up a chroot? > > (Also, for general use, we need this in a RHEL 5 kernel. Fun!) > > Bill > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list Well I think we need to do a couple of these to figure out the common requirements. I envision mock to be quite different then livecd. I think we need to full the mock chroot to think SELinux is disabled and to do no labeling in the chroot. This would allow us to confine the mock process to be able to write to the chroot and label the chroot mock_rw_t. We could then use SELinux to prevent mock environments from breaking out of the chroot, and stop mock environments from doing evil network things within the chroot. In livecd we need to be able to put down labels that the host machine does not understand. From dwalsh at redhat.com Thu May 29 15:00:05 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 29 May 2008 11:00:05 -0400 Subject: mock context In-Reply-To: <1211849590.3079.11.camel@localhost.localdomain> References: <20080525162034.580251ef@metropolis.intra.city-fan.org> <1211849590.3079.11.camel@localhost.localdomain> Message-ID: <483EC4F5.7060706@redhat.com> Eric Paris wrote: > On Sun, 2008-05-25 at 16:20 +0100, Paul Howarth wrote: >> Is there some reason why the context type of /usr/sbin/mock has reverted >> to bin_t in F9 from unconfined_notrans_exec_t in F8? The latter still >> seems to work OK for me in F9 and significantly reduces the number of >> spurious AVCs when using mock. > > I think Dan did it after reading some of my messages about getting > livecd's to work. I've since reverted it on my local livecd building > systems and just haven't told dan I think unconfined_notrans_exec_t is > the right way to go after all... > > Sorry, just still so much in progress with livecd and eventually mock... > > Dan, I think leave it as notrans for now and eventually i'm going to > want a custom mock/livecd type to be determined at a later date... > > (at least that's my guess...) > > -Eric > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list I changed it back in -58, but I want to generate a mock file context with limited access to network for example. From notting at redhat.com Thu May 29 15:01:17 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 29 May 2008 11:01:17 -0400 Subject: [RFC] Livecd-creator and selinux, we can play nice In-Reply-To: <483EC427.4060009@redhat.com> References: <1212004261.3079.87.camel@localhost.localdomain> <20080528200443.GA16939@nostromo.devel.redhat.com> <483EC427.4060009@redhat.com> Message-ID: <20080529150117.GA13595@nostromo.devel.redhat.com> Daniel J Walsh (dwalsh at redhat.com) said: > Well I think we need to do a couple of these to figure out the common > requirements. > > I envision mock to be quite different then livecd. I think we need to > full the mock chroot to think SELinux is disabled and to do no labeling > in the chroot. This would allow us to confine the mock process to be > able to write to the chroot and label the chroot mock_rw_t. We could > then use SELinux to prevent mock environments from breaking out of the > chroot, and stop mock environments from doing evil network things within > the chroot. > > In livecd we need to be able to put down labels that the host machine > does not understand. The problem is that mock can be used to do non-build things. (For example, creating the anaconda install images.) Bill From paul at city-fan.org Thu May 29 15:08:05 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 29 May 2008 16:08:05 +0100 Subject: mock context In-Reply-To: <483EC4F5.7060706@redhat.com> References: <20080525162034.580251ef@metropolis.intra.city-fan.org> <1211849590.3079.11.camel@localhost.localdomain> <483EC4F5.7060706@redhat.com> Message-ID: <483EC6D5.6030501@city-fan.org> Daniel J Walsh wrote: > Eric Paris wrote: >> On Sun, 2008-05-25 at 16:20 +0100, Paul Howarth wrote: >>> Is there some reason why the context type of /usr/sbin/mock has reverted >>> to bin_t in F9 from unconfined_notrans_exec_t in F8? The latter still >>> seems to work OK for me in F9 and significantly reduces the number of >>> spurious AVCs when using mock. >> I think Dan did it after reading some of my messages about getting >> livecd's to work. I've since reverted it on my local livecd building >> systems and just haven't told dan I think unconfined_notrans_exec_t is >> the right way to go after all... >> >> Sorry, just still so much in progress with livecd and eventually mock... >> >> Dan, I think leave it as notrans for now and eventually i'm going to >> want a custom mock/livecd type to be determined at a later date... >> >> (at least that's my guess...) >> >> -Eric > > I changed it back in -58, but I want to generate a mock file context > with limited access to network for example. Please make network access restrictions tunable by a boolean; I tend to leave network tests enabled in the packages I build locally in mock. Paul. From dwalsh at redhat.com Thu May 29 17:39:55 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 29 May 2008 13:39:55 -0400 Subject: mock context In-Reply-To: <483EC6D5.6030501@city-fan.org> References: <20080525162034.580251ef@metropolis.intra.city-fan.org> <1211849590.3079.11.camel@localhost.localdomain> <483EC4F5.7060706@redhat.com> <483EC6D5.6030501@city-fan.org> Message-ID: <483EEA6B.3050002@redhat.com> Paul Howarth wrote: > Daniel J Walsh wrote: >> Eric Paris wrote: >>> On Sun, 2008-05-25 at 16:20 +0100, Paul Howarth wrote: >>>> Is there some reason why the context type of /usr/sbin/mock has >>>> reverted >>>> to bin_t in F9 from unconfined_notrans_exec_t in F8? The latter still >>>> seems to work OK for me in F9 and significantly reduces the number of >>>> spurious AVCs when using mock. >>> I think Dan did it after reading some of my messages about getting >>> livecd's to work. I've since reverted it on my local livecd building >>> systems and just haven't told dan I think unconfined_notrans_exec_t is >>> the right way to go after all... >>> >>> Sorry, just still so much in progress with livecd and eventually mock... >>> >>> Dan, I think leave it as notrans for now and eventually i'm going to >>> want a custom mock/livecd type to be determined at a later date... >>> >>> (at least that's my guess...) >>> >>> -Eric >> >> I changed it back in -58, but I want to generate a mock file context >> with limited access to network for example. > > Please make network access restrictions tunable by a boolean; I tend to > leave network tests enabled in the packages I build locally in mock. > > Paul. Yes this would definitely be a tunable. I am just trying to think of ways we could protect the Fedora Infrastructure. From mike.clarkson at baesystems.com Thu May 29 20:15:26 2008 From: mike.clarkson at baesystems.com (Clarkson, Mike R (US SSA)) Date: Thu, 29 May 2008 13:15:26 -0700 Subject: fs_search_nfs lacks getattr Message-ID: <0794F277152EF94AA637E3AECF5CB70FB9E2B0@blums0042.bluelnk.net> Shouldn't this have search_dir_perms to add in getattr? ######################################## ## ## Search directories on a NFS filesystem. ## ## ## ## Domain allowed access. ## ## # interface(`fs_search_nfs',` gen_require(` type nfs_t; ') allow $1 nfs_t:dir search; ') This is from RHEL5.1. There are no other interfaces to add getattr unless I want to move to full read access with fs_list_nfs. From extremoburo at gmail.com Fri May 30 08:05:38 2008 From: extremoburo at gmail.com (Fabrizio Buratta) Date: Fri, 30 May 2008 10:05:38 +0200 Subject: Postfix pipe command and python scripts In-Reply-To: <48e871f70805290641r1f97ca22t4434ea7d750f7393@mail.gmail.com> References: <48e871f70805280425o33bcf281u34b66e11fd21781a@mail.gmail.com> <483DAAD0.6080300@redhat.com> <48e871f70805290641r1f97ca22t4434ea7d750f7393@mail.gmail.com> Message-ID: <48e871f70805300105g5bfce93cufe5ebd42b98f6e3c@mail.gmail.com> > Looking at the policy postfix_pipe_t is able to write to postfix_spool_t > or postfix_var_run_t, So you could change the labeling of the file to > one of those context. > I realized that postfix_pipe_t ( postfix/pipe command actually runs under postfix_pipe_exec_t context ) cannot do write, add_name , remove_name and unlink either postfix_spool_t or postfix_var_run_t therefore i had to set it myself. I'll resume what i've done : 1 - I put my db in /var/spool/postfix/vacation 2 - chcon -u system_u -r object_r -t postfix_spool_t -R /var/spool/postfix/vacation 3 - chown -R postfix:vacation /var/spool/postfix/vacation 4 - i created vacation.te : module vacationpolicy 1.0; require { type postfix_pipe_t; type postfix_spool_t; class dir { write remove_name add_name }; class file { create unlink }; } #============= postfix_pipe_t ============== allow postfix_pipe_t postfix_spool_t:dir { write remove_name add_name }; allow postfix_pipe_t postfix_spool_t:file { create unlink }; 5 - I created a package and installed it It worked Thanks for your help! Fabrizio