OSDev.org

There is one thing that has bothered me when it comes to Unix-like operating systems. I am not saying that this is Unix-specific per se but I use that as an example. The fact that you can access a hard-disk drive or a bunch of other devices so easily (e.g. read/write to "/dev/???") feels dubious. Abstractions, like files, are thrown away very easily if needed. There would be no problems if the root user was used only for some serious system management. It could be like "boot to recovery mode" or something like that but not just logging in as a root user. Currently the root user plays significant role in normal things. You need it to do things like installing applications etc. In short: too powerful root privileges are not very far away but just around the corner. I think this is not good.

Current operating systems are what they are and I am not trying to change them. I am just planning how I will design and implement my OS. I may be wrong (and change my opinions) but now it just feels that I do not like too low-level things be accessible in a way like this. Of course, the OS is not Unix-like but this topic is still valid no matter what the design is. This post is not very comprehensive and is simplified but I think this should be enough at this point and you surely get the idea. What are your opinions about this?

I'm not sure that this is so much a problem of OS design as the way that facilities are used. Most OSs provide the ability for a user to perform a single command only with root privileges. The problem arises when this command is not properly secured so that something like "sudo bash" is allowed. This is not just a problem with Unix; I've seen the same thing with OS/400 which should be an extremely secure system.

I guess the trick is to write an OS that can't be misconfigured in this way. That's more a question of understanding human nature and imagining the ways that necessary facilities can be misused. For starters, how do you design an OS so that the user can't write the root user's password on a piece of paper?

iansjack wrote:How do you design an OS so that the user can't write the root user's password on a piece of paper?

Make an onscreen keyboard showing animals instead of lettered keys. If it doesn't even look like a keyboard/numpad layout you're guaranteed that password is not going to be used on other systems, and becomes a pain to write down.

iansjack wrote:Most OSs provide the ability for a user to perform a single command only with root privileges. The problem arises when this command is not properly secured so that something like "sudo bash" is allowed.

That does not help much. Being it "sudo bash" or "sudo malware", the privileges of that running application are usually far too powerful. Besides, that whole "sudo" thing ruins the idea of Unix-like systems.

Have you looked into capability-based security? It takes the power root has and splits it up into separate capabilities that can be passed around between protection domains (for example processes) at a finer granularity. Note that this is different (and more flexible) than Linux capabilities.

Rusky wrote:Have you looked into capability-based security?

Thank you for the concept. I just checked the wikipedia and it gave me a link to Principle of least privilege. The latter is a simple base of any secure system. Security is not the only important thing but usually a secure system is also a good system.

the thing is you can't really remove the possibility to do some sysadmin or low level task, even things that are potentially harmful , unless you have an extremely polished low level layer who never need any kind of admin at all, like maybe something close to game console, or android system, where all operation can be done with an user interface with well defined and secure functions

maybe a possibility would be to totally separate admin user interface from regular user interface, a bit like they do with web software as the back end is almost a completely different piece of software than the front end, and having a specific "admin" "expert" mode to do sys admin things, and having an user interface that is more like what you can find on cell phones or game console, and limiting by default anything the regular user can do at all to some well defined functions

maybe some system like SELinux can help to have permission that are not primarily based on user, and booting the os with some different SELinux configuration for regular user or admin user

but if it happen that the user interface is not very well polished , and that there is always need to switch to admin mode to do everyday things, the user interface might end up being totally useless, it's basically what happen with windows vista with their security paradigm, the totally secure user mode is almost unusable for everyday task, result even your granma use vista in admin mode, because it become simpler even for everyday task

Antti wrote:now it just feels that I do not like too low-level things be accessible in a way like this

I think it's all about controllability. If you have to reboot a system to log in with administrator permissions it is very inconvenient. But there's some reasons for such reboot requirement. And the reasons are not under your control when you are logged in as an ordinary user. Then the solution can be just to resolve the uncontrollability problem. There should be some means of ensuring the system is safe and your actions as a permission owner are not break the safeness. For example - if you can monitor system activity in such a way that there is no chance for a malware to use your permissions unnoticed - then you need no all those reboots or relogins. This means the system should be simple (and it is hard to achieve) or have some monitoring tool which can show you every suspicious activity in a simple manner. Then you just need to invent such a monitor.

embryo wrote:If you have to reboot a system to log in with administrator permissions it is very inconvenient.

Rebooting should not be necessary unless something is wrong. It is like a recovery mode that is used in an emergency. Then there are no artificial limits of what can be done. It is like using the disk with external tool (e.g. attaching the disk to another computer and directly accessing data). At the recovery mode level I consider accessing raw disk sectors appropriate but, at the normal run level, things like these are abstracted i.e. not allowed directly, regardless of the user privileges.

We can take disk partitions as an example. Currently an application like "fdisk" running at root privileges can directly edit disk sectors. I think a "fdisk-like" application should only use an interface the kernel provides. The kernel makes sure changes that are made are meaningful and are not breaking the system.

I have not thought everything through yet. This is just a design idea.

But in your example users might also want to create partition or change them at some point as well.

