Owner/Guest

A concept for OS design i pondered about.
Instead of making users ROOT/ADMIN and allowing remote users to become them.
I think there should be OWNER class,thats is anyone who physically controls the keyboard and mouse, and GUEST that is anyone who doesn't.
It would reduce security to simple manageable threats, like capability checks for guests and limiting said capabilities to such extent so "rooting" would be impossible.
Critique my concept, /prog/ (spamming autists not welcome)

install BSD/Gentoo

I think you didn't think this through. If a remote user has access to the system, then they can also impersonate the Owner class.

>>3
A remote user can send data, this doesn't mean he can replace the keyboard driver(which is NOT used for treating remote connections, only for real non-virtual physical data sent by keyboard cable(wireless is insecure)). A better question "what is a dumb Owner executes a trojan", the answer is the trojan has the capabilities of guest(the only thing that has Owner capability is Trusted System Binaries(signed of course) launched by Owner via keyboard cable, not scripted or automated), and guest processes can't earn capability of replacing system binaries or drivers or kernels.
The remote attacker would have to find a vulnerability in system daemon/service/server which has an open port(e.h. httpd/apache/etc) which would allow him to gain access(guest of course, but using the capabilities of daemon/service/server which can be severely limited).
Captcha:rnedeple Terry

so something like WebMin wouldn't be possible ? And you couldn't launch child processes with admin rights ?
So launching apt-get from your shell wouldn't work ?

Dude.
I think you don't understand computer

>>5
No remote root shells. Child process with Owner rights are only possible with keyboard access.
 To instead of "sudo apt-get upgrade" you just type "apt-get upgrade" on the keyboard.
The Keyboard Owner is the system owner. Apt-Get is Trusted System Binary and your Shell is too..so Keyboard->keyboard driver->Shell->Apt-get at each step the process was manually launched(except keyboard driver/shell, which is started by default). The process is as follows.
1.System starts Keyboard Driver(from kernel/bootloader/etc) and launches the default shell(must be a trusted system binary).
2.You don't login or prove anything. You type on a non-wireless keyboard the command to launch apt-get with parameters. Apt-get get verified as Trusted System Binary(you can manually sign your binaries of course if you need it), the Shell is a Trusted System Binary and the command was launched from a physical Keyboard. Now Apt-get launches with owner rights, but it cannot launch child processes with Owner right unless you explicitly confirm it(using a physical keyboard,e.g. Launch Subprocess X with owner rights[Yes/No]),Subprocess X is Trusted System Binary. Non-system binaries or scripts(non-signed) can't get owner rights no matter what, until you explicitly sign them.

>>7
So essentially you've reinvented physical system consoles?

>>8
>So essentially you've invented keyboards
>Keyboards make computers secure
>its secure because its hardware, OS DOESN'T MATTER
>Excuse me, i'm going to compile some keyboards

>>9
You ever get your hands on a router with a console port?
Plug your laptop into that port and telnet to it (or use whatever console program they give you).
You'll be given root access without having to log on.
Just disable root access from all other places and you've got what's described.

Hypervisors are the right idea. Every user gets their own OS. Shared nothing, communication as if with other computers.

>>10
>Just disable root access from all other places
The system still has non-root to root transition by allowing root to lauch non-root software with root privileges. I.e. in my system running a trojan by Owner, will not result in infection(as trojan is unsigned,non-system binary which has guest class), but in your example trojan will gain the privileges of the user automatically and infect the system(since root makes all launched software root).
Another example: in exploit of guest class service/daemon/server (software which has capabilities restricted to much lower level than Owner, which cannot have Owner rights in any case) does not results in Owner-level access,because guest process(with the capability not set) cannot even start a new process and cannot control a higher-security process which spawned it, root shells are not possible(while in your  example an exploit could gain remote root by exploiting any service/daemon/server running, since there is no fundamental difference between admin at the keyboard and hacker from the net,either can have root).

install BSD/Gentoo

install BSD/Gentoo

top lel

top lel

top lel

top lel

>>14
>>15
>>16
>>17
>>18
Stop spamming, "kudasai"

>>19
Optimise your quotes ``please''

install BSD/Gentoo

install BSD/Gentoo

install BSD/Gentoo

install BSD/Gentoo

install BSD/Gentoo

http://www.thewebcomiclist.com/o/8538