* neverallow rules @ 2019-02-27 1:29 Joe Nall 2019-02-27 3:38 ` Chris PeBenito 0 siblings, 1 reply; 8+ messages in thread From: Joe Nall @ 2019-02-27 1:29 UTC (permalink / raw) To: selinux Looking at neverallow rules, the semanage.conf file says "# expand-check check neverallow rules when executing all semanage commands. # Large penalty in time if you turn this on. " If I don't set expand-check=1, are the neverallow rules actually enforced? If so, when? An semodule -i of a policy module with neverallow rules that are violated by the existing binary policy succeeds without complaint unless expand-check=1 in RHEL 7.6. This is not what I expected. The time taken by a trivial module installation goes from ~.3 seconds to ~14 seconds, so the time hit for expand-check is pretty serious. We are trying to establish some policy invariants to protect against unexpected/unnoticed RHEL upstream policy changes, some of which have bitten us recently. Any suggestions are welcome. joe ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: neverallow rules 2019-02-27 1:29 neverallow rules Joe Nall @ 2019-02-27 3:38 ` Chris PeBenito 2019-02-27 13:29 ` Stephen Smalley 2019-02-27 16:13 ` [Non-DoD Source] " jwcart2 0 siblings, 2 replies; 8+ messages in thread From: Chris PeBenito @ 2019-02-27 3:38 UTC (permalink / raw) To: Joe Nall, selinux On Tue, 2019-02-26 at 19:29 -0600, Joe Nall wrote: > Looking at neverallow rules, the semanage.conf file says > "# expand-check check neverallow rules when executing all semanage > commands. > # Large penalty in time if you turn this on. " > > If I don't set expand-check=1, are the neverallow rules actually > enforced? Nope. > If so, when? > > An semodule -i of a policy module with neverallow rules that are > violated by the existing binary policy succeeds without complaint > unless expand-check=1 in RHEL 7.6. This is not what I expected. > > The time taken by a trivial module installation goes from ~.3 seconds > to ~14 seconds, so the time hit for expand-check is pretty serious. The reason for adding the expand-check option is because the neverallow checking is so expensive. > We are trying to establish some policy invariants to protect against > unexpected/unnoticed RHEL upstream policy changes, some of which have > bitten us recently. Any suggestions are welcome. One alternative would be to use the setools API to code up some policy searches in Python, then process the results to find things you do/don't want in your policy. -- Chris PeBenito ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: neverallow rules 2019-02-27 3:38 ` Chris PeBenito @ 2019-02-27 13:29 ` Stephen Smalley 2019-02-27 13:48 ` Stephen Smalley 2019-02-27 16:13 ` [Non-DoD Source] " jwcart2 1 sibling, 1 reply; 8+ messages in thread From: Stephen Smalley @ 2019-02-27 13:29 UTC (permalink / raw) To: Chris PeBenito, Joe Nall, selinux On 2/26/19 10:38 PM, Chris PeBenito wrote: > On Tue, 2019-02-26 at 19:29 -0600, Joe Nall wrote: >> Looking at neverallow rules, the semanage.conf file says >> "# expand-check check neverallow rules when executing all semanage >> commands. >> # Large penalty in time if you turn this on. " >> >> If I don't set expand-check=1, are the neverallow rules actually >> enforced? > > Nope. > >> If so, when? >> >> An semodule -i of a policy module with neverallow rules that are >> violated by the existing binary policy succeeds without complaint >> unless expand-check=1 in RHEL 7.6. This is not what I expected. >> >> The time taken by a trivial module installation goes from ~.3 seconds >> to ~14 seconds, so the time hit for expand-check is pretty serious. > > The reason for adding the expand-check option is because the neverallow > checking is so expensive. > >> We are trying to establish some policy invariants to protect against >> unexpected/unnoticed RHEL upstream policy changes, some of which have >> bitten us recently. Any suggestions are welcome. > > One alternative would be to use the setools API to code up some policy > searches in Python, then process the results to find things you > do/don't want in your policy. The approach taken in Fedora/RHEL is to run make validate as part of the selinux-policy.spec recipe, which uses the validate target in the refpolicy Makefile, which manually runs semodule_link and semodule_expand to manually link and expand the modules and performs full checking. Then the cost is only paid at policy build time and is only applied for the neverallow rules and allow rules in the Fedora/RHEL policy, not for third party modules. If you are rebuilding the RHEL policy from source, you could add your neverallows to it there and the make validate should catch the violations. In Android, neverallow checking is done both at policy build time and as part of device certification. The latter is done using a sepolicy-analyze tool we originally contributed; it can take a separate neverallow rule configuration in source form and an already compiled kernel binary policy and check them against each other. That's useful for cases where you don't have policy sources. You can have libsemanage apply your own checker against policy as part of module transactions by specifying a [verify kernel] stanza in semanage.conf, see: http://selinuxproject.org/page/PolicyValidate ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: neverallow rules 2019-02-27 13:29 ` Stephen Smalley @ 2019-02-27 13:48 ` Stephen Smalley 2019-02-27 13:54 ` Stephen Smalley 0 siblings, 1 reply; 8+ messages in thread From: Stephen Smalley @ 2019-02-27 13:48 UTC (permalink / raw) To: Chris PeBenito, Joe Nall, selinux On 2/27/19 8:29 AM, Stephen Smalley wrote: > On 2/26/19 10:38 PM, Chris PeBenito wrote: >> On Tue, 2019-02-26 at 19:29 -0600, Joe Nall wrote: >>> Looking at neverallow rules, the semanage.conf file says >>> "# expand-check check neverallow rules when executing all semanage >>> commands. >>> # Large penalty in time if you turn this on. " >>> >>> If I don't set expand-check=1, are the neverallow rules actually >>> enforced? >> >> Nope. >> >>> If so, when? >>> >>> An semodule -i of a policy module with neverallow rules that are >>> violated by the existing binary policy succeeds without complaint >>> unless expand-check=1 in RHEL 7.6. This is not what I expected. >>> >>> The time taken by a trivial module installation goes from ~.3 seconds >>> to ~14 seconds, so the time hit for expand-check is pretty serious. >> >> The reason for adding the expand-check option is because the neverallow >> checking is so expensive. >> >>> We are trying to establish some policy invariants to protect against >>> unexpected/unnoticed RHEL upstream policy changes, some of which have >>> bitten us recently. Any suggestions are welcome. >> >> One alternative would be to use the setools API to code up some policy >> searches in Python, then process the results to find things you >> do/don't want in your policy. > > The approach taken in Fedora/RHEL is to run make validate as part of the > selinux-policy.spec recipe, which uses the validate target in the > refpolicy Makefile, which manually runs semodule_link and > semodule_expand to manually link and expand the modules and performs > full checking. Then the cost is only paid at policy build time and is > only applied for the neverallow rules and allow rules in the Fedora/RHEL > policy, not for third party modules. If you are rebuilding the RHEL > policy from source, you could add your neverallows to it there and the > make validate should catch the violations. > > In Android, neverallow checking is done both at policy build time and as > part of device certification. The latter is done using a > sepolicy-analyze tool we originally contributed; it can take a separate > neverallow rule configuration in source form and an already compiled > kernel binary policy and check them against each other. That's useful > for cases where you don't have policy sources. > > You can have libsemanage apply your own checker against policy as part > of module transactions by specifying a [verify kernel] stanza in > semanage.conf, see: > http://selinuxproject.org/page/PolicyValidate Also, FWIW, you can obtain, build, and use sepolicy-analyze outside of the Android build system as follows. If you are on RHEL 7, you likely need/want to obtain the upstream selinux userspace and build its version of libsepol.a for use below instead of using the libsepol-static package from RHEL since that is likely too old. # Get source and build. $ git clone https://android.googlesource.com/platform/system/sepolicy $ cd sepolicy/tools/sepolicy-analyze $ gcc -o sepolicy-analyze *.c /path/to/libsepol.a # Run with neverallows specified on the command-line. $ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow -n "neverallow user_t self:process signal;" # Run with neverallows from a separate file. $ cat > neverallows.conf <<EOF neverallow user_t self:process signal; EOF $ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow -f neverallows.conf There have been improvements to neverallow checking time upstream since RHEL 7, but it will still be a function of policy size and obviously RHEL has a much larger policy than Android... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: neverallow rules 2019-02-27 13:48 ` Stephen Smalley @ 2019-02-27 13:54 ` Stephen Smalley 2019-02-27 13:57 ` Stephen Smalley 0 siblings, 1 reply; 8+ messages in thread From: Stephen Smalley @ 2019-02-27 13:54 UTC (permalink / raw) To: Chris PeBenito, Joe Nall, selinux On 2/27/19 8:48 AM, Stephen Smalley wrote: > On 2/27/19 8:29 AM, Stephen Smalley wrote: >> On 2/26/19 10:38 PM, Chris PeBenito wrote: >>> On Tue, 2019-02-26 at 19:29 -0600, Joe Nall wrote: >>>> Looking at neverallow rules, the semanage.conf file says >>>> "# expand-check check neverallow rules when executing all semanage >>>> commands. >>>> # Large penalty in time if you turn this on. " >>>> >>>> If I don't set expand-check=1, are the neverallow rules actually >>>> enforced? >>> >>> Nope. >>> >>>> If so, when? >>>> >>>> An semodule -i of a policy module with neverallow rules that are >>>> violated by the existing binary policy succeeds without complaint >>>> unless expand-check=1 in RHEL 7.6. This is not what I expected. >>>> >>>> The time taken by a trivial module installation goes from ~.3 seconds >>>> to ~14 seconds, so the time hit for expand-check is pretty serious. >>> >>> The reason for adding the expand-check option is because the neverallow >>> checking is so expensive. >>> >>>> We are trying to establish some policy invariants to protect against >>>> unexpected/unnoticed RHEL upstream policy changes, some of which have >>>> bitten us recently. Any suggestions are welcome. >>> >>> One alternative would be to use the setools API to code up some policy >>> searches in Python, then process the results to find things you >>> do/don't want in your policy. >> >> The approach taken in Fedora/RHEL is to run make validate as part of >> the selinux-policy.spec recipe, which uses the validate target in the >> refpolicy Makefile, which manually runs semodule_link and >> semodule_expand to manually link and expand the modules and performs >> full checking. Then the cost is only paid at policy build time and is >> only applied for the neverallow rules and allow rules in the >> Fedora/RHEL policy, not for third party modules. If you are >> rebuilding the RHEL policy from source, you could add your neverallows >> to it there and the make validate should catch the violations. >> >> In Android, neverallow checking is done both at policy build time and >> as part of device certification. The latter is done using a >> sepolicy-analyze tool we originally contributed; it can take a >> separate neverallow rule configuration in source form and an already >> compiled kernel binary policy and check them against each other. >> That's useful for cases where you don't have policy sources. >> >> You can have libsemanage apply your own checker against policy as part >> of module transactions by specifying a [verify kernel] stanza in >> semanage.conf, see: >> http://selinuxproject.org/page/PolicyValidate > > Also, FWIW, you can obtain, build, and use sepolicy-analyze outside of > the Android build system as follows. If you are on RHEL 7, you likely > need/want to obtain the upstream selinux userspace and build its version > of libsepol.a for use below instead of using the libsepol-static package > from RHEL since that is likely too old. > > # Get source and build. > $ git clone https://android.googlesource.com/platform/system/sepolicy > $ cd sepolicy/tools/sepolicy-analyze > $ gcc -o sepolicy-analyze *.c /path/to/libsepol.a > > # Run with neverallows specified on the command-line. > $ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow -n > "neverallow user_t self:process signal;" > > # Run with neverallows from a separate file. > $ cat > neverallows.conf <<EOF > neverallow user_t self:process signal; > EOF > $ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow -f > neverallows.conf > > There have been improvements to neverallow checking time upstream since > RHEL 7, but it will still be a function of policy size and obviously > RHEL has a much larger policy than Android... For reference, on Fedora 29: $ time sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow -n "neverallow user_t self:capability mac_admin;" real 0m0.145s user 0m0.133s sys 0m0.012s ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: neverallow rules 2019-02-27 13:54 ` Stephen Smalley @ 2019-02-27 13:57 ` Stephen Smalley 2019-02-27 14:12 ` Stephen Smalley 0 siblings, 1 reply; 8+ messages in thread From: Stephen Smalley @ 2019-02-27 13:57 UTC (permalink / raw) To: Chris PeBenito, Joe Nall, selinux On 2/27/19 8:54 AM, Stephen Smalley wrote: > On 2/27/19 8:48 AM, Stephen Smalley wrote: >> On 2/27/19 8:29 AM, Stephen Smalley wrote: >>> On 2/26/19 10:38 PM, Chris PeBenito wrote: >>>> On Tue, 2019-02-26 at 19:29 -0600, Joe Nall wrote: >>>>> Looking at neverallow rules, the semanage.conf file says >>>>> "# expand-check check neverallow rules when executing all semanage >>>>> commands. >>>>> # Large penalty in time if you turn this on. " >>>>> >>>>> If I don't set expand-check=1, are the neverallow rules actually >>>>> enforced? >>>> >>>> Nope. >>>> >>>>> If so, when? >>>>> >>>>> An semodule -i of a policy module with neverallow rules that are >>>>> violated by the existing binary policy succeeds without complaint >>>>> unless expand-check=1 in RHEL 7.6. This is not what I expected. >>>>> >>>>> The time taken by a trivial module installation goes from ~.3 seconds >>>>> to ~14 seconds, so the time hit for expand-check is pretty serious. >>>> >>>> The reason for adding the expand-check option is because the neverallow >>>> checking is so expensive. >>>> >>>>> We are trying to establish some policy invariants to protect against >>>>> unexpected/unnoticed RHEL upstream policy changes, some of which have >>>>> bitten us recently. Any suggestions are welcome. >>>> >>>> One alternative would be to use the setools API to code up some policy >>>> searches in Python, then process the results to find things you >>>> do/don't want in your policy. >>> >>> The approach taken in Fedora/RHEL is to run make validate as part of >>> the selinux-policy.spec recipe, which uses the validate target in the >>> refpolicy Makefile, which manually runs semodule_link and >>> semodule_expand to manually link and expand the modules and performs >>> full checking. Then the cost is only paid at policy build time and >>> is only applied for the neverallow rules and allow rules in the >>> Fedora/RHEL policy, not for third party modules. If you are >>> rebuilding the RHEL policy from source, you could add your >>> neverallows to it there and the make validate should catch the >>> violations. >>> >>> In Android, neverallow checking is done both at policy build time and >>> as part of device certification. The latter is done using a >>> sepolicy-analyze tool we originally contributed; it can take a >>> separate neverallow rule configuration in source form and an already >>> compiled kernel binary policy and check them against each other. >>> That's useful for cases where you don't have policy sources. >>> >>> You can have libsemanage apply your own checker against policy as >>> part of module transactions by specifying a [verify kernel] stanza in >>> semanage.conf, see: >>> http://selinuxproject.org/page/PolicyValidate >> >> Also, FWIW, you can obtain, build, and use sepolicy-analyze outside of >> the Android build system as follows. If you are on RHEL 7, you likely >> need/want to obtain the upstream selinux userspace and build its >> version of libsepol.a for use below instead of using the >> libsepol-static package from RHEL since that is likely too old. >> >> # Get source and build. >> $ git clone https://android.googlesource.com/platform/system/sepolicy >> $ cd sepolicy/tools/sepolicy-analyze >> $ gcc -o sepolicy-analyze *.c /path/to/libsepol.a >> >> # Run with neverallows specified on the command-line. >> $ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow >> -n "neverallow user_t self:process signal;" >> >> # Run with neverallows from a separate file. >> $ cat > neverallows.conf <<EOF >> neverallow user_t self:process signal; >> EOF >> $ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow >> -f neverallows.conf >> >> There have been improvements to neverallow checking time upstream >> since RHEL 7, but it will still be a function of policy size and >> obviously RHEL has a much larger policy than Android... > > For reference, on Fedora 29: > > $ time sepolicy-analyze /etc/selinux/targeted/policy/policy.31 > neverallow -n "neverallow user_t self:capability mac_admin;" > > real 0m0.145s > user 0m0.133s > sys 0m0.012s Also, you can put multiple neverallow statements (semicolon separated) in the -n option value and have them all checked at once, or similarly multiple ones in the file. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: neverallow rules 2019-02-27 13:57 ` Stephen Smalley @ 2019-02-27 14:12 ` Stephen Smalley 0 siblings, 0 replies; 8+ messages in thread From: Stephen Smalley @ 2019-02-27 14:12 UTC (permalink / raw) To: Chris PeBenito, Joe Nall, selinux On 2/27/19 8:57 AM, Stephen Smalley wrote: > On 2/27/19 8:54 AM, Stephen Smalley wrote: >> On 2/27/19 8:48 AM, Stephen Smalley wrote: >>> On 2/27/19 8:29 AM, Stephen Smalley wrote: >>>> On 2/26/19 10:38 PM, Chris PeBenito wrote: >>>>> On Tue, 2019-02-26 at 19:29 -0600, Joe Nall wrote: >>>>>> Looking at neverallow rules, the semanage.conf file says >>>>>> "# expand-check check neverallow rules when executing all semanage >>>>>> commands. >>>>>> # Large penalty in time if you turn this on. " >>>>>> >>>>>> If I don't set expand-check=1, are the neverallow rules actually >>>>>> enforced? >>>>> >>>>> Nope. >>>>> >>>>>> If so, when? >>>>>> >>>>>> An semodule -i of a policy module with neverallow rules that are >>>>>> violated by the existing binary policy succeeds without complaint >>>>>> unless expand-check=1 in RHEL 7.6. This is not what I expected. >>>>>> >>>>>> The time taken by a trivial module installation goes from ~.3 seconds >>>>>> to ~14 seconds, so the time hit for expand-check is pretty serious. >>>>> >>>>> The reason for adding the expand-check option is because the >>>>> neverallow >>>>> checking is so expensive. >>>>> >>>>>> We are trying to establish some policy invariants to protect against >>>>>> unexpected/unnoticed RHEL upstream policy changes, some of which have >>>>>> bitten us recently. Any suggestions are welcome. >>>>> >>>>> One alternative would be to use the setools API to code up some policy >>>>> searches in Python, then process the results to find things you >>>>> do/don't want in your policy. >>>> >>>> The approach taken in Fedora/RHEL is to run make validate as part of >>>> the selinux-policy.spec recipe, which uses the validate target in >>>> the refpolicy Makefile, which manually runs semodule_link and >>>> semodule_expand to manually link and expand the modules and performs >>>> full checking. Then the cost is only paid at policy build time and >>>> is only applied for the neverallow rules and allow rules in the >>>> Fedora/RHEL policy, not for third party modules. If you are >>>> rebuilding the RHEL policy from source, you could add your >>>> neverallows to it there and the make validate should catch the >>>> violations. >>>> >>>> In Android, neverallow checking is done both at policy build time >>>> and as part of device certification. The latter is done using a >>>> sepolicy-analyze tool we originally contributed; it can take a >>>> separate neverallow rule configuration in source form and an already >>>> compiled kernel binary policy and check them against each other. >>>> That's useful for cases where you don't have policy sources. >>>> >>>> You can have libsemanage apply your own checker against policy as >>>> part of module transactions by specifying a [verify kernel] stanza >>>> in semanage.conf, see: >>>> http://selinuxproject.org/page/PolicyValidate >>> >>> Also, FWIW, you can obtain, build, and use sepolicy-analyze outside >>> of the Android build system as follows. If you are on RHEL 7, you >>> likely need/want to obtain the upstream selinux userspace and build >>> its version of libsepol.a for use below instead of using the >>> libsepol-static package from RHEL since that is likely too old. >>> >>> # Get source and build. >>> $ git clone https://android.googlesource.com/platform/system/sepolicy >>> $ cd sepolicy/tools/sepolicy-analyze >>> $ gcc -o sepolicy-analyze *.c /path/to/libsepol.a >>> >>> # Run with neverallows specified on the command-line. >>> $ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow >>> -n "neverallow user_t self:process signal;" >>> >>> # Run with neverallows from a separate file. >>> $ cat > neverallows.conf <<EOF >>> neverallow user_t self:process signal; >>> EOF >>> $ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow >>> -f neverallows.conf >>> >>> There have been improvements to neverallow checking time upstream >>> since RHEL 7, but it will still be a function of policy size and >>> obviously RHEL has a much larger policy than Android... >> >> For reference, on Fedora 29: >> >> $ time sepolicy-analyze /etc/selinux/targeted/policy/policy.31 >> neverallow -n "neverallow user_t self:capability mac_admin;" >> >> real 0m0.145s >> user 0m0.133s >> sys 0m0.012s > > Also, you can put multiple neverallow statements (semicolon separated) > in the -n option value and have them all checked at once, or similarly > multiple ones in the file. There is an error in the example above; mac_admin is a permission in capability2 rather than capability. By default, sepolicy-analyze doesn't warn about undefined classes/permissions/types because a given binary policy might not define everything used in a neverallow configuration and that is ok (i.e. if there is no matching type, class or permission, then it isn't possible for the neverallow to be violated). If you want it to detect such things, pass -w to neverallow, ala: $ sepolicy-analyze /etc/selinux/targeted/policy/policy.31 neverallow -w -n "neverallow user_t self:capability mac_admin;" Warning! Permission mac_admin used in neverallow undefined in class capability in policy being checked. Warning! Empty permission set These are only warnings however; they do not yield an error exit. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Non-DoD Source] Re: neverallow rules 2019-02-27 3:38 ` Chris PeBenito 2019-02-27 13:29 ` Stephen Smalley @ 2019-02-27 16:13 ` jwcart2 1 sibling, 0 replies; 8+ messages in thread From: jwcart2 @ 2019-02-27 16:13 UTC (permalink / raw) To: Chris PeBenito, Joe Nall, selinux On 2/26/19 10:38 PM, Chris PeBenito wrote: > On Tue, 2019-02-26 at 19:29 -0600, Joe Nall wrote: >> Looking at neverallow rules, the semanage.conf file says >> "# expand-check check neverallow rules when executing all semanage >> commands. >> # Large penalty in time if you turn this on. " >> >> If I don't set expand-check=1, are the neverallow rules actually >> enforced? > > Nope. > >> If so, when? >> >> An semodule -i of a policy module with neverallow rules that are >> violated by the existing binary policy succeeds without complaint >> unless expand-check=1 in RHEL 7.6. This is not what I expected. >> >> The time taken by a trivial module installation goes from ~.3 seconds >> to ~14 seconds, so the time hit for expand-check is pretty serious. > > The reason for adding the expand-check option is because the neverallow > checking is so expensive. > I guess RHEL 7.6 is using an older version of the libsepol and friends? I refactored neverallow checking back in 2015 (see commit9e6840e6) which greatly reduced the time and memory usage of neverallow checking. Jim >> We are trying to establish some policy invariants to protect against >> unexpected/unnoticed RHEL upstream policy changes, some of which have >> bitten us recently. Any suggestions are welcome. > > One alternative would be to use the setools API to code up some policy > searches in Python, then process the results to find things you > do/don't want in your policy. > -- James Carter <jwcart2@tycho.nsa.gov> National Security Agency ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-02-27 16:14 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-27 1:29 neverallow rules Joe Nall 2019-02-27 3:38 ` Chris PeBenito 2019-02-27 13:29 ` Stephen Smalley 2019-02-27 13:48 ` Stephen Smalley 2019-02-27 13:54 ` Stephen Smalley 2019-02-27 13:57 ` Stephen Smalley 2019-02-27 14:12 ` Stephen Smalley 2019-02-27 16:13 ` [Non-DoD Source] " jwcart2
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).