From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=NcJOprqCPrKCdMoiuA2eHV2OmwauQyNlYHaeL5WM6nI=; b=ss8aJZx73dMZk0HCxjTigUBEhcGtj9jY5rQVq0XL7TcK6lR2hcs6L2KfZJbx+Ku+/0 DVSohnhmnOqyQY1Jywf8a6KqUAJVvFEN3maqxnHLObnR+1EWAbKVnB8Rm8mpfkAaL53p kZ8ShgaQo8kWEurFYVYIYrxz3hjGUewIKd+Yakop/pqjRTMBsWuk6sm7bFcwGYvEcRlO +lc8/QkLPz3bMLjfGSTECzS2AfF926MitxiqBpeN8dP1TGd7v+BBh3RVrJ82JdZLD7zE jPbqwVKpWyBvaYS1eVN85YN9wbQFTrkr5d7YvztrWBIVrGcpm8rXblghdRQKGhX4xYut 53ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=NcJOprqCPrKCdMoiuA2eHV2OmwauQyNlYHaeL5WM6nI=; b=oR+Tq23rTu/C1O+RRbvQ0hUzzv8YoiHBBIkviPL9bel3fNsoJaetlzZW2CxX9DXEeA kXk6sEb5eIPu61jvBogttI8RhjHg7XjdIRX6sRJnzkbXrEqM6l0ndZrbVlvVGjwJ5Wrj mqaIkLuvsr25GWHpoOExzqGWAV1ysV0/YMfm5d/gBkzVICnpZb4lz4Mkk2E3tTz3iw7w /GvCSTchtImjeTxRcydKwnxpXP4AYs7TKz1xB94cdnsU3J4Cdp4plVn7K/sDqfIf5lYo ek+v73ZEV0eCFbO+Lp2ZKX1bJ2skPm1/mmcemZsreQhH48eAxlvYPZibFUqhyQZ18bFm wP2A== X-Gm-Message-State: APjAAAXTaRDiF1CJ7Sh0PvlJ/KRVdgdcVt60GcAh4l4wglOXbesGmt5R I2VTY301iRxzLvqo3ZavLTl1zWafpTkUsFtTfwnH0bo4 X-Google-Smtp-Source: APXvYqz4LxH5ybVb3xEqN/cldyQ/HIMhdx3OXgRBAv2q8DT40ZDwtOu86vFTr23C+zddqhNyPGHcYYsTcjylGW8/LHc= X-Received: by 2002:a02:2404:: with SMTP id f4mr47718486jaa.50.1577617398306; Sun, 29 Dec 2019 03:03:18 -0800 (PST) MIME-Version: 1.0 References: <20191216093533.GA26143@altlinux.org> In-Reply-To: <20191216093533.GA26143@altlinux.org> From: Alexey Tourbin Date: Sun, 29 Dec 2019 14:03:07 +0300 Message-ID: To: ALT Linux Team development discussions Content-Type: text/plain; charset="UTF-8" Subject: Re: [devel] [PATCH hasher-priv v1 0/3] Make a daemon from the hasher-priv X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2019 11:03:22 -0000 Archived-At: List-Archive: List-Post: On Mon, Dec 16, 2019 at 12:35 PM Dmitry V. Levin wrote: > On Sun, Dec 15, 2019 at 11:50:13AM +0300, Alexey Tourbin wrote: > > On Fri, Dec 13, 2019 at 2:42 PM Alex Gladkov wrote: > > > The hasher-priv is a SUID utility. This is not good. Separation of the > > > server and client parts will allow us to remove SUID flag. > > > > Removing the SUID flag shouldn't be an end in itself. You're still > > running a process with root privileges which serves user requests. > > It's the same, except that instead of the SUID flag, the process just > > starts as root. So you are not improving privilege separation or > > something, you are only limiting the ability of the user to tamper > > with the SUID binary. And tampering with the binary should be > > pointless anyway (unless glibc is faulty and permits arbitrary code > > injection, etc.). > > While turning a suid root executable into a daemon doesn't automagically > make everything more secure, it's an important move in the right direction. Not necessarily. Conversion into a daemon takes more code, which can have its own faults. Instead of relying on the set-uid mechanism, you're very likely to up end up with a more complex DIY construction. > Firstly, the attack surface of a suid root executable is larger than > of the equivalent root daemon on the other side of a unix domain socket, > so this change narrows the attack surface. You are casting doubt on the venerable set-uid mechanism. What if it's faulty? What if the user can tamper with the binary and somehow inject arbitrary code? Well, you can do nothing about it, and moreover it's not your problem. (Likewise, if the kernel is faulty and permits privilege escalation, you can do nothing about it, and the only way round is to fix the kernel.) Your basic mechanisms must be secure, and it's doable. The "attack surface" is just a highbrow way of saying that the dynamic loader should be insensitive to LD_PRELOAD. :) > Secondly, this change opens the way for more elaborate privilege separation. > > Thirdly, it makes hasher available for PR_SET_NO_NEW_PRIVS'ed > processes (e.g. self-seccomp'ed) that cannot make use of suid executables. These might be valid arguments. Still, I find it hard to believe it's really about security. hasher-priv is minimalistic, and its use is limited to those few machines that need it, some of them booted over the network. There is no good reason to believe that we might face any security risks.