From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id t3NLEEnj010547 for ; Thu, 23 Apr 2015 17:14:14 -0400 From: "Spector, Aaron" To: "SELinux (selinux@tycho.nsa.gov)" Subject: Switching to enforcing mode introduces new policy issues? Date: Thu, 23 Apr 2015 21:14:07 +0000 Message-ID: <363d72e72db54ed2a93f39f76d1811fd@MIVEXUSR1N01.corpzone.internalzone.com> Content-Type: multipart/alternative; boundary="_000_363d72e72db54ed2a93f39f76d1811fdMIVEXUSR1N01corpzoneint_" MIME-Version: 1.0 List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --_000_363d72e72db54ed2a93f39f76d1811fdMIVEXUSR1N01corpzoneint_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've been working on writing my first policy for SELinux and I've hit a bit= of a snag. I've gotten the policy clean in permissive mode, but when I swa= p the system over to enforcing, a whole new set of policy issues crop up. E= verything I've read says this isn't to be expected so I'm a bit confused as= to what's happening. Output from sestatus when in permissive mode is: SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: default Current mode: permissive Mode from config file: permissive Policy MLS status: enabled Policy deny_unknown status: denied Max kernel policy version: 29 I'm running a version 26 policy and a 3.16.7 kernel. It seems like the majority of the new deny audits are about the need for se= arch permissions on directories between types that already have what I beli= eve are the necessary file permissions. So far what I've had to do to get around it is to add to my policy, but tha= t doesn't seem like that should be necessary. If the audit is clean in perm= issive mode, why isn't it clean in enforcing? Is it possible that I'm missing policy deny audits when it's in permissive = mode? Thanks, -Aaron --_000_363d72e72db54ed2a93f39f76d1811fdMIVEXUSR1N01corpzoneint_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I’ve been working on writing my first policy f= or SELinux and I’ve hit a bit of a snag. I’ve gotten the policy= clean in permissive mode, but when I swap the system over to enforcing, a = whole new set of policy issues crop up. Everything I’ve read says this isn’t to be expected so I’m a bit confused as t= o what’s happening. Output from sestatus when in permissive mode is:<= o:p>

 

SELinux status:      &= nbsp;          enabled

SELinuxfs mount:      =           /sys/fs/selinux=

SELinux root directory:     = ;    /etc/selinux

Loaded policy name:     &nb= sp;       default

Current mode:      &nb= sp;            permi= ssive

Mode from config file:     =      permissive

Policy MLS status:     &nbs= p;        enabled

Policy deny_unknown status:     = denied

Max kernel policy version:    &n= bsp; 29

 

I’m running a version 26 policy and a 3.16.7 k= ernel.

 

It seems like the majority of the new deny audits ar= e about the need for search permissions on directories between types that a= lready have what I believe are the necessary file permissions.

 

So far what I’ve had to do to get around it is= to add to my policy, but that doesn’t seem like that should be neces= sary. If the audit is clean in permissive mode, why isn’t it clean in= enforcing?

 

Is it possible that I’m missing policy deny au= dits when it’s in permissive mode?

 

 

Thanks,

 

-Aaron

 

