>>> [...] it seems to me that a machine that to which you have console
>>> access that also has ddb is not much more secure than a dos
>>> machine...
>
>Probably true.  Even if securelevel can't be patched directly, there
>are lots of other interesting things you can do, like patching the
>p_cred->cr_uid field for your shell, or diking out certain suser()
>calls in the kernel text segment.

can't be patched directly?!  it can...or are you referring to the
silly "patch" i made?  as for patching the p_cred->cr_uid field, it
would take me more than a few minutes to manually walk over to that
particular field i think...

>> But what i was saying was that if you have physical access to a
>> machine (which is different from mere console access), you can do as
>> you please with it.  At the very worst, plug a floppy in and boot
>> from there (DOS, and then use a sector editor...)
>
>Heh.  _Real_ machines have PROM passwords so that you-the-sysadmin can
>prevent booting from alternative media by people ignorant of the
>password.  (Remember, not everything runs DOS, either - this _is_
>current-users, not port-i386.)  (Though as you say, given physical
>access and the time and knowledge to use it to good advantage, you can
>work around such things.  "One more hurdle"....)

<rant>

*real* machines have encrypted filesystems so that even if you walk
over to the machine and just pull the disks off (you don't need to
reboot it or muck with the securelevel for that) with the intention of
just hooking them up to something at home, you *still* can't get at
the data.  but where to store the keys...

</rant>

-- 
|-----< "CODE WARRIOR" >-----|
andrew@echonyc.com (TheMan)        * "ah!  i see you have the internet
codewarrior@daemon.org                               that goes *ping*!"
warfare@graffiti.com      * "information is power -- share the wealth."