Re: Re: Has anyone received one of these?
  By: Bradley D. Thornton to Todd Yatzook on Thu Sep 05 2019 01:18 pm

 > -=> On 09-08-19 22:02, Bradley D. Thornton wrote to Tony Langdon <=-


 >  BDT> So for now I've got port 23 open for telnet and port 22 open (running 
Mystic's SSHD). I'm glad that I didn't have to install and run another
 >  BDT> OpenSSHD and figure out how to pass that through or if it could be 
done. Like I inferred, although perhaps not clearly enough, I already have
 >  BDT> SSHD listening on another, non-standard port for regular user
 >  BDT> access to the host, i.e., there are two SSH daemons listening now, 
Mystic on 22 and OpenSSH on another :)

 > Yep I run 3 SSH daemons here:

 > OpenSSH on port 22 all IPs
 > Mystic on port 222 on selected IPs
 > Synchronet on port 222 on a different set of selected IPs.

 > :)


Hm... If I want to also run a Syncrhonet instance I could just bind it to a 
different IP, but Is it possible to share the filebase between the two 
internally? I suppose I could do it with a symlink. I had thought about doing 
it on another machine and then just making it available via an NFS mount on the 
private network. I'll need to ponder that later.

Thanks for bringing that up!

 >  BDT> I start mis as root. Actually, since that part of testing is over now, 
I start it as the non-priv'd user who owns the dir with a sudo - one of
 >  BDT> the use cases where I believe in using sudo ;) For that, I don't add 
the user to the sudo group, because any breakouts could afford a script
 >  BDT> kiddie to wreak havoc with impunity, so the user running "mis" (Not
 >  BDT> mystic)
 >  BDT> is only allowed to run mis.

 > Using sudo is still "running as root".

Well.... Okay ;) Yes it is, but I'll address that below.

 >  BDT> I try to avoid letting non-privileged users run daemon's on privileged 
lower ports, but with some software, do sometimes. This isn't one of
 >  BDT> those
 >  BDT> times ;)

 > Umm, why?  Back in the old days, there were lots of users (as in actual 
people with individual UNIX accounts) and only one sysadmin.  In that
 > environment, it makes sense not to allow non root users to bind privileged 
ports - you wouldn't want a user taking over the SMTP port, for example.
 > Today it's more common to have Linux boxes with only one actual (human) user 
- the sysadmin, and any "users" are simply accounts to isolate processes
 > from one another.  Allowing these users to run a specific application that 
can bind privileged ports means they don't have to start the application as
 > root, with a (very) small increased potential for a root compromise, if a 
flaw can be triggered before it drops privileges.


Actually, and I do understand what you're saying, but with respect to SMTP 
specifically, and I know  I gave an example of Bind as well, there are [once] 
common use cases for allowing a user to do that.

For example, I have users that manage their own email users for their domains 
as well as the DNS for those particular zones the users have. Bind picks up the 
zonefiles for that user's domains from their say, ~/dns/sld.tld.db file. The 
user is free to add and delete whatever records they need to, and up the serial 
for their zonefile, but they still need a way to HUP named, ergo, visudo:

joeuser        ALL=(ALL:ALL) NOPASSWD: /sbin/reload-dns.sh

where reload-dns.sh is chmod'd 644

#!/bin/sh
# reload-dns.sh
/etc/rc.d/rcnamed reload

Or some version of kill -HUP named, etc.

The same to hash the include of sendmail.cf in their ~ tree.

I know the thang nowadays is to sudo command for everything from the one person 
who is the admin on their own machine, but that's so freakin' redundant and 
unneccesary it just drives me nuts - even when I read it in Howtos. Yes, I get 
the idea, and this didn't come into common usage until Windows folks starting 
coming over the UNIX and Ubuntu really popularized it. In that Windows world, 
there isn't really an 'su -' per se', so what 'should' normally be a non-priv'd 
user is dropped into the Local Administrator or Domain Administrator group to 
administer machines on the network and have SSO convenience - that's just never 
been the way it was done in UNIX - su to root, and get back out after you do 
root stuff.

Effectively, 'sudo command' is the same, but all that typing just drives me 
nuts. I know when I want to do root stuff and I know when to ^d back out. I 
understand why it's been popularized in recent years not to do it that way 
but.... an explitive came to mind so my rant should stop there lol.

The first thing I had to get my head around when I started in the MCSE program 
when it was first launched was coming to terms with being a regular user and a 
god user at the same time - that's just freakin' wrong. Microsoft has never had 
an su equivalent, with the semi exception of being able to choose running 
certain things as Administrator - like powershell, etc. There I go again. 
Apologies.

Back to the security of it, if someone were to break out into the system, by 
allowing the user only a single root command, and effectively only commit a 
DOS, in this case.

In the rare cases where I would allow a non-priv'd user to start a job that 
could bind to a lower port, I would first make sure that user has no shell, 
maybe /bin/false or whatever, in /etc/passwd, so for them to start that service 
they would (root would, actually):

su jouser -s $SHELL -lc "
/path/to/command
/some/other/command
/bind/daemon/to_port:123
"

And this would be required:

#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
#AmbientCapabilities=CAP_NET_BIND_SERVICE

 >  BDT> Now, that begs another question. If someone breaks out of Mystic... 
that's always a concern, so what SSH implementation does Mystic use? I ask
 >  BDT> because I want to know how confident I should be that port 22 
(Mystic's SSHD) is as secure as OpenSSH is on the host.

 > I'm not sure tbh.


Here's what I got from a quick port scan. Not much info, which is good 
actually.

PORT    STATE  SERVICE    VERSION
22/tcp  open   ssh        APC AOS cryptlib sshd (protocol 2.0)
23/tcp  open   telnet
| fingerprint-strings:
|   GenericLines:
|     [8;25;80t
|     [1;25r
|     [1;1H
|     [1;1H
|     [?1000h
|     Mystic BBS v1.12 A43 for Linux Node 1
|     Copyright (C) 1997-2019 By James Coyle
|     Detecting terminal emulation:
|     [6nASCII detected.
|     Ascii (No Color)
|     Ansi (Color)
|     Graphics Mode ->
|   NULL, tn3270:
|     [8;25;80t
|     [1;25r
|     [1;1H
|     [1;1H
|     [?1000h
|     Mystic BBS v1.12 A43 for Linux Node 1
|     Copyright (C) 1997-2019 By James Coyle
|_    Detecting terminal emulation:


Thanks for your feedback Tony!
--- SBBSecho 3.09-Linux