Originally Posted by Megol
It may surprise you but I have several years of education in the area at the university level. I have never seen a paper that uses your definitions (and I have read a lot), I have never had a lecturer being even close to your definition. Even from other student have I ever heard anything like that.
No operating system papers uses your definitions for either user or multi-user. Research in security systems including capability systems doesn't mix the idea of users and protection domains*. You are completely on your own.
(* or whatever term is used to describe a privileged component)
It doesn't surprise me, but, i'm not really trying to "define" these terms at all. I only want to point out that the "protection domains" that various Unix/Linux processes and daemons run under are treated exactly the same way as users by the system. They appear in /etc/passwd alongside my own login accounts (my passwd file actually has 52 entries in it, and only 3 of them are people; i actually just tried logging in as "nobody" in the terminal and it worked!). They are part of the same data structures and are processed by the same functions and APIs. In all honestly i couldn't care less if they are called "users" or "eggs" or "teapots", they are the same thing
inside the system.
The security idea you outlined above is essentially what modern Linux distributions do already, and they do it precisely by using the same mechanisms originally developed to support multiple users. The only important - or perhaps defining - thing about this mechanism is that it makes it possible to segregate one part of the system from another, whether that means segregating one user from another or one process from another, that's only a difference in the application of the technology.
If you had what you call a "single-user system" with "protection domains" for different processes, you could implement individual user accounts just with a set of simple scripts. Just give each script access to a separate directory and there they are. So you can cite as many academic papers as you like, the difference is... well... entirely academic. Although by all means do cite them, for our edification.
Originally Posted by Megol
You are right. Just got carried away. Sorry.
Yeah... me too... and i wasn't even drunk
IMHO it is impossible to patch Amiga OS to be either protected or secure. But it wouldn't be impossible to make an OS that is very similar but protected (though not secure) by making all memory readable but protecting writes using virtual memory.
i think it could be made *more* secure (security is always relative, even modern systems are vulnerable and we already cited side-channel attacks that cut straight through memory protection), it depends on what you want. I still think we could protect the OS from user applications by:
* having a file system with some concept of privilege level
* have a concept of privileged exec library calls
* sanitizing exec/dos library function inputs
* not giving out raw pointers to vital OS structures (perhaps give out pointers to disposable copies, and maintain a separate copy of the execbase structure for each running process)
There is also the possibility of running some sort of virtual machine, and then only running browsers &c inside that, even if you run native Amiga code outside of it as well.
Ok so if you were to try to compromise an Amiga system, in a controlled way (i.e. mess with files, hijack processes &c, not just crash the system), some questions to think about
1. if you could only use legitimate library calls or modify structures passed back as return values of same, how would you do it?
2. if you were not able to use those function calls (for instance if file permissions prevented you from doing what you wanted), how would you do it?
3. if you were not able to get the genuine addresses of the structures you wanted to modify from library calls (for instance, if you only got back a copy, which you could modify without having any effect), how would you do it?