IronPort-PHdr: =?us-ascii?q?9a23=3A45FvWh/m4cPUsP9uRHKM819IXTAuvvDOBiVQ1KB+?=
 =?us-ascii?q?1+MfIJqq85mqBkHD//Il1AaPAd2CrakewLuM+4nbGkU4qa6bt34DdJEeHzQksu?=
 =?us-ascii?q?4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPERvjKwV1?=
 =?us-ascii?q?Ov71GonPhMiryuy+4ZLebxlViDanb75+Mhq6oAHPusILnYZsN6E9xwfTrHBVYe?=
 =?us-ascii?q?pW32RoJVySnxb4+Mi9+YNo/jpTtfw86cNOSL32cKskQ7NWCjQmKH0169bwtRbf?=
 =?us-ascii?q?VwuP52ATXXsQnxFVHgXK9hD6XpP2sivnqupw3TSRMMPqQbwoXzmp8rxmQwH0hi?=
 =?us-ascii?q?gZKzE58XnXis1ug6JdvBKhvAF0z4rNbI2IKPZyYqbRcNUUSmpbWsZaSjJPDIWy?=
 =?us-ascii?q?YYASC+YNJPhUo5X4q1YIsBCwBxSjBPn3xzFLm3H43bM03eojHgHI2wwvA9UAv3?=
 =?us-ascii?q?vbotjuKKcfUvq4wLXSwDnfbf5b3yr25ojSchAmpPGBRa9+cdbPxkk3FwPKkFOQ?=
 =?us-ascii?q?opH4MTOQzOsNt2yb4PRgVOmyjGMnsBx+oiO0y8cwiojGmoIVylfe+SV/24Y6P8?=
 =?us-ascii?q?e0SEF8Yd66CZZdsTyROYhuQs46Xm1ltyk3xqcGtJKmZiQG1psqywDFZ/CadYWD?=
 =?us-ascii?q?/wjtW/yLIThigXJoYLe/hxGv/ke+0uD8Tcy00EpSripCj9nMqmgB1xzN5ciDTf?=
 =?us-ascii?q?tw5luh1iyV1wDS9+FEOlo4lbbbKpE9wr4wkYAfsULfES/thEr6lqqWdkQg+uSw?=
 =?us-ascii?q?6uTnZKvppoOEOoNphQzzPb4il8yiDegiLAQDUHaX9f6h2LH7+E32WrRKjvk4kq?=
 =?us-ascii?q?nDt5DaINwWprWkDA9OyYsj9xa+ACum0NQfh3UHKklFdwidg4jmPFHOPuj0De2j?=
 =?us-ascii?q?jFS0jDdr2/fGM6XlApXMKHjDjbjgca9+60FC0gozy85Q55ZPB7EfL/L8RFXxuM?=
 =?us-ascii?q?bbDhAnKQy0xfjoCNFn2oMZQ2KPDbeTMLnOvl+Q+uIvP+6MaZcNuDb5Mfcl+uLu?=
 =?us-ascii?q?jWUillAHZqSpx4UYZ224Hvt8P0WVe2bjgtAEEW0SpAoxUPTqiEGeUT5Uf3uyW7?=
 =?us-ascii?q?w85ishB429E4jMWpuggKaf0yimHp1ZfHxGBkqQHnfvcoWOQ+0MZz6KIs99jjwE?=
 =?us-ascii?q?UqCsRJIv1B60sA/60LpnI/HO+iIGqJ3j1MJ65/HJmR4u8jx0CtyX03uRQGFsgm?=
 =?us-ascii?q?MIWzg20bhhrkxl0FiDy6l4g+dDGNxL/fxJSAY6NYXEz+x+Ed/9RhzOcs2OSFa8?=
 =?us-ascii?q?TdWsGSsxQc4pw98Sf0Z9HM2vjgjZ0Cq3B78YjKSLC4Yp8qLYxnTxIsF9y3Hc1K?=
 =?us-ascii?q?Y/lVUpXsxPNWi+jK5l6wfTH5LJk1mel6uydaUTxijN9GiBzWqPvEFYVwhwUarY?=
 =?us-ascii?q?UX0EZkvWsM72503cQL+vE7goLgxBycuaIKtQdtLplUlGROvkONnGf22+gXywCg?=
 =?us-ascii?q?iIx76Xd4rlZ2Ud0z/ACEgKlwAc42yGOREiCSi7uW7REDtuFVe8K3/rpMJ3s36q?=
 =?us-ascii?q?BnQ/zwiXYUlszfLh8RcOiO20UPgT168KvCo77j59Wl262oSSQ8uJoQVjfaVbZ9?=
 =?us-ascii?q?x1tEZO023btgx6OJP5B6B/j0ETckJ8uEa4k109EoxdleAypW4uiQ91LriVllhG?=
 =?us-ascii?q?cnnQiYj5J7n/MmDv+FWqbKnM1xfV19PAvu9F5ewxsVT4lBmgDEs563Fu2NQT1G?=
 =?us-ascii?q?GTrN2eARIbS5Pqel4+7Rlhv7XTaSR74Jnbgzkke7K5tj7ExsIBGPouyhHmecxW?=
 =?us-ascii?q?dqyDCkW6R9YXA8moNfwCh0mibhVCOvtbsqEzIZXiP9eP3q+mOK5C1A2viX9HqN?=
 =?us-ascii?q?RxzUuI7CpUUOPE358Zhfqf213DHxPhj166+v7tkIpJbnlGGnSlwCLpD6ZLa6Fy?=
 =?us-ascii?q?dJpNAmCrdYn//thindbJUmNE7lSqDFNOjNetcAeOdVb09Rdd2UQevTqsni7unB?=
 =?us-ascii?q?JulDR8lbaSxCzDxazZcRMDPmNaDD15gUzEPZm/j9dcWlOhKQcuik32tg7B26FH?=
 =?us-ascii?q?qfEnfCHoSkBScn2zdjs6Xw=3D=3D?=
