<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.12.3">
</HEAD>
<BODY>
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.<BR>
Only when the documentation (of course my own interpretation of it) fails do I read "C" (badly) and get on to this reflector.<BR>
Others here have much more focused history with them...<BR>
<BR>
On Sun, 2007-04-08 at 11:57 +0200, Miroslav Skoric (YT7MPB) wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">(Skip) K8RRA wrote:</FONT>
<FONT COLOR="#000000">> If you have configured all file access for users in /public and below</FONT>
<FONT COLOR="#000000">> then directories above /public are not accessible and jnos replies</FONT>
<FONT COLOR="#000000">> "permission denied".</FONT>
<FONT COLOR="#000000">> But the sysop has access to all files on the host - even outside jnos</FONT>
<FONT COLOR="#000000">> root directory.</FONT>
<FONT COLOR="#000000">Ok, let's see it once again. During the testing stage there are only two </FONT>
<FONT COLOR="#000000">users of my JNOS. One is me, as the sysop (callsign YT7MPB-9) and the </FONT>
<FONT COLOR="#000000">other is FBB for forwarding purposes (callsign YT7MPB).</FONT>
</PRE>
</BLOCKQUOTE>
This raises a flag with me - without a conclusion.<BR>
What I think I know is that there is an interplay between call & call-ssid that is not good.<BR>
In my history I configured 4 portable packet work stations as call-ssid where ssid was 1,2,3,4.<BR>
Not everything worked - as though there was some compromise in the identity of the station.<BR>
The bad news for this conversation is that I did not stay with the example until completion.<BR>
SO - either I blew the configuration / or the configuration would never work.<BR>
I expect to return to it within the next few months.<BR>
<BR>
In any case - you might choose two non-ssid calls for this?
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> I added those </FONT>
<FONT COLOR="#000000">two entries into 'ftpusers' file, both having a <password> value in </FONT>
<FONT COLOR="#000000">there. Sysop's callsign has access to '/jnos' folder and bbs's callsign </FONT>
<FONT COLOR="#000000">has access to '/public' folder (btw, I am not sure if the bbs should go </FONT>
<FONT COLOR="#000000">to '/jnos/public' or just '/public' - any suggestion?).</FONT>
</PRE>
</BLOCKQUOTE>
You have a root directory issue here.<BR>
With jnos installed in /jnos directory and started without redirection the <dir> spec of<BR>
1) "/public" points a root directory named "public"<BR>
2) "./public" points to a child directory of /jnos named "public"<BR>
3) "/jnos/public" points (ditto 2)<BR>
The path in ftpusers file is absolute when started by "/" and relative when started "./".<BR>
I find the ftpuser file documentation terse but accurate.<BR>
<BR>
The directory structure is your option for your circumstances.<BR>
And the rule of "highest directory access" is enforced for bbs users.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> By default, new </FONT>
<FONT COLOR="#000000">users were declared as "univperm" with no password ('*') and access to </FONT>
<FONT COLOR="#000000">'/jnos/public'.</FONT>
</PRE>
</BLOCKQUOTE>
There is more to this as well...<BR>
The permissions list for univperm may be much more restrictive than for a unique call user.<BR>
Again - your choice as sysop.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000"> I also noticed that some specific users, who may asked </FONT>
<FONT COLOR="#000000">for password, may also have their entries here, with declared password </FONT>
<FONT COLOR="#000000">of not '*'.</FONT>
<FONT COLOR="#000000">So far - so good. The question is the following: How to prevent anybody </FONT>
<FONT COLOR="#000000">on the air to play with callsigns and to misuses either sysop's or </FONT>
<FONT COLOR="#000000">forwarding bbs's callsign (which we, btw, have experienced here long ago)?</FONT>
</PRE>
</BLOCKQUOTE>
The security features of jnos are not very advanced by today's standards for operating systems.<BR>
It is arguable that jnos is adequate for it's environment.<BR>
Your question suggests you lean toward wanting more?<BR>
<BR>
I suggest your answer rests with human nature at this moment.<BR>
If the person on the other radio is a maniacal cracker your hope for security is lost.<BR>
You might identify him by reading the log - but safety will become a game --> your move - his move.<BR>
If the person on the radio gains the access that satisfies him - you are in good shape.<BR>
Even with univperm as long as his intents are honorable.<BR>
<BR>
Door locks only keep out honest people.<BR>
This brings you back to the honey pot - if there is nothing of value behind the door there will (probably) be no break-in.<BR>
<BR>
There is some conflict here in USA over encryption, the most basic of locks.<BR>
I hear opinions that even password encryption is not acceptable to the FCC.<BR>
So - just reading the trace under these circumstances allows anyone to use any call ID.<BR>
<BR>
Your question is worthy - I'm not certain it has a good (secure) answer.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Besides that, in order to try something similar to what was implemented </FONT>
<FONT COLOR="#000000">within FBB world (C_FILTER, PROTUS etc), I activated MD5 authentication </FONT>
<FONT COLOR="#000000">in JNOS, added two new entries in 'rc' file and noticed that MD5 </FONT>
<FONT COLOR="#000000">challenge appears only in JNOS local console connection ('bbs' command) </FONT>
<FONT COLOR="#000000">and during a telnet connection. Where it doesn't work yet is in AXIP </FONT>
<FONT COLOR="#000000">channel (it even doesn't ask the forwarding bbs for its credentials) and </FONT>
<FONT COLOR="#000000">I suppose the same will go over the AX25 radio channel.</FONT>
</PRE>
</BLOCKQUOTE>
It *might* be worth re-testing with unique callsigns and IP numbers on the two stations.<BR>
That test would take the ssid factor out of the configuration.<BR>
<BR>
I *believe* I am correct to interpret MD5 as a TCP/IP feature, and FBB mail forwarding an AX.25 feature.<BR>
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.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Any opinion?</FONT>
</PRE>
</BLOCKQUOTE>
Opinion? - yes<BR>
Helpful ? - I hope<BR>
Complete ? - nope
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Regards,</FONT>
<FONT COLOR="#000000">Misko YT7MPB</FONT>
<FONT COLOR="#000000">PS: When experimenting with FBB-to-FBB connections, we even had </FONT>
<FONT COLOR="#000000">encrypted password sent on the air. I don't insist on that - just wonder </FONT>
<FONT COLOR="#000000">if it works in JNOS world.</FONT>
</PRE>
</BLOCKQUOTE>
This may be a self-indulgent suggestion, but try text searches for FBB, forward, MD5, encrypt, (etc), at <A HREF="http://k8rra.no-ip.org/jnosd">http://k8rra.no-ip.org/jnosd</A> 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...
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">nos-bbs mailing list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:nos-bbs@lists.tapr.org">nos-bbs@lists.tapr.org</A></FONT>
<FONT COLOR="#000000"><A HREF="https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs">https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs</A></FONT>
</PRE>
</BLOCKQUOTE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
73<BR>
de [George (Skip) VerDuin] K8RRA k
</TD>
</TR>
</TABLE>
</BODY>
</HTML>