--_000_363d72e72db54ed2a93f39f76d1811fdMIVEXUSR1N01corpzoneint_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id t3NMJqLY014851 for ; Thu, 23 Apr 2015 18:19:52 -0400 Received: by oblw8 with SMTP id w8so24913147obl.0 for ; Thu, 23 Apr 2015 15:19:50 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <363d72e72db54ed2a93f39f76d1811fd@MIVEXUSR1N01.corpzone.internalzone.com> References: <363d72e72db54ed2a93f39f76d1811fd@MIVEXUSR1N01.corpzone.internalzone.com> Date: Thu, 23 Apr 2015 18:19:50 -0400 Message-ID: Subject: Re: Switching to enforcing mode introduces new policy issues? From: Paul Moore To: "Spector, Aaron" Content-Type: text/plain; charset=UTF-8 Cc: "SELinux \(selinux@tycho.nsa.gov\)" List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: On Thu, Apr 23, 2015 at 5:14 PM, Spector, Aaron wrote: > Hi all, > > I’ve been working on writing my first policy for SELinux and I’ve hit a bit > of a snag. I’ve gotten the policy clean in permissive mode, but when I swap > the system over to enforcing, a whole new set of policy issues crop up. > Everything I’ve read says this isn’t to be expected so I’m a bit confused as > to what’s happening. {snip} > So far what I’ve had to do to get around it is to add to my policy, but that > doesn’t seem like that should be necessary. If the audit is clean in > permissive mode, why isn’t it clean in enforcing? > > Is it possible that I’m missing policy deny audits when it’s in permissive > mode? It's important to remember that when you are in permissive mode you will only see a given SELinux AVC denial *once*, after that it will not be reported until the AVC is reset. My two favorite ways of resetting the SELinux AVC are to run either 'load_policy' or toggle the system from permissive into enforcing and then back into permissive mode. Try that and I suspect that will solve your problem. -Paul -- paul moore www.paul-moore.com From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id t3O4CZgw001617 for ; Fri, 24 Apr 2015 00:12:36 -0400 From: "Spector, Aaron" To: Paul Moore Subject: RE: Switching to enforcing mode introduces new policy issues? Date: Fri, 24 Apr 2015 04:12:25 +0000 Message-ID: References: <363d72e72db54ed2a93f39f76d1811fd@MIVEXUSR1N01.corpzone.internalzone.com> In-Reply-To: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Cc: "SELinux \(selinux@tycho.nsa.gov\)" List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: That sounds like an idea, I'll have to give it a shot. To add a bit more information, I'm seeing a bunch of these changes happen during the boot process in init and I would assume the AVC is cleared between reboots - I've tweaked and added some things there for experimentation. I can boot my system up in permissive and see no problems, but when I restart it in enforcing I start seeing brand new policy violations, things I haven't seen before. It seems odd that the same boot sequence would result in such different behavior. -Aaron -----Original Message----- From: Paul Moore [mailto:paul@paul-moore.com] Sent: Thursday, April 23, 2015 5:20 PM To: Spector, Aaron Cc: SELinux (selinux@tycho.nsa.gov) Subject: Re: Switching to enforcing mode introduces new policy issues? On Thu, Apr 23, 2015 at 5:14 PM, Spector, Aaron wrote: > Hi all, > > I’ve been working on writing my first policy for SELinux and I’ve hit > a bit of a snag. I’ve gotten the policy clean in permissive mode, but > when I swap the system over to enforcing, a whole new set of policy issues crop up. > Everything I’ve read says this isn’t to be expected so I’m a bit > confused as to what’s happening. {snip} > So far what I’ve had to do to get around it is to add to my policy, > but that doesn’t seem like that should be necessary. If the audit is > clean in permissive mode, why isn’t it clean in enforcing? > > Is it possible that I’m missing policy deny audits when it’s in > permissive mode? It's important to remember that when you are in permissive mode you will only see a given SELinux AVC denial *once*, after that it will not be reported until the AVC is reset. My two favorite ways of resetting the SELinux AVC are to run either 'load_policy' or toggle the system from permissive into enforcing and then back into permissive mode. Try that and I suspect that will solve your problem. -Paul -- paul moore www.paul-moore.com From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id t3O4rfpg003395 for ; Fri, 24 Apr 2015 00:53:41 -0400 Received: by qcpm10 with SMTP id m10so20534597qcp.3 for ; Thu, 23 Apr 2015 21:53:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <363d72e72db54ed2a93f39f76d1811fd@MIVEXUSR1N01.corpzone.internalzone.com> Date: Fri, 24 Apr 2015 10:23:40 +0530 Message-ID: Subject: Re: Switching to enforcing mode introduces new policy issues? From: Gaurav Gangwar To: "Spector, Aaron" Content-Type: multipart/alternative; boundary=001a1149572412913b0514712e8d Cc: "SELinux \(selinux@tycho.nsa.gov\)" List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --001a1149572412913b0514712e8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Aaron, also check if you have modified the selinux code also keep track of dmesg. i have noticed that few denials are only shown in dmesg so $dmesg | grep avc is quit important while checking the boot time denials. one more thing you have to be sure is that u switch between permissive and enforce mode on the same build/bootimage. Thanks and Regards Gaurav Gangwar On 24 April 2015 at 09:42, Spector, Aaron wrote: > That sounds like an idea, I'll have to give it a shot. To add a bit more > information, I'm seeing a bunch of these changes happen during the boot > process in init and I would assume the AVC is cleared between reboots - > I've tweaked and added some things there for experimentation. I can boot = my > system up in permissive and see no problems, but when I restart it in > enforcing I start seeing brand new policy violations, things I haven't se= en > before. It seems odd that the same boot sequence would result in such > different behavior. > > -Aaron > > -----Original Message----- > From: Paul Moore [mailto:paul@paul-moore.com] > Sent: Thursday, April 23, 2015 5:20 PM > To: Spector, Aaron > Cc: SELinux (selinux@tycho.nsa.gov) > Subject: Re: Switching to enforcing mode introduces new policy issues? > > On Thu, Apr 23, 2015 at 5:14 PM, Spector, Aaron > wrote: > > Hi all, > > > > I=E2=80=99ve been working on writing my first policy for SELinux and I= =E2=80=99ve hit > > a bit of a snag. I=E2=80=99ve gotten the policy clean in permissive mod= e, but > > when I swap the system over to enforcing, a whole new set of policy > issues crop up. > > Everything I=E2=80=99ve read says this isn=E2=80=99t to be expected so = I=E2=80=99m a bit > > confused as to what=E2=80=99s happening. > > {snip} > > > So far what I=E2=80=99ve had to do to get around it is to add to my pol= icy, > > but that doesn=E2=80=99t seem like that should be necessary. If the aud= it is > > clean in permissive mode, why isn=E2=80=99t it clean in enforcing? > > > > Is it possible that I=E2=80=99m missing policy deny audits when it=E2= =80=99s in > > permissive mode? > > It's important to remember that when you are in permissive mode you will > only see a given SELinux AVC denial *once*, after that it will not be > reported until the AVC is reset. My two favorite ways of resetting the > SELinux AVC are to run either 'load_policy' or toggle the system from > permissive into enforcing and then back into permissive mode. Try that a= nd > I suspect that will solve your problem. > > -Paul > > -- > paul moore > www.paul-moore.com > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to > Selinux-request@tycho.nsa.gov. --001a1149572412913b0514712e8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Aaron,

also check if you have modified the= selinux code=C2=A0
also keep track of dmesg. i have noticed that= few denials are only shown in dmesg so $dmesg | grep avc is quit important= while checking the boot time denials.
one more thing you have to= be sure is that u switch between permissive and enforce mode on the same b= uild/bootimage.


Thanks and Regards<= /div>
Gaurav Gangwar

On 24 April 2015 at 09:42, Spector, Aaron <Aaron_Spector@mcafee.com> wrote:
That sounds like an idea, I'll have to give it a shot. To add a = bit more information, I'm seeing a bunch of these changes happen during= the boot process in init and I would assume the AVC is cleared between reb= oots - I've tweaked and added some things there for experimentation. I = can boot my system up in permissive and see no problems, but when I restart= it in enforcing I start seeing brand new policy violations, things I haven= 't seen before. It seems odd that the same boot sequence would result i= n such different behavior.

-Aaron

