Groups | Search | Server Info | Login | Register

Groups > comp.mail.uucp > #149

Re: Modern Uses of UUCP & NNCP

Show all headers | View raw

On Monday, January 4, 2021 at 8:05:56 PM UTC-6, Grant Taylor wrote:

> 
> I would also hope that there is a way to cause NNCP (UUCP) to simply 
> drop anything that wasn't from an explicitly allowed host, independent 
> of how it got into the system. 

Yes, NNCP would fail to look up the node in its configuration, and therefore would drop it.  (I haven't explicitly tested this but this seems to be an explicit design goal)

> > ISTR uuxqt can generate an error report at this point. I would need to 
> > look into NNCP's behavior here; I believe it holds the packet in the 
> > incoming queue thinking that the failure may eventually get resolved. 
> > Probably not ideal in this situation.

> I presume that you're referring to NNCP on the receiving end system 
> where rmail was prohibited.

Correct.

> This brings to mind another short coming I've seen with UUCP. 
> Inter-user access on the same system. 
> 
> Does NNCP even extend the encryption to the user level on the system? 
> E.g. destination!user1 vs destination!user2. As in if files were sent 
> something like uuto /path/to/local-file destination!user3. 
> 
> The UUCP installations that I've been exposed to were largely if you can 
> access the UUCP spool, you could access just about anything in it. 
> Perhaps this was a misconfiguration on those systems.

The story is only marginally better with NNCP.  You can setuid/setgid some stuff as is often done with UUCP, or mess with sticky bits on spool directories and such.  Outbound packets will be safe from inspection, since they are encrypted using a different node's public key.  Inbound packets could be decoded by any user that can read the NNCP config file (though you could probably restrict that, resulting in some protection).  There is no default support for a multiuser setup, and I haven't messed with it either.

My own setup has been to run NNCP as the nncp user, and create sudo rules to allow passwordless sudo from my user account to the nncp-* commands as nncp.  That segments off my private files from any kind of NNCP bug for the most part.  I add myself to the nncp group so I can pull things out of the incoming directory.

Another approach would be to create a separate installation for each user.  This would also be possible in UUCP, but is simpler in NNCP.  For instance, I could have a master NNCP on my system, that all inboud and outbound traffic is routed via.  Then I would set up another NNCP installation as jgoerzen, with all the files in my own home directory.  Then they could talk to each other; for instance, the master would "call" the jgoerzen one like this:

"|sudo -H -u jgoerzen nncp-daemon -inetd"

and vica-versa for calls in the other direction.

This could be extended arbitrarily to any number of users.

With NNCP only needing a single config file, it is somewhat faster to set up than UUCP, but conceptually I don't think there is anything ruling this out from a UUCP perspective either.

> I feel like I should go back and re-read about ToR. 
> 
> I wonder if I'm incorrect about it too or of NNCP's behavior diverges at 
> this point.

Don't discount the possibility that I am incorrect also :-)

> > Node5 could sort of know that the packet arrived from node4, but 
> > there is no cryptographic guarantee of that (the ONLY signatures in 
> > this whole chain come from node1) so that information is basically 
> > discarded.

> So NNCP really is about the data at rest as opposed to the data in 
> flight. Thus the flight path really doesn't make any difference to NNCP. 

From a configuration and authorization perspective, yes.  Both data at rest and data in flight are secured.

But I think this is a key point and puts a finer point on what was a bit hand-wavy on my part in my initial post.  There is no username/password authentication in NNCP because there is no point; a node will prove who it is by its keypairs on the wire protocol (and by what it can decrypt on the offline formats) and the path a packet takes to its destination doesn't matter to the destination.
 
> A non-trivial portion of UUCP is about the flight path, accounts that 
> are used, and other associated metadata. In addition to the data at 
> rest (what queue does it go into).

Right.  NNCP does maintain an outbound queue in subdirectories per node (named after the node's public key).  But there is no way for the receiver to see what the via-path was for a packet to reach it; it is expected that for an answer to be returned, the via-path should be defined in the config file on the receiver.  Basically the routing is supposed to be transparent to the user, though it can be explicitly given at any time with a -via parameter.

> > This is different from the UUCP model, in which node5 only really 
> > knows about its neighbor node4 and may have no idea whatever about 
> > node1's existence. Permissions in UUCP are based on what the neighbor 
> > can do, not what the source can do, if I remember correctly.
> I largely agree. 
> 
> Though I think there is some security around what remote node(s) the 
> local node will forward from and / or to. I can't tell you at the 
> moment if that's the remote source node or the direct neighbor node.

Control over forwarding is a bit of a missing link in NNCP right now, and probably wouldn't hurt to have.  Though I can see why Sergey left it out, if he envisioned an NNCP network to be one of curated peers and the forwarded packets are opaque to the nodes anyway, and the path is irrelevant to permissions.

> > The other thing that follows from this is that if node3 were 
> > compromised, the worst it can do is fail to relay packets. It cannot 
> > modify packets (signature validation from node1 would fail), it 
> > cannot spoof node1 (lacking its private key), it can't inject fake 
> > packets claiming to have followed the node1!node2!node3 path (again, 
> > lacking node1's private key),

> Eh ... I suspect that an upstream node could perform a DoS and send 
> bogus packets that ultimately consume resources.

True.  A compromised node3 could send packets that claim to be from node3, as of course they would be, and could execute whatever attacks node3 would be granted permissions to do.  I didn't mean to imply that compromise of node3 would be a "meh, I don't care" event, but rather that it couldn't be used to spoof another node.  

> > it can't even see what the ultimate destination is (it just knows 
> > the next hop is node4 but since it doesn't have node4's private key, 
> > it doesn't even know if node4 is the ultimate hop or not).
> I wonder if it would be possible to perform some metadata (packet size) 
> analysis and speculate about anything. 

Possibly, and that's why there is a minsize configuration option and parameter: http://www.nncpgo.org/Commands.html#OptMinSize 

- John

Back to comp.mail.uucp | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Modern Uses of UUCP & NNCP John Goerzen <jgoerzen@complete.org> - 2021-01-03 17:06 -0800
  Re: Modern Uses of UUCP & NNCP Grant Taylor <gtaylor@tnetconsulting.net> - 2021-01-03 19:31 -0700
    Re: Modern Uses of UUCP & NNCP John Goerzen <jgoerzen@complete.org> - 2021-01-03 21:51 -0800
      Re: Modern Uses of UUCP & NNCP Grant Taylor <gtaylor@tnetconsulting.net> - 2021-01-04 12:43 -0700
        Re: Modern Uses of UUCP & NNCP John Goerzen <jgoerzen@complete.org> - 2021-01-04 15:00 -0800
          Re: Modern Uses of UUCP & NNCP Grant Taylor <gtaylor@tnetconsulting.net> - 2021-01-04 19:06 -0700
            Re: Modern Uses of UUCP & NNCP John Goerzen <jgoerzen@complete.org> - 2021-01-04 19:33 -0800
              Re: Modern Uses of UUCP & NNCP Grant Taylor <gtaylor@tnetconsulting.net> - 2021-01-04 21:36 -0700
                Re: Modern Uses of UUCP & NNCP John Goerzen <jgoerzen@complete.org> - 2021-01-04 20:48 -0800
                Re: Modern Uses of UUCP & NNCP Grant Taylor <gtaylor@tnetconsulting.net> - 2021-01-05 20:51 -0700
    Re: Modern Uses of UUCP & NNCP John Goerzen <jgoerzen@complete.org> - 2021-01-04 09:41 -0800
      Re: Modern Uses of UUCP & NNCP Grant Taylor <gtaylor@tnetconsulting.net> - 2021-01-04 13:00 -0700
        Re: Modern Uses of UUCP & NNCP John Goerzen <jgoerzen@complete.org> - 2021-01-04 14:55 -0800
          Re: Modern Uses of UUCP & NNCP Grant Taylor <gtaylor@tnetconsulting.net> - 2021-01-04 19:11 -0700
  Re: Modern Uses of UUCP & NNCP Andy Valencia <vandys@vsta.org> - 2021-01-04 07:55 -0800
    Re: fussp, was Modern Uses of UUCP & NNCP John Levine <johnl@taugh.com> - 2021-01-04 19:52 +0000
    Re: fussp, was Modern Uses of UUCP & NNCP Andy Valencia <vandys@vsta.org> - 2021-01-04 14:03 -0800
      Re: fussp, was Modern Uses of UUCP & NNCP John Levine <johnl@taugh.com> - 2021-01-04 22:53 +0000

csiph-web