[Coco] Telnet to your CoCo.. and invite 6 of your friends
Joel Ewy
jcewy at swbell.net
Sun Nov 29 09:35:11 EST 2009
Aaron Wolfe wrote:
> On Sun, Nov 29, 2009 at 12:14 AM, Tim Fadden <t.fadden at cox.net> wrote:
>
>> Non-technical explanation from experience. tsmon watches the serial line for
>> input. It then calls the login program which prompts for user-name and
>> password. The password file is is in /dd/sys It contains in this order:
>> loginname,password,userid,priority,cmds_dir,home_dir,program_to_run If the
>> permissions are set properly, this file can only be read by root (userid 0),
>>
>>
>> 1. User Name; tim
>> 2. Mypassword
>> 3. 3 (Non-root userid)
>> 4. 128 (any value between 1 and 255) how much cpu time he gets. 128 is
>> equal time with other processes.
>> 5. /dd/cmds ( or some other cmds dir for more security)
>> 6. /dd/usr/tim my home directory set such that only myself userid 3 and
>> root can access
>> 7. shell (This could just as well be some other program like a
>> bbs front end. or the sculptor database "menu" program.
>>
>> IF some thought and work is put into setting directory and file permissions
>> propperly os9 is more secure than any windows, very simalar to unix.
>>
>> In my case I use /t2 to connect to my system from its serial line. This is
>> set up with the commands in my startup file :
>>
>> smode /t2 bau=6
>> tsmon /t2&
>>
>> I then use the program "telnet BBs server" on a windows box that takes input
>> from the internet, and connects to the coco serial port. So that when I
>> telnet to the with telnet from any box on the net I get a connection to the
>> coco with:
>>
>> CoCo-OS9
>>
>> connecting...
>>
>> NitrOS-9/6809 Level 2 V3.2.8 on the Tandy Color Computer 3 2009/11/28
>> 21:56:25
>>
>>
>> User name?: tim
>> Password:
>>
>> Word of note here. the original os9 login program did not echo the password
>> input. the current nitros09 login does, which is a security fault and should
>> be corrected. I am not a programmer, any takers?
>>
>> after I put in my password in this case a shell is opened.
>>
>> Process #04 logged on 2009/11/28 21:58:12
>> Welcome!
>>
>>
>> Welcome
>> to
>>
>> NitrOS-9 Level 2
>>
>> for the
>>
>> Color Computer 3
>>
>>
>> Shell+ v2.2a 09/11/28 21:58:12
>>
>>
>> This login can be as restrictive, or as open as you want it to be. If the
>> person logging in can only run cmds and see files and dirs than you allow
>> them to, how would it be insecure?
>>
>
> If the user can write to the disk, they can create a file with a short
> sequence of bytes that when executed would allow them to become any
> other user. Not sure if it is possible to set up a system where a
> user could actually do anything without allowing them any write access
> to any disk. Maybe you could lock their executable directory down
> somehow, and prevent writes there.
>
When I get the SWTPC running OS-9, I'm considering putting some text
adventures on it and letting people telnet in to play them. If you boot
from a write-protected floppy and limit the writable storage, the amount
of real damage anyone could do would be limited. If things get too
messed up, erase the writable storage and reboot.
JCE
>
>> Or, write your own bbs front end and start it!
>>
>>
>>
>> Permissions of cmds in the cmds dir can be set such that only specific cmds
>> can be run by only user root, directories can be set such that only the dir
>> owner can access the dirs and files owned by that specific user ID.
>>
>> I use this regularly to connect to my coco from work.
>>
>> Tim Fadden
>>
>>
>>
>>
>>
>> Wayne Campbell wrote:
>>
>>> I am probably too ignorant to even touch on this topic, but it seems to me
>>> it's a matter of permissions. Just like with Unix, OS-9 allows you to set
>>> access permissions based on the attributes of the file/folder/program. In
>>> order for a user to use a program, they have to have permission to access
>>> the directory, and the file and/or program to use it.
>>>
>>> With this in mind, one can establish a userlevel that makes it possible to
>>> prevent users with lower access levels from using or accessing things
>>> requiring higher access levels. Is this not the case with OS-9?
>>>
>>> I seem to recall something about userlevel using tsmon. Again, I'm not
>>> that educated in this field, so please forgive any implication of
>>> understanding on my part.
>>>
>>> Wayne
>>>
>>>
>>>
>>>
>>> ________________________________
>>> From: Willard Goosey <goosey at virgo.sdc.org>
>>> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>>> Sent: Sat, November 28, 2009 8:31:05 PM
>>> Subject: Re: [Coco] Telnet to your CoCo.. and invite 6 of your friends
>>>
>>> On Sat, Nov 28, 2009 at 05:53:53PM -0500, Aaron Wolfe wrote:
>>>
>>>
>>>> "Security" in OS-9 seems to be mostly based on the honor system.
>>>>
>>>>
>>> Unfortunately. I'd always been under the impression that while the
>>> security wasn't complete, what was there worked properly. This doesn't
>>> seem to be the case.
>>>
>>>
>>>
>>>> The real limitation is that the Coco cannot protect
>>>> memory as far as I can tell.
>>>>
>>>>
>>>>
>>> Correct. It's a hardware limitation of the MMU, not the operating
>>> system's fault.
>>>
>>>
>>>
>>>> I mostly guess people would use this feature to run a multiline BBS,
>>>> which *should* have it's own security,
>>>>
>>> Yeah, I never did the BBS thing, so I don't really understand it.
>>> Without shell access, what's the point? ;-) See, my first experience
>>> with multi-user machines was UNIX.
>>>
>>>
>>>
>>>> It would also be trivial to add a simple password check before
>>>> allowing a connection to a port, if that would be useful.
>>>>
>>>>
>>> I believe there are replacement login programs with a real(-ish ;)
>>> password program with them on RTSI.
>>>
>>> Willard
>>>
>>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
More information about the Coco
mailing list