public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
From: John Goerzen <jgoerzen@complete•org>
To: Sergey Matveev <stargrave@stargrave•org>
Cc: nncp-devel@lists.cypherpunks.ru
Subject: Re: nncp-sudo
Date: Fri, 20 Aug 2021 07:30:12 -0500 [thread overview]
Message-ID: <87v940e1t7.fsf@complete.org> (raw)
In-Reply-To: <YR+N2CZcndUkCJN1@stargrave.org>
On Fri, Aug 20 2021, Sergey Matveev wrote:
> Greetings!
>
> *** John Goerzen [2021-08-19 22:42]:
>>I also have a more detailed exploration of how sudo and NNCP can
>>work
>>together, both for exchanging data between two different NNCP
>>installations
>>on a local machine, and for cases where NNCP runs as a different
>>user than
>>your regular user.
>>https://github.com/jgoerzen/nncp-tools/blob/main/docs/nncp-sudo.org
>
> And yet again, possibly stupid question out of curiosity: isn't
> the
> ordinary Unix permissions are not enough? I assume that there is
> some
Hi Sergey!
I have a couple of scenarios in mind:
1) Where one main config file isn't desirable. For instance,
individual users want to define their own exec commands, areas,
etc.
2) Where users don't fully trust each other (this can also play
into #1)
3) Desire to run NNCP commands with privilege separation
I did indeed see your shared spool directory. I actually have
been working to make NNCP work on SDF which has thousands (tens of
thousands?) of users. I don't have root there, so I couldn't
create an NNCP group, and so would have been unable to run it more
securely than basically a wide-open /tmp. (Since I don't have
root there, I also can't implement the sudo option)
So, thinking a bit about #1. Shared-spool might be undesirable
because:
- sudo rules would need to be defined for each exec target that
needs to run as a particular user
- Unless each user also had write access to the configuration,
they'd have to request all changes from someone else
Basically, the sudo setup lets the administrator delegate control
over what a user does with NNCP to the user.
Other drawbacks of the shared spool?
- More security risks (think of, for instance, a world-readable
set of files in /var/mail). Users have access to the secret
keys and could read each other's incoming packets at the very
least. Or delete them, etc.
- Would certainly let all users see metadata about each other -
where they're sending packets and what size.
One reason I am running it as a separate user is because I think
that's the appropriate way to go, even though I'm the only user on
my box. I wouldn't run postfix, exim, apache, tor, etc. as
jgoerzen, because the more things run as my user, the greater the
consequences of a security hole exploitation. By running NNCP as
a separate user, and having restrictive permissions on my home
directory, I have the same kind of isolation that I get with these
other daemons. (Yes, I know about things like namespaces and
capabilities on Linux, but they are Linux-specific and rather
complicated.) Then I can use pinpoint sudo rules for any exec
targets I want to run as jgoerzen. (This isn't directly about
using sudo to talk between call/daemon but just a general reason
that I don't want to run NNCP commands as jgoerzen.) On these
particular situations, I have an additional layer of gpg signature
verification protecting against any sort of data injection at the
NNCP level.
I'm not saying NNCP is bad - far from it! But basically I want as
much isolation from every component on my system as possible, and
to treat everything as untrusted as much as I can, even if I think
it's pretty good.
On Unix systems, with certain exceptions (email interface mainly)
I generally don't run any commands associated with daemons as my
local user.
(/usr/sbin/sendmail is an odd one; setuid root with exim4 and so
forth. I'm not fond of this model at all. Maybe it's better with
Postfix.)
- John
next prev parent reply other threads:[~2021-08-20 12:31 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-20 3:42 ANN: Tunnelling NNCP over (ssh, sudo, tor, S3, Nextcloud, syncthing, uucp) John Goerzen
2021-08-20 10:52 ` Sergey Matveev
2021-08-20 12:36 ` John Goerzen
2021-08-21 18:30 ` Sergey Matveev
2021-08-24 2:31 ` John Goerzen
2021-08-24 8:35 ` Frank Doepper
2021-08-24 10:12 ` Sergey Matveev
2021-08-24 10:09 ` Sergey Matveev
2021-08-20 11:11 ` nncp-sudo Sergey Matveev
2021-08-20 12:30 ` John Goerzen [this message]
2021-08-21 19:02 ` nncp-sudo Sergey Matveev
2021-08-24 2:35 ` nncp-sudo John Goerzen
2021-08-25 19:24 ` nncp-sudo Jonathan Lane
2021-08-25 20:31 ` nncp-sudo John Goerzen