-----Original Message-----
From: Paul Moore [mailto:paul@paul-m= oore.com]
Sent: Thursday, April 23, 2015 5:20 PM
To: Spector, Aaron
Cc: SELinux (selinux@tycho.nsa.gov= )
Subject: Re: Switching to enforcing mode introduces new policy issues?

On Thu, Apr 23, 2015 at 5:14 PM, Spector, Aaron <Aaron_Spector@mcafee.com> wrote:
> Hi all,
>
> I=E2=80=99ve been working on writing my first policy for SELinux and I= =E2=80=99ve hit
> a bit of a snag. I=E2=80=99ve gotten the policy clean in permissive mo= de, but
> when I swap the system over to enforcing, a whole new set of policy is= sues crop up.
> Everything I=E2=80=99ve read says this isn=E2=80=99t to be expected so= I=E2=80=99m a bit
> confused as to what=E2=80=99s happening.

{snip}

> So far what I=E2=80=99ve had to do to get around it is to add to my po= licy,
> but that doesn=E2=80=99t seem like that should be necessary. If the au= dit is
> clean in permissive mode, why isn=E2=80=99t it clean in enforcing?
>
> Is it possible that I=E2=80=99m missing policy deny audits when it=E2= =80=99s in
> permissive mode?

It's important to remember that when you are in permissive mode you wil= l only see a given SELinux AVC denial *once*, after that it will not be rep= orted until the AVC is reset.=C2=A0 My two favorite ways of resetting the S= ELinux AVC are to run either 'load_policy' or toggle the system fro= m permissive into enforcing and then back into permissive mode.=C2=A0 Try t= hat and I suspect that will solve your problem.

-Paul

--
paul moore
www.paul-moore.com<= /a>

_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

