From: Alexey Tourbin <alexey.tourbin@gmail.com> To: ALT Linux Team development discussions <devel@lists.altlinux.org> Subject: Re: [devel] [PATCH hasher-priv v1 0/3] Make a daemon from the hasher-priv Date: Sun, 29 Dec 2019 14:03:07 +0300 Message-ID: <CA+qzennmkOY-g2CULkaJ2+xs9wewNvRhGvkdGPL8YdVFwSRhMg@mail.gmail.com> (raw) In-Reply-To: <20191216093533.GA26143@altlinux.org> On Mon, Dec 16, 2019 at 12:35 PM Dmitry V. Levin <ldv@altlinux.org> 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 <legion@altlinux.ru> 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.
next prev parent reply other threads:[~2019-12-29 11:03 UTC|newest] Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-13 11:42 Alex Gladkov 2019-12-13 11:42 ` [devel] [PATCH hasher-priv v1 1/3] " Alex Gladkov 2020-09-17 13:10 ` Arseny Maslennikov 2020-10-01 19:43 ` Alexey Gladkov 2020-10-01 21:24 ` Arseny Maslennikov 2020-10-01 23:38 ` Alexey Gladkov 2020-09-17 13:10 ` [devel] [PATCH hasher-priv v1 1/3] *literacy* Arseny Maslennikov 2020-09-17 13:11 ` [devel] [PATCH hasher-priv v1 1/3] caller.c Arseny Maslennikov 2020-09-17 13:55 ` Arseny Maslennikov 2020-09-17 13:11 ` [devel] [PATCH hasher-priv v1 1/3] caller_server.c, caller_task.c Arseny Maslennikov 2020-10-01 19:47 ` Alexey Gladkov 2020-09-17 13:11 ` [devel] [PATCH hasher-priv v1 1/3] config.c Arseny Maslennikov 2020-09-18 10:42 ` Dmitry V. Levin 2020-09-17 13:12 ` [devel] [PATCH hasher-priv v1 1/3] hasher-privd.c Arseny Maslennikov 2020-09-17 13:12 ` [devel] [PATCH hasher-priv v1 1/3] logging.c Arseny Maslennikov 2020-09-17 13:12 ` [devel] [PATCH hasher-priv v1 1/3] Makefile Arseny Maslennikov 2020-09-17 15:09 ` Vladimir D. Seleznev 2020-09-18 10:48 ` Dmitry V. Levin 2020-09-18 10:54 ` Andrey Savchenko 2020-09-18 11:33 ` Dmitry V. Levin 2020-09-18 12:24 ` Arseny Maslennikov 2020-09-17 13:12 ` [devel] [PATCH hasher-priv v1 1/3] server.conf Arseny Maslennikov 2020-09-18 10:50 ` Dmitry V. Levin 2020-09-18 10:57 ` Arseny Maslennikov 2019-12-13 11:42 ` [devel] [PATCH hasher-priv v1 2/3] Add systemd and sysvinit service files Alex Gladkov 2020-06-17 22:31 ` Mikhail Novosyolov 2020-06-17 22:38 ` Mikhail Novosyolov 2020-06-17 22:50 ` Alexey Gladkov 2020-06-17 22:43 ` Alexey Gladkov 2020-06-17 22:53 ` Mikhail Novosyolov 2020-09-17 13:10 ` Arseny Maslennikov 2020-10-01 17:25 ` Alexey Gladkov 2020-10-01 17:50 ` Arseny Maslennikov 2019-12-13 11:42 ` [devel] [PATCH hasher-priv v1 3/3] Add cgroup support Alex Gladkov 2020-09-17 13:11 ` Arseny Maslennikov 2020-10-01 19:17 ` Alexey Gladkov 2020-10-01 20:23 ` Arseny Maslennikov 2020-10-02 0:42 ` Alexey Gladkov 2020-10-02 11:46 ` Arseny Maslennikov 2020-10-02 12:58 ` Alexey Gladkov 2019-12-15 8:50 ` [devel] [PATCH hasher-priv v1 0/3] Make a daemon from the hasher-priv Alexey Tourbin 2019-12-15 23:33 ` Andrey Savchenko 2019-12-16 9:35 ` Dmitry V. Levin 2019-12-29 11:03 ` Alexey Tourbin [this message] 2020-03-16 10:34 ` Alexey Gladkov 2020-06-17 22:01 ` Alexey Gladkov 2020-09-17 13:09 ` Arseny Maslennikov 2020-10-01 17:21 ` Alexey Gladkov 2020-10-01 17:44 ` Arseny Maslennikov 2020-10-01 20:01 ` Alexey Gladkov 2020-10-01 21:53 ` Arseny Maslennikov 2020-10-01 23:55 ` Alexey Gladkov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CA+qzennmkOY-g2CULkaJ2+xs9wewNvRhGvkdGPL8YdVFwSRhMg@mail.gmail.com \ --to=alexey.tourbin@gmail.com \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git