* [refpolicy] Non root users fail to login after switch to latest kernel
@ 2012-10-05 3:34 Subodh Nijsure
2012-10-05 13:51 ` Stephen Smalley
0 siblings, 1 reply; 8+ messages in thread
From: Subodh Nijsure @ 2012-10-05 3:34 UTC (permalink / raw)
To: refpolicy
Hello,
We have been running SELinux on our embedded platform for almost 18 months.
We have been using kernel revision - 2.6.31. Since our platform only has 64MB
memory we decided roll out our own policy.
Recently we have upgrade our linux kernel to version 3.5-rc4 again with our
policy every thing is working, except one thing, login for any user other
than root doesn't work.
Login at console works if I apply change shown below to commoncap.c, which not
exactly correct.
-------------------
diff --git a/security/commoncap.c b/security/commoncap.c
index 6dbae46..074cd74 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -83,7 +83,7 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
/* Do we have the necessary capabilities? */
if (targ_ns == cred->user_ns)
- return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
+ return cap_raised(cred->cap_effective, cap) ? 0 : 0;
/* Have we tried all of the parent namespaces? */
if (targ_ns == &init_user_ns)
-------------------
So it looks like the users definition is missing some capabilities?
I don't even see any avc messages.
When I try to login over ssh I consistantly see this message:
Jan 1 05:58:14 192.168.137.1 sshd[928]: error: open /dev/tty failed - could not set controlling tty: Permission denied
However root user login at console or ssh work just fine.
I would appreciate any pointers/clues as to what I should look in my policy definitions that is preventing users other than root from logging into the system?
-Subodh
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [refpolicy] Non root users fail to login after switch to latest kernel
2012-10-05 3:34 [refpolicy] Non root users fail to login after switch to latest kernel Subodh Nijsure
@ 2012-10-05 13:51 ` Stephen Smalley
2012-10-05 15:17 ` Subodh Nijsure
0 siblings, 1 reply; 8+ messages in thread
From: Stephen Smalley @ 2012-10-05 13:51 UTC (permalink / raw)
To: refpolicy
On Fri, 2012-10-05 at 03:34 +0000, Subodh Nijsure wrote:
> Hello,
>
> We have been running SELinux on our embedded platform for almost 18 months.
> We have been using kernel revision - 2.6.31. Since our platform only has 64MB
> memory we decided roll out our own policy.
>
> Recently we have upgrade our linux kernel to version 3.5-rc4 again with our
> policy every thing is working, except one thing, login for any user other
> than root doesn't work.
>
> Login at console works if I apply change shown below to commoncap.c, which not
> exactly correct.
>
> -------------------
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 6dbae46..074cd74 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -83,7 +83,7 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
>
> /* Do we have the necessary capabilities? */
> if (targ_ns == cred->user_ns)
> - return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
> + return cap_raised(cred->cap_effective, cap) ? 0 : 0;
>
> /* Have we tried all of the parent namespaces? */
> if (targ_ns == &init_user_ns)
> -------------------
>
> So it looks like the users definition is missing some capabilities?
> I don't even see any avc messages.
Unless you are using them, I'd recommend disabling user namespaces in
your kernel. They are marked as experimental. This has nothing to do
with SELinux. CONFIG_USER_NS=n
--
Stephen Smalley
National Security Agency
^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] Non root users fail to login after switch to latest kernel
2012-10-05 13:51 ` Stephen Smalley
@ 2012-10-05 15:17 ` Subodh Nijsure
2012-10-05 16:24 ` Stephen Smalley
0 siblings, 1 reply; 8+ messages in thread
From: Subodh Nijsure @ 2012-10-05 15:17 UTC (permalink / raw)
To: refpolicy
On Fri, 2012-10-05 at 03:34 +0000, Subodh Nijsure wrote:
>> Hello,
>>
>> We have been running SELinux on our embedded platform for almost 18 months.
>> We have been using kernel revision - 2.6.31. Since our platform only has 64MB
>> memory we decided roll out our own policy.
>>
>> Recently we have upgrade our linux kernel to version 3.5-rc4 again with our
>> policy every thing is working, except one thing, login for any user other
>> than root doesn't work.
>>
>> Login at console works if I apply change shown below to commoncap.c, which not
>> exactly correct.
>>
>> -------------------
>> diff --git a/security/commoncap.c b/security/commoncap.c
>> index 6dbae46..074cd74 100644
>> --- a/security/commoncap.c
>> +++ b/security/commoncap.c
>> @@ -83,7 +83,7 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
>>
>> /* Do we have the necessary capabilities? */
>> if (targ_ns == cred->user_ns)
>> - return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
>> + return cap_raised(cred->cap_effective, cap) ? 0 : 0;
>>
>> /* Have we tried all of the parent namespaces? */
>> if (targ_ns == &init_user_ns)
>> -------------------
>>
>> So it looks like the users definition is missing some capabilities?
>> I don't even see any avc messages.
>Unless you are using them, I'd recommend disabling user namespaces in
>your kernel. They are marked as experimental. This has nothing to do
>with SELinux. CONFIG_USER_NS=n
Actually CONFIG_USER_NS is not set in the kernel configuration and its off by default.
Also I have verified that it is not defined by adding a check in kernel source file (#ifdef CONFIG_USER_NS / #error "CONFIG_USER_NS_DEFINED")...
So CONFIG_USER_NS=y doesn't appear to be issue?
It appears that if USER_NS is not defined then the kernel uses the init_user_ns should I be assigning capabilities to "initrc" user in my policy?
Should I move this question to linux-security instead of selinux?
Regards,
-Subodh
^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] Non root users fail to login after switch to latest kernel
2012-10-05 15:17 ` Subodh Nijsure
@ 2012-10-05 16:24 ` Stephen Smalley
2012-10-05 16:46 ` Stephen Smalley
0 siblings, 1 reply; 8+ messages in thread
From: Stephen Smalley @ 2012-10-05 16:24 UTC (permalink / raw)
To: refpolicy
On Fri, 2012-10-05 at 15:17 +0000, Subodh Nijsure wrote:
> On Fri, 2012-10-05 at 03:34 +0000, Subodh Nijsure wrote:
> >> Hello,
> >>
> >> We have been running SELinux on our embedded platform for almost 18 months.
> >> We have been using kernel revision - 2.6.31. Since our platform only has 64MB
> >> memory we decided roll out our own policy.
> >>
> >> Recently we have upgrade our linux kernel to version 3.5-rc4 again with our
> >> policy every thing is working, except one thing, login for any user other
> >> than root doesn't work.
> >>
> >> Login at console works if I apply change shown below to commoncap.c, which not
> >> exactly correct.
> >>
> >> -------------------
> >> diff --git a/security/commoncap.c b/security/commoncap.c
> >> index 6dbae46..074cd74 100644
> >> --- a/security/commoncap.c
> >> +++ b/security/commoncap.c
> >> @@ -83,7 +83,7 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
> >>
> >> /* Do we have the necessary capabilities? */
> >> if (targ_ns == cred->user_ns)
> >> - return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
> >> + return cap_raised(cred->cap_effective, cap) ? 0 : 0;
> >>
> >> /* Have we tried all of the parent namespaces? */
> >> if (targ_ns == &init_user_ns)
> >> -------------------
> >>
> >> So it looks like the users definition is missing some capabilities?
> >> I don't even see any avc messages.
>
> >Unless you are using them, I'd recommend disabling user namespaces in
> >your kernel. They are marked as experimental. This has nothing to do
> >with SELinux. CONFIG_USER_NS=n
>
> Actually CONFIG_USER_NS is not set in the kernel configuration and its off by default.
> Also I have verified that it is not defined by adding a check in kernel source file (#ifdef CONFIG_USER_NS / #error "CONFIG_USER_NS_DEFINED")...
>
> So CONFIG_USER_NS=y doesn't appear to be issue?
>
> It appears that if USER_NS is not defined then the kernel uses the init_user_ns should I be assigning capabilities to "initrc" user in my policy?
>
> Should I move this question to linux-security instead of selinux?
Can you confirm that it happens even if SELinux is permissive?
Because your patch has nothing to do with SELinux.
If it happens even with SELinux in permissive, then yes, I'd take it to
linux-security-module.
--
Stephen Smalley
National Security Agency
^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] Non root users fail to login after switch to latest kernel
2012-10-05 16:24 ` Stephen Smalley
@ 2012-10-05 16:46 ` Stephen Smalley
2012-10-05 16:57 ` Subodh Nijsure
0 siblings, 1 reply; 8+ messages in thread
From: Stephen Smalley @ 2012-10-05 16:46 UTC (permalink / raw)
To: refpolicy
On Fri, 2012-10-05 at 12:24 -0400, Stephen Smalley wrote:
> On Fri, 2012-10-05 at 15:17 +0000, Subodh Nijsure wrote:
> > On Fri, 2012-10-05 at 03:34 +0000, Subodh Nijsure wrote:
> > >> Hello,
> > >>
> > >> We have been running SELinux on our embedded platform for almost 18 months.
> > >> We have been using kernel revision - 2.6.31. Since our platform only has 64MB
> > >> memory we decided roll out our own policy.
> > >>
> > >> Recently we have upgrade our linux kernel to version 3.5-rc4 again with our
> > >> policy every thing is working, except one thing, login for any user other
> > >> than root doesn't work.
> > >>
> > >> Login at console works if I apply change shown below to commoncap.c, which not
> > >> exactly correct.
> > >>
> > >> -------------------
> > >> diff --git a/security/commoncap.c b/security/commoncap.c
> > >> index 6dbae46..074cd74 100644
> > >> --- a/security/commoncap.c
> > >> +++ b/security/commoncap.c
> > >> @@ -83,7 +83,7 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
> > >>
> > >> /* Do we have the necessary capabilities? */
> > >> if (targ_ns == cred->user_ns)
> > >> - return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
> > >> + return cap_raised(cred->cap_effective, cap) ? 0 : 0;
> > >>
> > >> /* Have we tried all of the parent namespaces? */
> > >> if (targ_ns == &init_user_ns)
> > >> -------------------
> > >>
> > >> So it looks like the users definition is missing some capabilities?
> > >> I don't even see any avc messages.
> >
> > >Unless you are using them, I'd recommend disabling user namespaces in
> > >your kernel. They are marked as experimental. This has nothing to do
> > >with SELinux. CONFIG_USER_NS=n
> >
> > Actually CONFIG_USER_NS is not set in the kernel configuration and its off by default.
> > Also I have verified that it is not defined by adding a check in kernel source file (#ifdef CONFIG_USER_NS / #error "CONFIG_USER_NS_DEFINED")...
> >
> > So CONFIG_USER_NS=y doesn't appear to be issue?
> >
> > It appears that if USER_NS is not defined then the kernel uses the init_user_ns should I be assigning capabilities to "initrc" user in my policy?
> >
> > Should I move this question to linux-security instead of selinux?
>
> Can you confirm that it happens even if SELinux is permissive?
> Because your patch has nothing to do with SELinux.
> If it happens even with SELinux in permissive, then yes, I'd take it to
> linux-security-module.
Also, you should check whether it happens with an actual released
kernel, not just an -rc kernel. 3.5.5 or 3.6
--
Stephen Smalley
National Security Agency
^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] Non root users fail to login after switch to latest kernel
2012-10-05 16:46 ` Stephen Smalley
@ 2012-10-05 16:57 ` Subodh Nijsure
2012-10-05 16:59 ` Stephen Smalley
0 siblings, 1 reply; 8+ messages in thread
From: Subodh Nijsure @ 2012-10-05 16:57 UTC (permalink / raw)
To: refpolicy
>On Fri, 2012-10-05 at 12:24 -0400, Stephen Smalley wrote:
>> On Fri, 2012-10-05 at 15:17 +0000, Subodh Nijsure wrote:
>> > On Fri, 2012-10-05 at 03:34 +0000, Subodh Nijsure wrote:
>> > >> Hello,
>> > >>
>> > >> We have been running SELinux on our embedded platform for almost 18 months.
>> > >> We have been using kernel revision - 2.6.31. Since our platform only has 64MB
>> > >> memory we decided roll out our own policy.
>> > >>
>> > >> Recently we have upgrade our linux kernel to version 3.5-rc4 again with our
>> > >> policy every thing is working, except one thing, login for any user other
>> > >> than root doesn't work.
>> > >>
>> > >> Login at console works if I apply change shown below to commoncap.c, which not
>> > >> exactly correct.
>> > >>
>> > >> -------------------
>> > >> diff --git a/security/commoncap.c b/security/commoncap.c
>> > >> index 6dbae46..074cd74 100644
>> > >> --- a/security/commoncap.c
>> > >> +++ b/security/commoncap.c
>> > >> @@ -83,7 +83,7 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
>> > >>
>> > >> /* Do we have the necessary capabilities? */
>> > >> if (targ_ns == cred->user_ns)
>> > >> - return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
>> > >> + return cap_raised(cred->cap_effective, cap) ? 0 : 0;
>> > >>
>> > >> /* Have we tried all of the parent namespaces? */
>> > >> if (targ_ns == &init_user_ns)
>> > >> -------------------
>> > >>
>> > >> So it looks like the users definition is missing some capabilities?
>> > >> I don't even see any avc messages.
>> >
>> > >Unless you are using them, I'd recommend disabling user namespaces in
>> > >your kernel. They are marked as experimental. This has nothing to do
>> > >with SELinux. CONFIG_USER_NS=n
>> >
>> > Actually CONFIG_USER_NS is not set in the kernel configuration and its off by default.
>> > Also I have verified that it is not defined by adding a check in kernel source file (#ifdef CONFIG_USER_NS / #error "CONFIG_USER_NS_DEFINED")...
>> >
>> > So CONFIG_USER_NS=y doesn't appear to be issue?
>> >
>> > It appears that if USER_NS is not defined then the kernel uses the init_user_ns should I be assigning capabilities to "initrc" user in my policy?
>> >
>> > Should I move this question to linux-security instead of selinux?
>>
>> Can you confirm that it happens even if SELinux is permissive?
>> Because your patch has nothing to do with SELinux.
>> If it happens even with SELinux in permissive, then yes, I'd take it to
>> linux-security-module.
>
>Also, you should check whether it happens with an actual released
>kernel, not just an -rc kernel. 3.5.5 or 3.6
>
Indeed I get same behavior even if SELINUX is in permissive mode.
I will try do run things with older kernels, it may take me some time to figure this out, platform (ARM MX28) depends on some of the latest device-tree stuff to run.
I will take this thread to linux-security and attach my kernel config file.
Thanks.
-Subodh
^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] Non root users fail to login after switch to latest kernel
2012-10-05 16:57 ` Subodh Nijsure
@ 2012-10-05 16:59 ` Stephen Smalley
2012-10-05 17:07 ` Stephen Smalley
0 siblings, 1 reply; 8+ messages in thread
From: Stephen Smalley @ 2012-10-05 16:59 UTC (permalink / raw)
To: refpolicy
On Fri, 2012-10-05 at 16:57 +0000, Subodh Nijsure wrote:
> >On Fri, 2012-10-05 at 12:24 -0400, Stephen Smalley wrote:
> >> On Fri, 2012-10-05 at 15:17 +0000, Subodh Nijsure wrote:
> >> > On Fri, 2012-10-05 at 03:34 +0000, Subodh Nijsure wrote:
> >> > >> Hello,
> >> > >>
> >> > >> We have been running SELinux on our embedded platform for almost 18 months.
> >> > >> We have been using kernel revision - 2.6.31. Since our platform only has 64MB
> >> > >> memory we decided roll out our own policy.
> >> > >>
> >> > >> Recently we have upgrade our linux kernel to version 3.5-rc4 again with our
> >> > >> policy every thing is working, except one thing, login for any user other
> >> > >> than root doesn't work.
> >> > >>
> >> > >> Login at console works if I apply change shown below to commoncap.c, which not
> >> > >> exactly correct.
> >> > >>
> >> > >> -------------------
> >> > >> diff --git a/security/commoncap.c b/security/commoncap.c
> >> > >> index 6dbae46..074cd74 100644
> >> > >> --- a/security/commoncap.c
> >> > >> +++ b/security/commoncap.c
> >> > >> @@ -83,7 +83,7 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
> >> > >>
> >> > >> /* Do we have the necessary capabilities? */
> >> > >> if (targ_ns == cred->user_ns)
> >> > >> - return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
> >> > >> + return cap_raised(cred->cap_effective, cap) ? 0 : 0;
> >> > >>
> >> > >> /* Have we tried all of the parent namespaces? */
> >> > >> if (targ_ns == &init_user_ns)
> >> > >> -------------------
> >> > >>
> >> > >> So it looks like the users definition is missing some capabilities?
> >> > >> I don't even see any avc messages.
> >> >
> >> > >Unless you are using them, I'd recommend disabling user namespaces in
> >> > >your kernel. They are marked as experimental. This has nothing to do
> >> > >with SELinux. CONFIG_USER_NS=n
> >> >
> >> > Actually CONFIG_USER_NS is not set in the kernel configuration and its off by default.
> >> > Also I have verified that it is not defined by adding a check in kernel source file (#ifdef CONFIG_USER_NS / #error "CONFIG_USER_NS_DEFINED")...
> >> >
> >> > So CONFIG_USER_NS=y doesn't appear to be issue?
> >> >
> >> > It appears that if USER_NS is not defined then the kernel uses the init_user_ns should I be assigning capabilities to "initrc" user in my policy?
> >> >
> >> > Should I move this question to linux-security instead of selinux?
> >>
> >> Can you confirm that it happens even if SELinux is permissive?
> >> Because your patch has nothing to do with SELinux.
> >> If it happens even with SELinux in permissive, then yes, I'd take it to
> >> linux-security-module.
> >
> >Also, you should check whether it happens with an actual released
> >kernel, not just an -rc kernel. 3.5.5 or 3.6
> >
> Indeed I get same behavior even if SELINUX is in permissive mode.
>
> I will try do run things with older kernels, it may take me some time to figure this out, platform (ARM MX28) depends on some of the latest device-tree stuff to run.
3.5.5 or 3.6.0 (both available from kernel.org) are newer than 3.5-rc4
(a release candidate for 3.5, before 3.5.0 was released), so you
shouldn't have a problem testing them.
--
Stephen Smalley
National Security Agency
^ permalink raw reply [flat|nested] 8+ messages in thread
* [refpolicy] Non root users fail to login after switch to latest kernel
2012-10-05 16:59 ` Stephen Smalley
@ 2012-10-05 17:07 ` Stephen Smalley
0 siblings, 0 replies; 8+ messages in thread
From: Stephen Smalley @ 2012-10-05 17:07 UTC (permalink / raw)
To: refpolicy
On Fri, 2012-10-05 at 12:59 -0400, Stephen Smalley wrote:
> On Fri, 2012-10-05 at 16:57 +0000, Subodh Nijsure wrote:
> > >On Fri, 2012-10-05 at 12:24 -0400, Stephen Smalley wrote:
> > >> On Fri, 2012-10-05 at 15:17 +0000, Subodh Nijsure wrote:
> > >> > On Fri, 2012-10-05 at 03:34 +0000, Subodh Nijsure wrote:
> > >> > >> Hello,
> > >> > >>
> > >> > >> We have been running SELinux on our embedded platform for almost 18 months.
> > >> > >> We have been using kernel revision - 2.6.31. Since our platform only has 64MB
> > >> > >> memory we decided roll out our own policy.
> > >> > >>
> > >> > >> Recently we have upgrade our linux kernel to version 3.5-rc4 again with our
> > >> > >> policy every thing is working, except one thing, login for any user other
> > >> > >> than root doesn't work.
> > >> > >>
> > >> > >> Login at console works if I apply change shown below to commoncap.c, which not
> > >> > >> exactly correct.
> > >> > >>
> > >> > >> -------------------
> > >> > >> diff --git a/security/commoncap.c b/security/commoncap.c
> > >> > >> index 6dbae46..074cd74 100644
> > >> > >> --- a/security/commoncap.c
> > >> > >> +++ b/security/commoncap.c
> > >> > >> @@ -83,7 +83,7 @@ int cap_capable(const struct cred *cred, struct user_namespace *targ_ns,
> > >> > >>
> > >> > >> /* Do we have the necessary capabilities? */
> > >> > >> if (targ_ns == cred->user_ns)
> > >> > >> - return cap_raised(cred->cap_effective, cap) ? 0 : -EPERM;
> > >> > >> + return cap_raised(cred->cap_effective, cap) ? 0 : 0;
> > >> > >>
> > >> > >> /* Have we tried all of the parent namespaces? */
> > >> > >> if (targ_ns == &init_user_ns)
> > >> > >> -------------------
> > >> > >>
> > >> > >> So it looks like the users definition is missing some capabilities?
> > >> > >> I don't even see any avc messages.
> > >> >
> > >> > >Unless you are using them, I'd recommend disabling user namespaces in
> > >> > >your kernel. They are marked as experimental. This has nothing to do
> > >> > >with SELinux. CONFIG_USER_NS=n
> > >> >
> > >> > Actually CONFIG_USER_NS is not set in the kernel configuration and its off by default.
> > >> > Also I have verified that it is not defined by adding a check in kernel source file (#ifdef CONFIG_USER_NS / #error "CONFIG_USER_NS_DEFINED")...
> > >> >
> > >> > So CONFIG_USER_NS=y doesn't appear to be issue?
> > >> >
> > >> > It appears that if USER_NS is not defined then the kernel uses the init_user_ns should I be assigning capabilities to "initrc" user in my policy?
> > >> >
> > >> > Should I move this question to linux-security instead of selinux?
> > >>
> > >> Can you confirm that it happens even if SELinux is permissive?
> > >> Because your patch has nothing to do with SELinux.
> > >> If it happens even with SELinux in permissive, then yes, I'd take it to
> > >> linux-security-module.
> > >
> > >Also, you should check whether it happens with an actual released
> > >kernel, not just an -rc kernel. 3.5.5 or 3.6
> > >
> > Indeed I get same behavior even if SELINUX is in permissive mode.
> >
> > I will try do run things with older kernels, it may take me some time to figure this out, platform (ARM MX28) depends on some of the latest device-tree stuff to run.
>
> 3.5.5 or 3.6.0 (both available from kernel.org) are newer than 3.5-rc4
> (a release candidate for 3.5, before 3.5.0 was released), so you
> shouldn't have a problem testing them.
Also, it would help to know exactly what called cap_capable() and with
what arguments when it failed. Maybe call dump_stack() from
cap_capable() in the EPERM case?
--
Stephen Smalley
National Security Agency
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-10-05 17:07 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-05 3:34 [refpolicy] Non root users fail to login after switch to latest kernel Subodh Nijsure
2012-10-05 13:51 ` Stephen Smalley
2012-10-05 15:17 ` Subodh Nijsure
2012-10-05 16:24 ` Stephen Smalley
2012-10-05 16:46 ` Stephen Smalley
2012-10-05 16:57 ` Subodh Nijsure
2012-10-05 16:59 ` Stephen Smalley
2012-10-05 17:07 ` Stephen Smalley
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.