[Coco] Telnet to your CoCo.. and invite 6 of your friends

[Aaron Wolfe]

Ok.  I suspected there were plenty of other ways to circumvent the
user id checks.  Changing the F$SUser call would be superficial and I
think you're right that its a red herring given the many other
potential means of exploit.

The security in 6809 OS-9 is fine for most uses, and an internet
facing service can be written with the limitations of the security
model in mind.  I'm not going to change the system call, since I can
see that it would at best provide a false sense of additional
security, and more importantly, Boisy says its a bad idea :)

-Aaron



On Tue, Dec 1, 2009 at 9:12 PM, Boisy G. Pitre <boisy at tee-boy.com> wrote:
> Bob/Aaron,
>
> I checked the assembly for F$SUser and here it is:
>
> FSUser   ldx   <D.Proc      get current process dsc ptr
>         ldd   R$Y,u        get requested user number
>         std   P$User,x     save new user # in process descriptor
>         clrb               no error
>         rts                and return
>
> I checked the OS-9/68K version of F_SUser and here's what the docs say:
>
> - Users with group ID zero may change their IDs to anything.
> - A primary module owned by a group zero user may change its ID to anything.
> - Any primary module may change its user ID to match the module’s owner.
> All other attempts to change the user ID number return an EOS_PERMIT error.
>
> There is no concept of a group number in OS-9/6809; nor do OS-9/6809 modules store the user id/group id in the module header, so none of the above apply.
>
> I think the idea of making the F$SUser call available only to processes owned by the super user is a red herring. There are plenty of ways to wreak havoc under OS-9/6809 as a non-super user, and since all memory is writable, changing one byte in the kernel can bypass the check for super user completely.  Frankly, I wouldn't worry about changing F$SUser.
> --
> Boisy G. Pitre
> http://www.tee-boy.com/
>
> On Dec 1, 2009, at 5:21 PM, Bob Devries wrote:
>
>> Should the new F$SUser call return an illegal service request error if an attempt is made by a user other than user 0?
>>
>> I'm separated from my docs by some 1200 kilometers at this time, so I can't look that up, at least not easily.
>>
>> Regards, Bob Devries
>>
>> --
>> Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
>>
>> Edsger W.Dijkstra, 18 June 1975
>>
>> ----- Original Message ----- From: "Aaron Wolfe" <aawolfe at gmail.com>
>> To: "CoCoList for Color Computer Enthusiasts" <coco at maltedmedia.com>
>> Sent: Wednesday, December 02, 2009 10:06 AM
>> Subject: Re: [Coco] Telnet to your CoCo.. and invite 6 of your friends
>>
>>
>> I'd be happy to try writing a replacement F$SUser that fails if the
>> current userid > 0.  It's probably just a couple bytes of changes.
>>
>> Would this break things?  I'm guessing the most compatible behavior
>> would be not to return any errors, since the original always succeeds.
>>
>> -Aaron
>>
>>
>> On Tue, Dec 1, 2009 at 5:55 PM, Willard Goosey <goosey at virgo.sdc.org> wrote:
>>> On Tue, Dec 01, 2009 at 03:36:50PM -0600, Boisy G. Pitre wrote:
>>>
>>>> That's exactly what would happen... when the kernel scans for krnpX
>>>> modules, it will call the os9 F$SSvc system call to install the
>>>> system calls in that module; if any of those system calls reuse an
>>>> existing system call number, then their address will overrwrite the
>>>> address stored in the system call jump table in RAM.
>>>
>>> Well, that's the definitive answer from the definitive master. :-)
>>>
>>> That's really cool that a mechanism like that was already in place and
>>> running at a time when most operating systems, even for mainframes and
>>> minis, had completely statically linked kernels.
>>>
>>>> It's a great way to extend the operating system.
>>>
>>> Sounds really useful.
>>>
>>> Willard
>>> --
>>> Willard Goosey goosey at sdc.org
>>> Socorro, New Mexico, USA
>>> I search my heart and find Cimmeria, land of Darkness and the Night.
>>> -- R.E. Howard
>>>
>>> --
>>> 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
>>
>> --
>> 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
>