Message-ID: <1513269771.18008.6.camel@tycho.nsa.gov>
Subject: Re: [BUG]kernel softlockup due to sidtab_search_context run for
 long time because of too many sidtab context node
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Casey Schaufler <casey@schaufler-ca.com>,
        yangjihong <yangjihong1@huawei.com>,
        "paul@paul-moore.com" <paul@paul-moore.com>,
        "eparis@parisplace.org" <eparis@parisplace.org>,
        "selinux@tycho.nsa.gov" <selinux@tycho.nsa.gov>,
        Daniel J Walsh <dwalsh@redhat.com>, Lukas Vrabec <lvrabec@redhat.com>,
        Petr Lautrbach <plautrba@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Date: Thu, 14 Dec 2017 11:42:51 -0500
In-Reply-To: <23c51943-51a4-4478-760f-375d02caa39b@schaufler-ca.com>
References: <1BC3DBD98AD61A4A9B2569BC1C0B4437D5D1F3@DGGEMM506-MBS.china.huawei.com>
         <1513178296.19161.8.camel@tycho.nsa.gov>
         <23c51943-51a4-4478-760f-375d02caa39b@schaufler-ca.com>
Organization: National Security Agency
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 6510
Lines: 157

On Thu, 2017-12-14 at 08:18 -0800, Casey Schaufler wrote:
> On 12/13/2017 7:18 AM, Stephen Smalley wrote:
> > On Wed, 2017-12-13 at 09:25 +0000, yangjihong wrote:
> > > Hello, 
> > > 
> > > I am doing stressing testing on 3.10 kernel(centos 7.4), to
> > > constantly starting numbers of docker ontainers with selinux
> > > enabled,
> > > and after about 2 days, the kernel softlockup panic:
> > >  <IRQ>  [<ffffffff810bb778>] sched_show_task+0xb8/0x120
> > >  [<ffffffff8116133f>] show_lock_info+0x20f/0x3a0
> > >  [<ffffffff811226aa>] watchdog_timer_fn+0x1da/0x2f0
> > >  [<ffffffff811224d0>] ? watchdog_enable_all_cpus.part.4+0x40/0x40
> > >  [<ffffffff810abf82>] __hrtimer_run_queues+0xd2/0x260
> > >  [<ffffffff810ac520>] hrtimer_interrupt+0xb0/0x1e0
> > >  [<ffffffff8104a477>] local_apic_timer_interrupt+0x37/0x60
> > >  [<ffffffff8166fd90>] smp_apic_timer_interrupt+0x50/0x140
> > >  [<ffffffff8166e1dd>] apic_timer_interrupt+0x6d/0x80
> > >  <EOI>  [<ffffffff812b4193>] ? sidtab_context_to_sid+0xb3/0x480
> > >  [<ffffffff812b41f0>] ? sidtab_context_to_sid+0x110/0x480
> > >  [<ffffffff812c0d15>] ? mls_setup_user_range+0x145/0x250
> > >  [<ffffffff812bd477>] security_get_user_sids+0x3f7/0x550
> > >  [<ffffffff812b1a8b>] sel_write_user+0x12b/0x210
> > >  [<ffffffff812b1960>] ? sel_write_member+0x200/0x200
> > >  [<ffffffff812b01d8>] selinux_transaction_write+0x48/0x80
> > >  [<ffffffff811f444d>] vfs_write+0xbd/0x1e0
> > >  [<ffffffff811f4eef>] SyS_write+0x7f/0xe0
> > >  [<ffffffff8166d433>] system_call_fastpath+0x16/0x1b
> > > 
> > > My opinion:
> > > when the docker container starts, it would mount overlay
> > > filesystem
> > > with different selinux context, mount point such as: 
> > > overlay on
> > > /var/lib/docker/overlay2/be3ef517730d92fc4530e0e952eae4f6cb0f07b4
> > > bc32
> > > 6cb07495ca08fc9ddb66/merged type overlay
> > > (rw,relatime,context="system_u:object_r:svirt_sandbox_file_t:s0:c
> > > 414,
> > > c873",lowerdir=/var/lib/docker/overlay2/l/Z4U7WY6ASNV5CFWLADPARHH
> > > WY7:
> > > /var/lib/docker/overlay2/l/V2S3HOKEFEOQLHBVAL5WLA3YLS:/var/lib/do
> > > cker
> > > /overlay2/l/46YGYO474KLOULZGDSZDW2JPRI,upperdir=/var/lib/docker/o
> > > verl
> > > ay2/be3ef517730d92fc4530e0e952eae4f6cb0f07b4bc326cb07495ca08fc9dd
> > > b66/
> > > diff,workdir=/var/lib/docker/overlay2/be3ef517730d92fc4530e0e952e
> > > ae4f
> > > 6cb0f07b4bc326cb07495ca08fc9ddb66/work)
> > > shm on
> > > /var/lib/docker/containers/9fd65e177d2132011d7b422755793449c91327
> > > ca57
> > > 7b8f5d9d6a4adf218d4876/shm type tmpfs
> > > (rw,nosuid,nodev,noexec,relatime,context="system_u:object_r:svirt
> > > _san
> > > dbox_file_t:s0:c414,c873",size=65536k)
> > > overlay on
> > > /var/lib/docker/overlay2/38d1544d080145c7d76150530d0255991dfb7258
> > > cbca
> > > 14ff6d165b94353eefab/merged type overlay
> > > (rw,relatime,context="system_u:object_r:svirt_sandbox_file_t:s0:c
> > > 431,
> > > c651",lowerdir=/var/lib/docker/overlay2/l/3MQQXB4UCLFB7ANVRHPAVRC
> > > RSS:
> > > /var/lib/docker/overlay2/l/46YGYO474KLOULZGDSZDW2JPRI,upperdir=/v
> > > ar/l
> > > ib/docker/overlay2/38d1544d080145c7d76150530d0255991dfb7258cbca14
> > > ff6d
> > > 165b94353eefab/diff,workdir=/var/lib/docker/overlay2/38d1544d0801
> > > 45c7
> > > d76150530d0255991dfb7258cbca14ff6d165b94353eefab/work)
> > > shm on
> > > /var/lib/docker/containers/662e7f798fc08b09eae0f0f944537a4bcedc1d
> > > cf05
> > > a65866458523ffd4a71614/shm type tmpfs
> > > (rw,nosuid,nodev,noexec,relatime,context="system_u:object_r:svirt
> > > _san
> > > dbox_file_t:s0:c431,c651",size=65536k)
> > > 
> > > sidtab_search_context check the context whether is in the sidtab
> > > list, If not found, a new node is generated and insert into the
> > > list,
> > > As the number of containers is increasing,  context nodes are
> > > also
> > > more and more, we tested the final number of nodes reached
> > > 300,000 +,
> > > sidtab_context_to_sid runtime needs 100-200ms, which will lead to
> > > the
> > > system softlockup.
> > > 
> > > Is this a selinux bug? When filesystem umount, why context node
> > > is
> > > not deleted?  I cannot find the relevant function to delete the
> > > node
> > > in sidtab.c
> > > 
> > > Thanks for reading and looking forward to your reply.
> > 
> > So, does docker just keep allocating a unique category set for
> > every
> > new container, never reusing them even if the container is
> > destroyed? 
> > That would be a bug in docker IMHO.  Or are you creating an
> > unbounded
> > number of containers and never destroying the older ones?
> 
> You can't reuse the security context. A process in ContainerA sends
> a labeled packet to MachineB. ContainerA goes away and its context
> is recycled in ContainerC. MachineB responds some time later, again
> with a labeled packet. ContainerC gets information intended for
> ContainerA, and uses the information to take over the Elbonian
> government.

Docker isn't using labeled networking (nor is anything else by default;
it is only enabled if explicitly configured).

> 
> > On the selinux userspace side, we'd also like to eliminate the use
> > of
> > /sys/fs/selinux/user (sel_write_user -> security_get_user_sids)
> > entirely, which is what triggered this for you.
> > 
> > We cannot currently delete a sidtab node because we have no way of
> > knowing if there are any lingering references to the SID.  Fixing
> > that
> > would require reference-counted SIDs, which goes beyond just
> > SELinux
> > since SIDs/secids are returned by LSM hooks and cached in other
> > kernel
> > data structures.
> 
> You could delete a sidtab node. The code already deals with
> unfindable
> SIDs. The issue is that eventually you run out of SIDs. Then you are
> forced to recycle SIDs, which leads to the overthrow of the Elbonian
> government.

We don't know when we can safely delete a sidtab node since SIDs aren't
reference counted and we can't know whether it is still in use
somewhere in the kernel.  Doing so prematurely would lead to the SID
being remapped to the unlabeled context, and then likely to undesired
denials.

> 
> > sidtab_search_context() could no doubt be optimized for the
> > negative
> > case; there was an earlier optimization for the positive case by
> > adding
> > a cache to sidtab_context_to_sid() prior to calling it.  It's a
> > reverse
> > lookup in the sidtab.
> 
> This seems like a bad idea.

Not sure what you mean, but it can certainly be changed to at least use
a hash table for these reverse lookups.