From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb Subject: Re: Re: [patch] Full relabel audit event Date: Tue, 30 May 2006 10:08:16 -0400 Message-ID: <200605301008.16564.sgrubb@redhat.com> References: <1148590901.8828.22.camel@code.and.org> <1148665647.8828.36.camel@code.and.org> <1148666614.20976.258.camel@moss-spartans.epoch.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1148666614.20976.258.camel@moss-spartans.epoch.ncsc.mil> Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: redhat-lspp-bounces@redhat.com Errors-To: redhat-lspp-bounces@redhat.com To: redhat-lspp@redhat.com Cc: James Antill , linux-audit@redhat.com, Stephen Smalley , selinux@tycho.nsa.gov List-Id: linux-audit@redhat.com On Friday 26 May 2006 14:03, Stephen Smalley wrote: > I don't see the point when a) you only want it in that one case, We do this already in several places. For example, we instrumented usermo= d,=20 but not chage. It was documented in the Security Target that usermod shou= ld=20 be used to alter user account attributes. > b) it doesn't prevent trivial bypass in any way (e.g. by using restorec= on, > by rolling your own program to do it, by running setfiles on /* rather = than > just /, ...), and=20 Its not meant to be bulletproof. Its purpose is to document that a full=20 relabel has occurred before any user can log in. During the boot process,= no=20 one can log in so nothing evil should happen. > Note btw that setfiles already provides three different ways to log > actual changes in file contexts, the original -v verbose mode, and the > -l (log via syslog) and -o (log to file) modes introduced later > by Red Hat. =C2=A0That at least provides detailed information that the = caller > couldn't determine otherwise. It was determined that we only need 1 record, not all the changes. -Steve -- redhat-lspp mailing list redhat-lspp@redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve Grubb To: redhat-lspp@redhat.com Subject: Re: [redhat-lspp] Re: [patch] Full relabel audit event Date: Tue, 30 May 2006 10:08:16 -0400 Cc: Stephen Smalley , James Antill , linux-audit@redhat.com, selinux@tycho.nsa.gov References: <1148590901.8828.22.camel@code.and.org> <1148665647.8828.36.camel@code.and.org> <1148666614.20976.258.camel@moss-spartans.epoch.ncsc.mil> In-Reply-To: <1148666614.20976.258.camel@moss-spartans.epoch.ncsc.mil> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Message-Id: <200605301008.16564.sgrubb@redhat.com> Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov On Friday 26 May 2006 14:03, Stephen Smalley wrote: > I don't see the point when a) you only want it in that one case, We do this already in several places. For example, we instrumented usermod, but not chage. It was documented in the Security Target that usermod should be used to alter user account attributes. > b) it doesn't prevent trivial bypass in any way (e.g. by using restorecon, > by rolling your own program to do it, by running setfiles on /* rather than > just /, ...), and Its not meant to be bulletproof. Its purpose is to document that a full relabel has occurred before any user can log in. During the boot process, no one can log in so nothing evil should happen. > Note btw that setfiles already provides three different ways to log > actual changes in file contexts, the original -v verbose mode, and the > -l (log via syslog) and -o (log to file) modes introduced later > by Red Hat.  That at least provides detailed information that the caller > couldn't determine otherwise. It was determined that we only need 1 record, not all the changes. -Steve -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.