[nos-bbs] Questions related to JNOS 1.11f

(Skip) K8RRA k8rra at ameritech.net
Sun Apr 8 11:45:04 EDT 2007


Concept one Misko - I'm focused on documentation only - and there are
(millions?) of conditions remaining to test.  And my test bed is
most-recent jnos on top of most-recent Fedora Core.
Only when the documentation (of course my own interpretation of it)
fails do I read "C" (badly) and get on to this reflector.
Others here have much more focused history with them...

On Sun, 2007-04-08 at 11:57 +0200, Miroslav Skoric (YT7MPB) wrote:

> (Skip) K8RRA wrote:
> 
> > If you have configured all file access for users in /public and below
> > then directories above /public are not accessible and jnos replies
> > "permission denied".
> > But the sysop has access to all files on the host - even outside jnos
> > root directory.
> 
> Ok, let's see it once again. During the testing stage there are only two 
> users of my JNOS. One is me, as the sysop (callsign YT7MPB-9) and the 
> other is FBB for forwarding purposes (callsign YT7MPB).

This raises a flag with me - without a conclusion.
What I think I know is that there is an interplay between call &
call-ssid that is not good.
In my history I configured 4 portable packet work stations as call-ssid
where ssid was 1,2,3,4.
Not everything worked - as though there was some compromise in the
identity of the station.
The bad news for this conversation is that I did not stay with the
example until completion.
SO - either I blew the configuration / or the configuration would never
work.
I expect to return to it within the next few months.

In any case - you might choose two non-ssid calls for this?

>  I added those 
> two entries into 'ftpusers' file, both having a <password> value in 
> there. Sysop's callsign has access to '/jnos' folder and bbs's callsign 
> has access to '/public' folder (btw, I am not sure if the bbs should go 
> to '/jnos/public' or just '/public' - any suggestion?).

You have a root directory issue here.
With jnos installed in /jnos directory and started without redirection
the <dir> spec of
 1)  "/public" points a root directory named "public"
 2) "./public" points to a child directory of /jnos named "public"
 3) "/jnos/public" points (ditto 2)
The path in ftpusers file is absolute when started by "/" and relative
when started "./".
I find the ftpuser file documentation terse but accurate.

The directory structure is your option for your circumstances.
And the rule of "highest directory access" is enforced for bbs users.

>  By default, new 
> users were declared as "univperm" with no password ('*') and access to 
> '/jnos/public'.

There is more to this as well...
The permissions list for univperm may be much more restrictive than for
a unique call user.
Again - your choice as sysop.

>  I also noticed that some specific users, who may asked 
> for password, may also have their entries here, with declared password 
> of not '*'.
> 
> So far - so good. The question is the following: How to prevent anybody 
> on the air to play with callsigns and to misuses either sysop's or 
> forwarding bbs's callsign (which we, btw, have experienced here long ago)?

The security features of jnos are not very advanced by today's standards
for operating systems.
It is arguable that jnos is adequate for it's environment.
Your question suggests you lean toward wanting more?

I suggest your answer rests with human nature at this moment.
If the person on the other radio is a maniacal cracker your hope for
security is lost.
You might identify him by reading the log - but safety will become a
game --> your move - his move.
If the person on the radio gains the access that satisfies him - you are
in good shape.
Even with univperm as long as his intents are honorable.

Door locks only keep out honest people.
This brings you back to the honey pot - if there is nothing of value
behind the door there will (probably) be no break-in.

There is some conflict here in USA over encryption, the most basic of
locks.
I hear opinions that even password encryption is not acceptable to the
FCC.
So - just reading the trace under these circumstances allows anyone to
use any call ID.

Your question is worthy - I'm not certain it has a good (secure) answer.

> 
> Besides that, in order to try something similar to what was implemented 
> within FBB world (C_FILTER, PROTUS etc), I activated MD5 authentication 
> in JNOS, added two new entries in 'rc' file and noticed that MD5 
> challenge appears only in JNOS local console connection ('bbs' command) 
> and during a telnet connection. Where it doesn't work yet is in AXIP 
> channel (it even doesn't ask the forwarding bbs for its credentials) and 
> I suppose the same will go over the AX25 radio channel.

It *might* be worth re-testing with unique callsigns and IP numbers on
the two stations.
That test would take the ssid factor out of the configuration.

I *believe* I am correct to interpret MD5 as a TCP/IP feature, and FBB
mail forwarding an AX.25 feature.
As such - I'm not confident in success - but there is much in mail
forwarding i DON'T KNOW - especially between platforms with different
software installed.

> 
> Any opinion?

Opinion? - yes
Helpful ? - I hope
Complete ? - nope

> 
> Regards,
> 
> Misko YT7MPB
> 
> PS: When experimenting with FBB-to-FBB connections, we even had 
> encrypted password sent on the air. I don't insist on that - just wonder 
> if it works in JNOS world.

This may be a self-indulgent suggestion, but try text searches for FBB,
forward, MD5, encrypt, (etc), at http://k8rra.no-ip.org/jnosd and study
the jnos pages identified by the search.  The content of the site is
jnos documentation [detail in the bibliography], the search may be a
useful tool toward your answer.  On the other hand it could be a bust.
I do wish the development were further along...

> 
> 
> 
> 
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs


73
de [George (Skip) VerDuin] K8RRA k
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/nos-bbs_lists.tapr.org/attachments/20070408/f58c1fba/attachment.html>


More information about the nos-bbs mailing list