Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Owner/Guest

Name: Anonymous 2014-01-20 6:01

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)

Name: Anonymous 2014-01-20 10:41

>>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.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List