it's the whole problem of this kind of things, for general look and feel and global design, not specially for security issue, there is a whole bunch of things apple ship alongside with their documentation, i don't remember what the name is, but it's like guideline for user interface, but it's general it's not only about GUI even if on mac most thing are controlled by GUI, but generally how to design functionalities that are coherent, and defining those functionalities that you want to expose under what condition, in the ideal, without a regular user has to switch to a true full power admin mode ever

Outside of Apple, there is not much other OS producer who really put that much care about this sort of things, on UNIX it's mostly done to be manipulated by sysadmin with resources sharing in mind, and access are largely user/file system based, on windows they define a lot of things via com, but it's not made specially for security purpose, i guess you would have this kind of security under windows if you program in C# or VB, but at least there are clearly defined interface to manipulate system resources

for this web industry can be interesting because it's software made to be run by just anyone, in sort that just anyone can run the program on just any server, so interfaces between the user and the program tend to be very well defined, and often access level on different kind of 'object' or content that can be pretty complex, with different level of admin/users, and not specially based on file access/file permissions, but on the different kind of resource that the system can manage, and what access can be given to them under what conditions

the major problem i think is while your system is still in development, you need some kind of way to be able to change anything in it easily, and so a system anyway need to have a mode at least for developers, to have all permission on everything, and then need in latter stage to expose some functionalities/resources via some kind of interface for user space program, and it's there you need to have a clear view of the functionalities that your system provide, and what an user will be exactly using your OS for, in sort to have a global view of what resources the system can manage, and what kind of action an user is supposed to be doing on them under what condition, knowing that as a developpers, you'll always need to go over any kind of layer of pre defined action that you can define for users

h0bby1 wrote:the major problem i think is while your system is still in development, you need some kind of way to be able to change anything in it easily

I do not think this is a major problem or a problem at all.

h0bby1 wrote:But in your example users might also want to create partition or change them at some point as well.

Typical case dictates partition editing to be reserved for install-time.

the major problem i think is while your system is still in development, you need some kind of way to be able to change anything in it easily

edit; make; bochs -q -f foo. (or edit; make run; for my particular Makefile because I want to do everything with a simple up-enter on the command)

and so a system anyway need to have a mode at least for developers, to have all permission on everything

I don't believe that Besides, shouldn't you always want as a system to cry havoc at the programmer if he wrote buggy code?

Antti wrote:I think a "fdisk-like" application should only use an interface the kernel provides. The kernel makes sure changes that are made are meaningful and are not breaking the system.

Yes. A wrapper around kernel functionality can ensure anything you want. Also it can act as a monitor and notify you if program actions are suspicious. All that is required is just to write wrappers logic.

I am thinking about things in a similar way for my OS.

I think you need to think about this issue as a collection of separate problems. Instead of just looking at security on the whole, look at security of what a user is allowed to do vs what a program my do.

Think about a general desktop OS like Windows or Linux. There really are 2 main concerns, user stupidity, and program maliciousness. I think these should be handled differently as they are 2 different things, and have 2 different solutions (well more than 2, but point is that there isn't a one-size-fits-all solution here)

Obviously that is a bit of a simplification, but the same logic can be applied to network security, or multiple users on a server, or even malicious users. You need to identify exactly what you are trying to stop/prevent with your security and handle each one separately.

- Monk

The only reason that giving users "too much power" is a problem is because most systems are based on the fundamentally flawed assumption that I am the author of all the programs that I am ever going to run on my computer system, and my programs are just an extension of myself, acting with my full authority in everything. This is obviously not true. The failure of system designers to distinguish between the intentions of the operator of a computer and the instructions in a random program downloaded from the Internet is the reason that people are afraid of running an untrusted program, and rightly so. It necessitates a bunch of convoluted security protocols at workplaces to avoid getting computers "contaminated" with malicious software, and everyone is so used to this that it seems perfectly reasonable and acceptable that it should be so. There is a man made metal contraption on another planet 400 million kilometers off into space, capable of searching for rocks and taking samples of them without a human operator. Are we really unable to invent technology that lets a person play FunnyCoolGame.exe that just arrived in his email inbox while still guaranteeing that all the classified military vehicle designs he was just working on a minute ago are still kept a well guarded secret?

Of course, as a computer owner, I take it for granted that I should be able to do anything I want with the data on my disks unless there is a good technical reason that I can't. If I need to inspect or change the contents of sectors directly, I shouldn't be hampered by someone arbitrarily deciding that I don't need to. I also shouldn't need to input another set of credentials, as my name isn't Mr. Root or Mr. Administrator. I am still the same me. The programs stored on my hard disk, on the other hand, aren't me and shouldn't be treated the same as me. They are just algorithms for performing some task, that I happened to decide to employ. I should be in total charge of their inputs and outputs. If I play a game I expect it to take input from my keyboard and mouse and produce output in a rectangular area on my screen. I do not expect it to take input from NuclearTorpedoTrajectoryPlanner.cpp and send output to [email protected]. There should be an easy way for me to assure myself that programs will not perform harmful actions without having to disassemble them and without having to set up a bunch of user accounts with different passwords.

Abstractions should be available, but optional. On some of my disks I may want to have various partitions with file systems, and on others I might just want to access sectors randomly. And I should be able to delegate access to these various levels of abstractions to others. Typical administration tasks, such as installing and updating software, should definitely have a well designed abstract interface. If company employees need to call the system administrator for routine tasks, the system is not doing its job.