--001a1149572412913b0514712e8d-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id t3OCHarj030732 for ; Fri, 24 Apr 2015 08:17:36 -0400 Message-ID: <553A3446.8010809@redhat.com> Date: Fri, 24 Apr 2015 14:17:10 +0200 From: Miroslav Grepl Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 To: "Spector, Aaron" Subject: Re: Switching to enforcing mode introduces new policy issues? References: <363d72e72db54ed2a93f39f76d1811fd@MIVEXUSR1N01.corpzone.internalzone.com> In-Reply-To: Cc: "SELinux \(selinux@tycho.nsa.gov\)" List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: On 04/24/2015 06:12 AM, Spector, Aaron wrote: > That sounds like an idea, I'll have to give it a shot. To add a bit more information, I'm seeing a bunch of these changes happen during the boot process in init and I would assume the AVC is cleared between reboots - I've tweaked and added some things there for experimentation. I can boot my system up in permissive and see no problems, but when I restart it in enforcing I start seeing brand new policy violations, things I haven't seen before. It seems odd that the same boot sequence would result in such different behavior. > > -Aaron > > -----Original Message----- > From: Paul Moore [mailto:paul@paul-moore.com] > Sent: Thursday, April 23, 2015 5:20 PM > To: Spector, Aaron > Cc: SELinux (selinux@tycho.nsa.gov) > Subject: Re: Switching to enforcing mode introduces new policy issues? > > On Thu, Apr 23, 2015 at 5:14 PM, Spector, Aaron wrote: >> Hi all, >> >> I’ve been working on writing my first policy for SELinux and I’ve hit >> a bit of a snag. I’ve gotten the policy clean in permissive mode, but >> when I swap the system over to enforcing, a whole new set of policy issues crop up. >> Everything I’ve read says this isn’t to be expected so I’m a bit >> confused as to what’s happening. > Try to use journalctl/dmesg to search either SELINUX_ERR or AVCs during boot time. > {snip} > >> So far what I’ve had to do to get around it is to add to my policy, >> but that doesn’t seem like that should be necessary. If the audit is >> clean in permissive mode, why isn’t it clean in enforcing? >> >> Is it possible that I’m missing policy deny audits when it’s in >> permissive mode? > > It's important to remember that when you are in permissive mode you will only see a given SELinux AVC denial *once*, after that it will not be reported until the AVC is reset. My two favorite ways of resetting the SELinux AVC are to run either 'load_policy' or toggle the system from permissive into enforcing and then back into permissive mode. Try that and I suspect that will solve your problem. > > -Paul > > -- > paul moore > www.paul-moore.com > > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. > -- Miroslav Grepl Software Engineering, SELinux Solutions Red Hat, Inc. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <553A362B.7040500@tycho.nsa.gov> Date: Fri, 24 Apr 2015 08:25:15 -0400 From: Stephen Smalley MIME-Version: 1.0 To: "Spector, Aaron" , "SELinux (selinux@tycho.nsa.gov)" , Paul Moore Subject: Re: Switching to enforcing mode introduces new policy issues? References: <363d72e72db54ed2a93f39f76d1811fd@MIVEXUSR1N01.corpzone.internalzone.com> In-Reply-To: <363d72e72db54ed2a93f39f76d1811fd@MIVEXUSR1N01.corpzone.internalzone.com> Content-Type: text/plain; charset=windows-1252 List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: On 04/23/2015 05:14 PM, Spector, Aaron wrote: > Hi all, > > > > I’ve been working on writing my first policy for SELinux and I’ve hit a > bit of a snag. I’ve gotten the policy clean in permissive mode, but when > I swap the system over to enforcing, a whole new set of policy issues > crop up. Everything I’ve read says this isn’t to be expected so I’m a > bit confused as to what’s happening. Output from sestatus when in > permissive mode is: > > > > SELinux status: enabled > > SELinuxfs mount: /sys/fs/selinux > > SELinux root directory: /etc/selinux > > Loaded policy name: default > > Current mode: permissive > > Mode from config file: permissive > > Policy MLS status: enabled > > Policy deny_unknown status: denied > > Max kernel policy version: 29 > > > > I’m running a version 26 policy and a 3.16.7 kernel. > > > > It seems like the majority of the new deny audits are about the need for > search permissions on directories between types that already have what I > believe are the necessary file permissions. > > > > So far what I’ve had to do to get around it is to add to my policy, but > that doesn’t seem like that should be necessary. If the audit is clean > in permissive mode, why isn’t it clean in enforcing? > > > > Is it possible that I’m missing policy deny audits when it’s in > permissive mode? The audit system can be overwhelmed by too many denials and therefore can drop some of the messages under certain conditions; look for audit_lost= in your dmesg output after booting. You may be hitting the audit rate limit, if set, or the backlog limit, if the userspace audit daemon cannot keep up, or an OOM condition. I've seen that for e.g. Android board bringup where you have too many denials during early boot. You can try adjusting the backlog or rate limits to improve the capture of denials, but sometimes you may just have to do it iteratively to ensure full coverage. Another possibility is that in enforcing mode, the kernel or userspace may follow a different code path after the point of the denial since the denial is then being enforced, and that different code path may itself trigger further permission checks that were not being triggered while permissive. I've seen that before as well. I am a little puzzled though by your comment about the majority of the new denials being for search permissions on directories between types that already have the necessary permissions. Does that mean that you have already added allow rules for these denials, rebuilt, reinstalled, and rebooted with that policy, and yet you are still seeing the same denials? If so, then a possible explanation is that the denial are due to something other than a missing allow rule, e.g. they might be due to a difference in the user identity or level fields of the source and target security contexts based on constraints in the policy. audit2why can tell you why a given denial occurred, but its ability to give you detailed info will depend on your policy version and how modern a version of libselinux and policycoreutils you have. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from goalie.tycho.ncsc.mil (goalie [144.51.242.250]) by tarius.tycho.ncsc.mil (8.14.4/8.14.4) with ESMTP id t3ODmIaQ005355 for ; Fri, 24 Apr 2015 09:48:18 -0400 From: "Spector, Aaron" To: Gaurav Gangwar Subject: RE: Switching to enforcing mode introduces new policy issues? Date: Fri, 24 Apr 2015 13:47:12 +0000 Message-ID: References: <363d72e72db54ed2a93f39f76d1811fd@MIVEXUSR1N01.corpzone.internalzone.com> In-Reply-To: Content-Type: multipart/alternative; boundary="_000_fa4b302dafe846abbbf259f3e6f37fbeMIVEXUSR1N01corpzoneint_" MIME-Version: 1.0 Cc: "SELinux \(selinux@tycho.nsa.gov\)" List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: --_000_fa4b302dafe846abbbf259f3e6f37fbeMIVEXUSR1N01corpzoneint_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgc3VnZ2VzdGlvbiBHYXVyYXYuIEnigJltIGN1cnJlbnRseSBjaGVja2lu ZyB0aGUgYXVkaXRzIGJ5IGxvb2tpbmcgYXQgZG1lc2cgYW5kIEnigJl2ZSBnb3QgdGhlIGNvbnNv bGUgYmVpbmcgcHVzaGVkIG91dCBhIHRvIGEgc2VyaWFsIGNvbnNvbGUgc28gSSBjYW4gc2VlIGFs bCB0aGUgZXZlbnRzIC0gdGhhdCdzIGhvdyBJIGtub3cgbXkgcGVybWlzc2l2ZSBib290IGlzIHN1 cHBvc2VkbHkgY2xlYW4uIElmIEkgaGFjayBteSBwb2xpY3kgdG8gbm90IGFsbG93IHNvbWV0aGlu ZywgdGhlIGZpcnN0IGF1ZGl0IEkgZ2V0IGlzIG9mICg8dGltZT46Mykgd2hpY2ggdG8gbWUgc2F5 cyBpdCdzIHRoZSBmaXJzdCBhdWRpdCBhZnRlciB0aGUgcG9saWN5IGxvYWQgd2hpY2ggaXMgKDx0 aW1lPjoyKSBvbiBteSBtYWNoaW5lLg0KDQoNCg0KSSBoYXZlbid0IG1vZGlmaWVkIHRoZSBTRUxp bnV4IGNvZGUuDQoNCg0KDQpJ4oCZdmUgY2hhbmdlZCB0byBlbmZvcmNpbmcgYnkgY2hhbmdpbmcg dGhlIC9ldGMvc2VsaW51eC9jb25maWcgZmlsZSBhbmQgYnkgYWRkaW5nIGVuZm9yY2luZz0xIHRv IGtlcm5lbCBjbWRsaW5lIGluIHRoZSBib290bG9hZGVyLiBCb3RoIHdheXMgcmVzdWx0IGluIHRo ZSBzYW1lIGVmZmVjdHMuDQoNCi1BYXJvbg0KDQpGcm9tOiBHYXVyYXYgR2FuZ3dhciBbbWFpbHRv OmdhdXJhdmdhbmd3YWFyQGdtYWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAyMywgMjAx NSAxMTo1NCBQTQ0KVG86IFNwZWN0b3IsIEFhcm9uDQpDYzogUGF1bCBNb29yZTsgU0VMaW51eCAo c2VsaW51eEB0eWNoby5uc2EuZ292KQ0KU3ViamVjdDogUmU6IFN3aXRjaGluZyB0byBlbmZvcmNp bmcgbW9kZSBpbnRyb2R1Y2VzIG5ldyBwb2xpY3kgaXNzdWVzPw0KDQpIaSBBYXJvbiwNCg0KYWxz byBjaGVjayBpZiB5b3UgaGF2ZSBtb2RpZmllZCB0aGUgc2VsaW51eCBjb2RlDQphbHNvIGtlZXAg dHJhY2sgb2YgZG1lc2cuIGkgaGF2ZSBub3RpY2VkIHRoYXQgZmV3IGRlbmlhbHMgYXJlIG9ubHkg c2hvd24gaW4gZG1lc2cgc28gJGRtZXNnIHwgZ3JlcCBhdmMgaXMgcXVpdCBpbXBvcnRhbnQgd2hp bGUgY2hlY2tpbmcgdGhlIGJvb3QgdGltZSBkZW5pYWxzLg0Kb25lIG1vcmUgdGhpbmcgeW91IGhh dmUgdG8gYmUgc3VyZSBpcyB0aGF0IHUgc3dpdGNoIGJldHdlZW4gcGVybWlzc2l2ZSBhbmQgZW5m b3JjZSBtb2RlIG9uIHRoZSBzYW1lIGJ1aWxkL2Jvb3RpbWFnZS4NCg0KDQpUaGFua3MgYW5kIFJl Z2FyZHMNCkdhdXJhdiBHYW5nd2FyDQoNCk9uIDI0IEFwcmlsIDIwMTUgYXQgMDk6NDIsIFNwZWN0 b3IsIEFhcm9uIDxBYXJvbl9TcGVjdG9yQG1jYWZlZS5jb208bWFpbHRvOkFhcm9uX1NwZWN0b3JA bWNhZmVlLmNvbT4+IHdyb3RlOg0KVGhhdCBzb3VuZHMgbGlrZSBhbiBpZGVhLCBJJ2xsIGhhdmUg dG8gZ2l2ZSBpdCBhIHNob3QuIFRvIGFkZCBhIGJpdCBtb3JlIGluZm9ybWF0aW9uLCBJJ20gc2Vl aW5nIGEgYnVuY2ggb2YgdGhlc2UgY2hhbmdlcyBoYXBwZW4gZHVyaW5nIHRoZSBib290IHByb2Nl c3MgaW4gaW5pdCBhbmQgSSB3b3VsZCBhc3N1bWUgdGhlIEFWQyBpcyBjbGVhcmVkIGJldHdlZW4g cmVib290cyAtIEkndmUgdHdlYWtlZCBhbmQgYWRkZWQgc29tZSB0aGluZ3MgdGhlcmUgZm9yIGV4 cGVyaW1lbnRhdGlvbi4gSSBjYW4gYm9vdCBteSBzeXN0ZW0gdXAgaW4gcGVybWlzc2l2ZSBhbmQg c2VlIG5vIHByb2JsZW1zLCBidXQgd2hlbiBJIHJlc3RhcnQgaXQgaW4gZW5mb3JjaW5nIEkgc3Rh cnQgc2VlaW5nIGJyYW5kIG5ldyBwb2xpY3kgdmlvbGF0aW9ucywgdGhpbmdzIEkgaGF2ZW4ndCBz ZWVuIGJlZm9yZS4gSXQgc2VlbXMgb2RkIHRoYXQgdGhlIHNhbWUgYm9vdCBzZXF1ZW5jZSB3b3Vs ZCByZXN1bHQgaW4gc3VjaCBkaWZmZXJlbnQgYmVoYXZpb3IuDQoNCi1BYXJvbg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGF1bCBNb29yZSBbbWFpbHRvOnBhdWxAcGF1bC1t b29yZS5jb208bWFpbHRvOnBhdWxAcGF1bC1tb29yZS5jb20+XQ0KU2VudDogVGh1cnNkYXksIEFw cmlsIDIzLCAyMDE1IDU6MjAgUE0NClRvOiBTcGVjdG9yLCBBYXJvbg0KQ2M6IFNFTGludXggKHNl bGludXhAdHljaG8ubnNhLmdvdjxtYWlsdG86c2VsaW51eEB0eWNoby5uc2EuZ292PikNClN1Ympl Y3Q6IFJlOiBTd2l0Y2hpbmcgdG8gZW5mb3JjaW5nIG1vZGUgaW50cm9kdWNlcyBuZXcgcG9saWN5 IGlzc3Vlcz8NCg0KT24gVGh1LCBBcHIgMjMsIDIwMTUgYXQgNToxNCBQTSwgU3BlY3RvciwgQWFy b24gPEFhcm9uX1NwZWN0b3JAbWNhZmVlLmNvbTxtYWlsdG86QWFyb25fU3BlY3RvckBtY2FmZWUu Y29tPj4gd3JvdGU6DQo+IEhpIGFsbCwNCj4NCj4gSeKAmXZlIGJlZW4gd29ya2luZyBvbiB3cml0 aW5nIG15IGZpcnN0IHBvbGljeSBmb3IgU0VMaW51eCBhbmQgSeKAmXZlIGhpdA0KPiBhIGJpdCBv ZiBhIHNuYWcuIEnigJl2ZSBnb3R0ZW4gdGhlIHBvbGljeSBjbGVhbiBpbiBwZXJtaXNzaXZlIG1v ZGUsIGJ1dA0KPiB3aGVuIEkgc3dhcCB0aGUgc3lzdGVtIG92ZXIgdG8gZW5mb3JjaW5nLCBhIHdo b2xlIG5ldyBzZXQgb2YgcG9saWN5IGlzc3VlcyBjcm9wIHVwLg0KPiBFdmVyeXRoaW5nIEnigJl2 ZSByZWFkIHNheXMgdGhpcyBpc27igJl0IHRvIGJlIGV4cGVjdGVkIHNvIEnigJltIGEgYml0DQo+ IGNvbmZ1c2VkIGFzIHRvIHdoYXTigJlzIGhhcHBlbmluZy4NCg0Ke3NuaXB9DQoNCj4gU28gZmFy IHdoYXQgSeKAmXZlIGhhZCB0byBkbyB0byBnZXQgYXJvdW5kIGl0IGlzIHRvIGFkZCB0byBteSBw b2xpY3ksDQo+IGJ1dCB0aGF0IGRvZXNu4oCZdCBzZWVtIGxpa2UgdGhhdCBzaG91bGQgYmUgbmVj ZXNzYXJ5LiBJZiB0aGUgYXVkaXQgaXMNCj4gY2xlYW4gaW4gcGVybWlzc2l2ZSBtb2RlLCB3aHkg aXNu4oCZdCBpdCBjbGVhbiBpbiBlbmZvcmNpbmc/DQo+DQo+IElzIGl0IHBvc3NpYmxlIHRoYXQg SeKAmW0gbWlzc2luZyBwb2xpY3kgZGVueSBhdWRpdHMgd2hlbiBpdOKAmXMgaW4NCj4gcGVybWlz c2l2ZSBtb2RlPw0KDQpJdCdzIGltcG9ydGFudCB0byByZW1lbWJlciB0aGF0IHdoZW4geW91IGFy ZSBpbiBwZXJtaXNzaXZlIG1vZGUgeW91IHdpbGwgb25seSBzZWUgYSBnaXZlbiBTRUxpbnV4IEFW QyBkZW5pYWwgKm9uY2UqLCBhZnRlciB0aGF0IGl0IHdpbGwgbm90IGJlIHJlcG9ydGVkIHVudGls IHRoZSBBVkMgaXMgcmVzZXQuICBNeSB0d28gZmF2b3JpdGUgd2F5cyBvZiByZXNldHRpbmcgdGhl IFNFTGludXggQVZDIGFyZSB0byBydW4gZWl0aGVyICdsb2FkX3BvbGljeScgb3IgdG9nZ2xlIHRo ZSBzeXN0ZW0gZnJvbSBwZXJtaXNzaXZlIGludG8gZW5mb3JjaW5nIGFuZCB0aGVuIGJhY2sgaW50 byBwZXJtaXNzaXZlIG1vZGUuICBUcnkgdGhhdCBhbmQgSSBzdXNwZWN0IHRoYXQgd2lsbCBzb2x2 ZSB5b3VyIHByb2JsZW0uDQoNCi1QYXVsDQoNCi0tDQpwYXVsIG1vb3JlDQp3d3cucGF1bC1tb29y ZS5jb208aHR0cDovL3d3dy5wYXVsLW1vb3JlLmNvbT4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClNlbGludXggbWFpbGluZyBsaXN0DQpTZWxpbnV4 QHR5Y2hvLm5zYS5nb3Y8bWFpbHRvOlNlbGludXhAdHljaG8ubnNhLmdvdj4NClRvIHVuc3Vic2Ny aWJlLCBzZW5kIGVtYWlsIHRvIFNlbGludXgtbGVhdmVAdHljaG8ubnNhLmdvdjxtYWlsdG86U2Vs aW51eC1sZWF2ZUB0eWNoby5uc2EuZ292Pi4NClRvIGdldCBoZWxwLCBzZW5kIGFuIGVtYWlsIGNv bnRhaW5pbmcgImhlbHAiIHRvIFNlbGludXgtcmVxdWVzdEB0eWNoby5uc2EuZ292PG1haWx0bzpT ZWxpbnV4LXJlcXVlc3RAdHljaG8ubnNhLmdvdj4uDQoNCg== --_000_fa4b302dafe846abbbf259f3e6f37fbeMIVEXUSR1N01corpzoneint_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyBmb3IgdGhl IHN1Z2dlc3Rpb24gR2F1cmF2LiBJ4oCZbSBjdXJyZW50bHkgY2hlY2tpbmcgdGhlIGF1ZGl0cyBi eSBsb29raW5nIGF0IGRtZXNnIGFuZCBJ4oCZdmUgZ290IHRoZSBjb25zb2xlIGJlaW5nIHB1c2hl ZCBvdXQgYSB0byBhIHNlcmlhbCBjb25zb2xlIHNvIEkgY2FuIHNlZSBhbGwgdGhlIGV2ZW50cyAt IHRoYXQncyBob3cgSSBrbm93IG15IHBlcm1pc3NpdmUgYm9vdCBpcyBzdXBwb3NlZGx5DQogY2xl YW4uIElmIEkgaGFjayBteSBwb2xpY3kgdG8gbm90IGFsbG93IHNvbWV0aGluZywgdGhlIGZpcnN0 IGF1ZGl0IEkgZ2V0IGlzIG9mICgmbHQ7dGltZSZndDs6Mykgd2hpY2ggdG8gbWUgc2F5cyBpdCdz IHRoZSBmaXJzdCBhdWRpdCBhZnRlciB0aGUgcG9saWN5IGxvYWQgd2hpY2ggaXMgKCZsdDt0aW1l Jmd0OzoyKSBvbiBteSBtYWNoaW5lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5JIGhh dmVuJ3QgbW9kaWZpZWQgdGhlIFNFTGludXggY29kZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+SeKAmXZlIGNoYW5nZWQgdG8gZW5mb3JjaW5nIGJ5IGNoYW5naW5nIHRoZSAvZXRjL3Nl bGludXgvY29uZmlnIGZpbGUgYW5kIGJ5IGFkZGluZyBlbmZvcmNpbmc9MSB0byBrZXJuZWwgY21k bGluZSBpbiB0aGUgYm9vdGxvYWRlci4gQm90aCB3YXlzIHJlc3VsdCBpbiB0aGUgc2FtZSBlZmZl Y3RzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tQWFyb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IEdhdXJhdiBHYW5nd2FyIFttYWlsdG86Z2F1cmF2Z2FuZ3dhYXJAZ21haWwuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAyMywgMjAxNSAxMTo1NCBQTTxicj4NCjxiPlRv OjwvYj4gU3BlY3RvciwgQWFyb248YnI+DQo8Yj5DYzo8L2I+IFBhdWwgTW9vcmU7IFNFTGludXgg KHNlbGludXhAdHljaG8ubnNhLmdvdik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFN3aXRjaGlu ZyB0byBlbmZvcmNpbmcgbW9kZSBpbnRyb2R1Y2VzIG5ldyBwb2xpY3kgaXNzdWVzPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEFhcm9uLDxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFsc28gY2hlY2sgaWYgeW91IGhhdmUgbW9kaWZpZWQgdGhl IHNlbGludXggY29kZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+YWxzbyBrZWVwIHRyYWNrIG9mIGRtZXNnLiBpIGhhdmUgbm90aWNlZCB0 aGF0IGZldyBkZW5pYWxzIGFyZSBvbmx5IHNob3duIGluIGRtZXNnIHNvICRkbWVzZyB8IGdyZXAg YXZjIGlzIHF1aXQgaW1wb3J0YW50IHdoaWxlIGNoZWNraW5nIHRoZSBib290IHRpbWUgZGVuaWFs cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm9u ZSBtb3JlIHRoaW5nIHlvdSBoYXZlIHRvIGJlIHN1cmUgaXMgdGhhdCB1IHN3aXRjaCBiZXR3ZWVu IHBlcm1pc3NpdmUgYW5kIGVuZm9yY2UgbW9kZSBvbiB0aGUgc2FtZSBidWlsZC9ib290aW1hZ2Uu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzIGFuZCBSZWdhcmRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5HYXVyYXYgR2FuZ3dhcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI0IEFwcmlsIDIwMTUgYXQgMDk6 NDIsIFNwZWN0b3IsIEFhcm9uICZsdDs8YSBocmVmPSJtYWlsdG86QWFyb25fU3BlY3RvckBtY2Fm ZWUuY29tIiB0YXJnZXQ9Il9ibGFuayI+QWFyb25fU3BlY3RvckBtY2FmZWUuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHNvdW5kcyBs aWtlIGFuIGlkZWEsIEknbGwgaGF2ZSB0byBnaXZlIGl0IGEgc2hvdC4gVG8gYWRkIGEgYml0IG1v cmUgaW5mb3JtYXRpb24sIEknbSBzZWVpbmcgYSBidW5jaCBvZiB0aGVzZSBjaGFuZ2VzIGhhcHBl biBkdXJpbmcgdGhlIGJvb3QgcHJvY2VzcyBpbiBpbml0IGFuZCBJIHdvdWxkIGFzc3VtZSB0aGUg QVZDIGlzIGNsZWFyZWQgYmV0d2VlbiByZWJvb3RzIC0gSSd2ZSB0d2Vha2VkIGFuZCBhZGRlZA0K IHNvbWUgdGhpbmdzIHRoZXJlIGZvciBleHBlcmltZW50YXRpb24uIEkgY2FuIGJvb3QgbXkgc3lz dGVtIHVwIGluIHBlcm1pc3NpdmUgYW5kIHNlZSBubyBwcm9ibGVtcywgYnV0IHdoZW4gSSByZXN0 YXJ0IGl0IGluIGVuZm9yY2luZyBJIHN0YXJ0IHNlZWluZyBicmFuZCBuZXcgcG9saWN5IHZpb2xh dGlvbnMsIHRoaW5ncyBJIGhhdmVuJ3Qgc2VlbiBiZWZvcmUuIEl0IHNlZW1zIG9kZCB0aGF0IHRo ZSBzYW1lIGJvb3Qgc2VxdWVuY2Ugd291bGQgcmVzdWx0DQogaW4gc3VjaCBkaWZmZXJlbnQgYmVo YXZpb3IuPGJyPg0KPGJyPg0KLUFhcm9uPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQpGcm9tOiBQYXVsIE1vb3JlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBhdWxA cGF1bC1tb29yZS5jb20iPnBhdWxAcGF1bC1tb29yZS5jb208L2E+XTxicj4NClNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAyMywgMjAxNSA1OjIwIFBNPGJyPg0KVG86IFNwZWN0b3IsIEFhcm9uPGJyPg0K Q2M6IFNFTGludXggKDxhIGhyZWY9Im1haWx0bzpzZWxpbnV4QHR5Y2hvLm5zYS5nb3YiPnNlbGlu dXhAdHljaG8ubnNhLmdvdjwvYT4pPGJyPg0KU3ViamVjdDogUmU6IFN3aXRjaGluZyB0byBlbmZv cmNpbmcgbW9kZSBpbnRyb2R1Y2VzIG5ldyBwb2xpY3kgaXNzdWVzPzxicj4NCjxicj4NCk9uIFRo dSwgQXByIDIzLCAyMDE1IGF0IDU6MTQgUE0sIFNwZWN0b3IsIEFhcm9uICZsdDs8YSBocmVmPSJt YWlsdG86QWFyb25fU3BlY3RvckBtY2FmZWUuY29tIj5BYXJvbl9TcGVjdG9yQG1jYWZlZS5jb208 L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ4oCZ dmUgYmVlbiB3b3JraW5nIG9uIHdyaXRpbmcgbXkgZmlyc3QgcG9saWN5IGZvciBTRUxpbnV4IGFu ZCBJ4oCZdmUgaGl0PGJyPg0KJmd0OyBhIGJpdCBvZiBhIHNuYWcuIEnigJl2ZSBnb3R0ZW4gdGhl IHBvbGljeSBjbGVhbiBpbiBwZXJtaXNzaXZlIG1vZGUsIGJ1dDxicj4NCiZndDsgd2hlbiBJIHN3 YXAgdGhlIHN5c3RlbSBvdmVyIHRvIGVuZm9yY2luZywgYSB3aG9sZSBuZXcgc2V0IG9mIHBvbGlj eSBpc3N1ZXMgY3JvcCB1cC48YnI+DQomZ3Q7IEV2ZXJ5dGhpbmcgSeKAmXZlIHJlYWQgc2F5cyB0 aGlzIGlzbuKAmXQgdG8gYmUgZXhwZWN0ZWQgc28gSeKAmW0gYSBiaXQ8YnI+DQomZ3Q7IGNvbmZ1 c2VkIGFzIHRvIHdoYXTigJlzIGhhcHBlbmluZy48YnI+DQo8YnI+DQp7c25pcH08YnI+DQo8YnI+ DQomZ3Q7IFNvIGZhciB3aGF0IEnigJl2ZSBoYWQgdG8gZG8gdG8gZ2V0IGFyb3VuZCBpdCBpcyB0 byBhZGQgdG8gbXkgcG9saWN5LDxicj4NCiZndDsgYnV0IHRoYXQgZG9lc27igJl0IHNlZW0gbGlr ZSB0aGF0IHNob3VsZCBiZSBuZWNlc3NhcnkuIElmIHRoZSBhdWRpdCBpczxicj4NCiZndDsgY2xl YW4gaW4gcGVybWlzc2l2ZSBtb2RlLCB3aHkgaXNu4oCZdCBpdCBjbGVhbiBpbiBlbmZvcmNpbmc/ PGJyPg0KJmd0Ozxicj4NCiZndDsgSXMgaXQgcG9zc2libGUgdGhhdCBJ4oCZbSBtaXNzaW5nIHBv bGljeSBkZW55IGF1ZGl0cyB3aGVuIGl04oCZcyBpbjxicj4NCiZndDsgcGVybWlzc2l2ZSBtb2Rl Pzxicj4NCjxicj4NCkl0J3MgaW1wb3J0YW50IHRvIHJlbWVtYmVyIHRoYXQgd2hlbiB5b3UgYXJl IGluIHBlcm1pc3NpdmUgbW9kZSB5b3Ugd2lsbCBvbmx5IHNlZSBhIGdpdmVuIFNFTGludXggQVZD IGRlbmlhbCAqb25jZSosIGFmdGVyIHRoYXQgaXQgd2lsbCBub3QgYmUgcmVwb3J0ZWQgdW50aWwg dGhlIEFWQyBpcyByZXNldC4mbmJzcDsgTXkgdHdvIGZhdm9yaXRlIHdheXMgb2YgcmVzZXR0aW5n IHRoZSBTRUxpbnV4IEFWQyBhcmUgdG8gcnVuIGVpdGhlciAnbG9hZF9wb2xpY3knDQogb3IgdG9n Z2xlIHRoZSBzeXN0ZW0gZnJvbSBwZXJtaXNzaXZlIGludG8gZW5mb3JjaW5nIGFuZCB0aGVuIGJh Y2sgaW50byBwZXJtaXNzaXZlIG1vZGUuJm5ic3A7IFRyeSB0aGF0IGFuZCBJIHN1c3BlY3QgdGhh dCB3aWxsIHNvbHZlIHlvdXIgcHJvYmxlbS48YnI+DQo8YnI+DQotUGF1bDxicj4NCjxicj4NCi0t PGJyPg0KcGF1bCBtb29yZTxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cucGF1bC1tb29yZS5jb20i IHRhcmdldD0iX2JsYW5rIj53d3cucGF1bC1tb29yZS5jb208L2E+PGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpTZWxpbnV4IG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpTZWxpbnV4QHR5Y2hvLm5zYS5nb3YiPlNl bGludXhAdHljaG8ubnNhLmdvdjwvYT48YnI+DQpUbyB1bnN1YnNjcmliZSwgc2VuZCBlbWFpbCB0 byA8YSBocmVmPSJtYWlsdG86U2VsaW51eC1sZWF2ZUB0eWNoby5uc2EuZ292Ij5TZWxpbnV4LWxl YXZlQHR5Y2hvLm5zYS5nb3Y8L2E+Ljxicj4NClRvIGdldCBoZWxwLCBzZW5kIGFuIGVtYWlsIGNv bnRhaW5pbmcgJnF1b3Q7aGVscCZxdW90OyB0byA8YSBocmVmPSJtYWlsdG86U2VsaW51eC1yZXF1 ZXN0QHR5Y2hvLm5zYS5nb3YiPg0KU2VsaW51eC1yZXF1ZXN0QHR5Y2hvLm5zYS5nb3Y8L2E+Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_fa4b302dafe846abbbf259f3e6f37fbeMIVEXUSR1N01corpzoneint_-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Spector, Aaron" To: Stephen Smalley , "SELinux (selinux@tycho.nsa.gov)" , "Paul Moore (paul@paul-moore.com)" Subject: RE: Switching to enforcing mode introduces new policy issues? Date: Fri, 24 Apr 2015 15:18:13 +0000 Message-ID: <0787916bff754fec87b219654e47b1e0@MIVEXUSR1N01.corpzone.internalzone.com> References: <363d72e72db54ed2a93f39f76d1811fd@MIVEXUSR1N01.corpzone.internalzone.com> <553A362B.7040500@tycho.nsa.gov> In-Reply-To: <553A362B.7040500@tycho.nsa.gov> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 List-Id: "Security-Enhanced Linux \(SELinux\) mailing list" List-Post: List-Help: I noticed the ratelimiting happening a while ago, but if it was happening here, I should get suppression logs correct? I've been checking my avc audits by examining dmesg / viewing that output via a serial console and nothing in there implies that I'm missing logs. When in permissive I can see the policy load audit (