From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7D6331396D0 for ; Sat, 23 Sep 2017 05:18:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BD5191FC1C3; Sat, 23 Sep 2017 05:18:17 +0000 (UTC) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6E565E082B for ; Sat, 23 Sep 2017 05:18:17 +0000 (UTC) Received: by mail-yw0-x244.google.com with SMTP id t127so1490479ywg.5 for ; Fri, 22 Sep 2017 22:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=MiwXMRG/WF0mww0+NgCHTBjBp+URu9EJUD+rgMcRroE=; b=AGg434JUcOmqlgsBi2li4ph1Uz3qkAFBfTASqYf6Xi1n55fOLaeHaWtOVSHCMep+37 0aDmuPvDJthA6S7A5UX1ottYYOgkvsEF44i+4Z4tmT0k9b6/j0RHlfpWKI0PCGycUcsZ KKdRXP/rhSeAEOPzztwfMArrq/8VW8UsNJMTISzTWGAbxewlyLeHmpTNDUsBSZfmvZKv g7NE+5HtqJwsbh3XQrhKLuU8W/lv0KTuqGJfTOU7BrLI2irNIaIUtaxamwwRau86udJC LQwTNnhnF38uikOuAqYQH14eCW9B7ozEPbP5eJCW/vNkUhxHxBqfOCLIDBFM825Npb// yssA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=MiwXMRG/WF0mww0+NgCHTBjBp+URu9EJUD+rgMcRroE=; b=b1qU3n8SnyviLg2TxLSjDHHMDeOe1K112xij6TmGknSQmqZ1WZe8jl+ohawgnotWaH JiWT5jz6PZH7VqBBteoo6XK64T1VR7/odLnAO8iba+C6GcYVPRb0r+bFvnRd7UVaYKng MGGWXuSCTU9GhqXMlPLV9XuZ7ADkP3Egaaojzlz7aYtcGIGTCEdBI5XBE00pxcdy8lu+ mTyoINSL8Dsi4JemnL6Ymvns8HCz68TMwJxwbL7iOAFBKnyFza9ZBD1yUKoF/2UEfvXh cwUYQdHRVdAyXLGxQo/sO54bBHAk1cMkxAr6vlgrGa8e0tczoS/9ji7FXuEHY1Lr3GzJ 3oCw== X-Gm-Message-State: AHPjjUiyZ2HCZwUTzGHoZ57ZDiNBShZUp20C9kdQZk9Km7g513vli5wS XvyrDnK5yj9RtDl8qWl4jGXrOHtAduGdGYhAykHTxw== X-Google-Smtp-Source: AOwi7QAt690LTtVhtrVLX3K3p3N67RGVeeilQhzpQBnf4uH6JtwADWTEFCULpF8B1hnUpJnazIAi31+hyU4l18CXFgQ= X-Received: by 10.37.210.8 with SMTP id j8mr790628ybg.317.1506143896012; Fri, 22 Sep 2017 22:18:16 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.129.131.138 with HTTP; Fri, 22 Sep 2017 22:18:15 -0700 (PDT) In-Reply-To: References: <1506023769.15165.14.camel@gentoo.org> From: R0b0t1 Date: Sat, 23 Sep 2017 00:18:15 -0500 Message-ID: Subject: Re: [gentoo-dev] Reviving the Sandbox project To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 45ef474a-5338-4e87-8f17-6f9c1e6e1546 X-Archives-Hash: fe3504f9a0eaf31a7901e92a65e4b28b On Fri, Sep 22, 2017 at 5:01 PM, Michael Orlitzky wrote: > On 09/22/2017 05:51 PM, R0b0t1 wrote: >> On Thu, Sep 21, 2017 at 2:56 PM, Micha=C5=82 G=C3=B3rny wrote: >>> [1]:https://wiki.gentoo.org/wiki/Project:Sandbox >>> >> >> I think I understand, in principle, why a sandbox could be useful, but >> would it not be more productive to follow up with projects which do >> unexpected things to ask that they not do those things? >> > > The sandbox isn't a security feature, it's more of a QA tool. How do you > *know* when the upstream project does something wrong? See, for example, > I was aware of this part. I suggested sandboxing mechanisms which were security related not for security purposes, but due to the fact that their original design goals makes them more comprehensive. As a bonus, they already exist. On Fri, Sep 22, 2017 at 5:05 PM, Alec Warner wrote: > > > On Fri, Sep 22, 2017 at 5:51 PM, R0b0t1 wrote: >> >> On Thu, Sep 21, 2017 at 2:56 PM, Micha=C5=82 G=C3=B3rny wrote: >> > [1]:https://wiki.gentoo.org/wiki/Project:Sandbox >> > >> >> I think I understand, in principle, why a sandbox could be useful, but >> would it not be more productive to follow up with projects which do >> unexpected things to ask that they not do those things? > > > So step one is figuring out what those things are. So the LD_PRELOAD sand= box > isn't designed to be a "security boundary" (its trivially defeat-able[1])= . > Instead its designed to be a fairly straightforward detector of 'anomalou= s' > behavior. It works by intercepting file-operations and comparing them > against a whitelist. > > You can't tell people do stop doing unexpected things if you don't know > their software is doing unexpected things. > Right, I suppose a sandboxing mechanism is the best way to detect those changes. Is it necessary for it to be implemented with something like ptrace or ld tricks? Like above, I ask because other mechanisms are more comprehensive. The mechanism used to implement containers, in particular, is extremely interesting because it does (more or less) exactly what is wanted. Look for the CLONE_NEW* options in `man 2 clone`. It is possible containers are the best interface to this syscall, but I am not sure how to evaluate them in the context they would be used. Respectfully, R0b0t1