OSDev.org

@Gigasoft: You have good points.

Gigasoft wrote: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 am not fully agreeing on this. As a computer owner, you could do anything. The main point is that you simply could not do this at the normal running level. There just would not be any mechanism to do that. Giving free write and read privileges to disk sectors weakens the OS's purpose of existence: providing abstractions. A file system driver needs "hardware-like" abstractions but applications and users need something like "file" abstractions.

Of course, this is overly simplified view and there is a big difference whether the disk is a "system disk" or an external USB stick containing data. The latter is a bit problematic and all this may sound overkill.

Hi,

I think this mainly depends on what the OS is designed for.

For example, for some OSs it's reasonable to assume that the computer owner is the administrator and the maintenance person and the user. For other OSs (e.g. intended for larger systems) these could/should all be considered 4 different roles done by 4 different types of people; where (e.g.) the computer owner might be the CEO of a company who doesn't know how to be a system's administrator but should still be able to delete an administrator's account if the administrator needs to be fired and then create a new administrator account for the new replacement administrator.


Cheers,

Brendan

Brendan wrote:I think this mainly depends on what the OS is designed for.

It seems the discussion is about an OS, designed for strong security enforcement. And the problem is - how to enforce the security and not to make system usage very inconvenient.

Combuster wrote:

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

Well it depend at which level you are developing. If you are working on the permission system, you definatly need to have some kind of way to change/install/update things on the system below permission level.

Combuster wrote: Besides, shouldn't you always want as a system to cry havoc at the programmer if he wrote buggy code?

Ha, i always wondered what this '_KABOOM' ACPI function was about.

Gigasoft wrote: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.

One way to have something secure in that particular case is cryptography, and having sensitive data on the harddrive encrypted, in sort that only the program that you explicitly authorize to access them by giving them the encryption key can access it. The problem is that cryptography is not very well integrated into OSes for mostly legal reason linked to 'security' in the real world sense. But having some cryptographic system used on top of everything, with public/private key associated with some context of use, lot of things could be made much more secure.

It's just that somewhere there is also a certain number of reason why system made for the civil industry are intentionally made not to be too secure as well. We even live in a world where program implement leaking of personal information as a feature more than as a security bug (like facebook etc).

But it's not necessarily the only problematic, it could be applied to anything like system setting, internet browser setting, or any resource of which access should be controlled. Why not volume of audio devices, or more other things that are not necessarily related to file system access. Maybe you would want some program to have access to some local setting or resources, and not some other programs. Or having a way to know what kind of resource you want the program to be able to use.

Cryptography is just a workaround that allows you to transmit secure data over an insecure medium. But I shouldn't have to "sneak" my secret documents past my applications in the first place. That's absurd. There is no reason that an arbitrary program should be able to access any random thing on my computer, or even know of their existence. They only need to be provided with access to the specific resources that I want them to operate on.

In my OS, I'm experimenting with having an application's menu bar managed and drawn by the system. An application that can load and save files, such as Notepad, will have "Open", "Save" and "Save As" commands provided by the system, and perhaps a "Recent" list. These commands will trigger an interface for loading and saving files safely. All the program will get is a handle to read from or write to.

For more advanced scenarios I imagine that one would provide configurable, permanent access to some resources. For example, a sound recording application might have permanent access to a particular sound source, and an emulator for some computer system might be given access to system ROM images, since you wouldn't want to "Open" these manually every time you run the program.

Some applications, such as Solitaire, do not need to access anything at all. All it needs to do is create a window, respond to input, and draw things when requested by the system.

I don't see crypto as only a workaround at all. If you had the permission system based on cryptography, and having certain resource that are supposed to only be used by a certain permission level using a crypto key known by the system for that permission level, it can be more effective than any kind of software permission logic. And even if the software permission logic fail, the resource still cannot be accessed. And it make in sort that the resource can physically only be accessed using the proper permission system to be able to deal with the encryption. Even if the hardware is pluged into an entire different system, you still can't access the data unless you know the good key associated with the permission system to access it. Asymmetric encryption algorithm can allow for more than just allow to transmit data, but also to identify both the source and the destination in reliable manner. Maybe it would be a little bit too heavy to use this for just everything, but it can be very good way to implement robust security/access logic.

If you need to protect against a person grabbing your hard drive, that's an entirely different problem, which is independent of protecting an user against applications that are up to something. In that case, I'd use an encrypted file system, but that's nothing that applications should have to worry about. If applications would have to use cryptography to prove that they are authorized to access some resource, that would basically be the equivalent of me walking into my boss's office and whispering, "Hey, psst. The owls are flying low today and Uncle Peter has taken his wife's sister as a concubine" to request a printed copy of some document. Which I fortunately don't need to do, because my boss already knows perfectly well what projects I'm involved with and which documents I have any business reading.

Having knowledge of a secret key, can in all of these cases be replaced with having an entry in the handle table for the process, and a system call for passing it to another process. In the multi-computer case, the computers will be authenticated with each other and there will be a master handle table for all the resources that a client is currently accessing on the server.

I currently don't have a file API for user mode (yet, Solitaire still works splendidly!), but when it gets implemented, one thing you won't find is the traditional Unix "open" call. To open a file explicitly, you'll need to supply a valid directory handle with the appropriate access rights. I might not have permission checks on the individual files themselves, but symbolic links will have an access mask which restricts the operations permitted on the link target regardless of requestor. Of course, that means you can't just create any symbolic link pointing anywhere, either - this will require a "path handle". But, all this means that there probably won't be a need for access control lists per item. Each user will have a home directory, and some way to share things with others, and that's it. So, from an application's point of view, it doesn't matter if it is being run by the administrator or someone else, it still only gets access to what the user tells it to access, and you don't accidentally compromise the system because the administrator accidentally gave you access to something you shouldn't.

well maybe having asymmetric crypto for everything would be a tad overkill, but you could have a system that for every kernel call, you have to issue some kind of request token for doing that action, that would act like a sort of certificate to sign your actual request data. Or having either function name or pointer crypted, or having request made in sort of packet like ATAPI.

The problem with the analogy with your boss is that it's more like if you had to use some random intermediate between you and your boss to require the printed copy of the thing, because it's what happen when you run a program, you don't do the kernel call manually, but an automatized program will do it for you. So in that case, could be nice to have at least some kind of secure badge system, like a certificate system, to be sure that the request really come from an employee of the company. And the be sure the request is really made to the person that it's supposed to be made to. Kinda like the seal that kings could use in the middle age. Or it could make it much easier to actually track the origin of an action or request.

I'm not sure in all detail how a system making good use of data signing and asymmetric crypto could be implemented nicely, but i'm pretty sure something quite nice could be made.

And it could also work in the same way being put in relation with a kerebros like system or https system, rather easily as well to allow also secure authentification over network.

And for me having a true control over you data, and what can be sent over the network in what form, and who can read it, is not necessarily limited to protecting against former 'malware' on the running system, but as well to regular sofware, web thing, or any other software for whom data leaking is more a non marketized feature rather than truly a bug. Or even if you have to move data to another computer over the network that you only want a single other person to be able to read.

h0bby1 wrote:well maybe having asymmetric crypto for everything would be a tad overkill

It's not only overkill. If something has managed to get your permissions to do something - why it can't obtain your private key? The key is just data and is hidden by permissions only.

embryo wrote:

h0bby1 wrote:well maybe having asymmetric crypto for everything would be a tad overkill

It's not only overkill. If something has managed to get your permissions to do something - why it can't obtain your private key? The key is just data and is hidden by permissions only.

It's just to avoid the case where permission are hacked somehow through some kind of bug that bypass the permission system.

The point is to avoid that something that has not managed to get your permission to do something can still do it.

With crypto even if a program has the permission to read sector on the hardrive, it still can't read your files. It could eventually delete them, or alterate the content though. But at least you can know it has been altered without permission.

if a program can have access to the kernel API to control audio volume, even at equivalent of root level permission , it still can't make the request unless it has the key associated with it.

But of course if you give the particular key to a program, it's useless. The point would be that the key to access certain things would only be given to the program that are actually supposed to access it. Or to give the possibility to do it, there could be various way to do it ranging from more annoying at user level, to more automatic and potentially exploitable somehow.

Potentially, in the extreme, even the kernel itself could not access some resource without an explicit permission from the user.

Well i won't go in all detail, because it's not something i plan to implement in short term anyway, but i can think different kind of implementation taking from a program running in user space that could clearly complicate a lot any unauthorized access to any resource without explicit permission. Or give the possibility to do it in various way.

Application could contain some kind of signed id , to identify some application domain associated with the signature. And only request that match this application domain permission could be executed by the application. And for higher level of permission, an explicit user interaction could be required at kernel level to authorize the kernel to deliver the signed id to the application. And without this signed ID, the application can't access the function associated with the permission level. The kernel would have a private key for each level of permission used to sign application id, or some token that the application need to have to execute some operations.

Then unless the program can get to ring0 and do hardware request totally bypassing the kernel, there is no a way an unauthorized application can run function that are not within it's permission level.

And you could have several application domain like that per user. Like running an application in a specific domain and another application in another domain from the same user. They would just use different key or token to identify themselves to the kernel within that application domain. And the only way an application can have a valid token is to have the private key for the permission level, which would be kept in the kernel space memory.

Or for each operation, the application could be made to require a token from the kernel, this token could be based on timestamp, application code segment, or something that can identify the program, to be crypted with the private key associated with the permission level. If the application don't have the private key of the kernel, or if a wrong application use the token, or if the application's code segment is changed it can't access the resource.

It would be a bit overkill to do that for everything systematically. But it could be a good way to handle permissions. At least to have the possibility restrict some action to some trust application domain, and require explicit permission for an application to gain access to that domain.

There are many thing that can be though of that could make it hard to bypass authorization.

But ultimatly yes, if you give explicitly permission to a program to access the resource, it's hard to see why the system should block the action.

h0bby1 wrote:The point is to avoid that something that has not managed to get your permission to do something can still do it.

With crypto even if a program has the permission to read sector on the hardrive, it still can't read your files.

If some program has managed to obtain disk read permission then it is possible to read private key. If private key is encrypted, then it is possible to read encryption key. If the encryption key is encrypted, then it is possible to read another encryption key. And so on.

With permissions it is possible to have disk read permission along with system area read permission. So if something has managed to get disk read permission (or circumvent it) then it is still unable to read the system area. And it requires no permanent overhead with encryption/decryption.

h0bby1 wrote:The point would be that the key to access certain things would only be given to the program that are actually supposed to access it.

It complicates the hacking, but when there are some key owners, hackers just need to circumvent permissions, associated with the key owners. Your case just moves hacker attention from simple disk read to a read from particular location within the key owner storage. In case of fine grained permissions the situation is a bit similar, but hacker should manage to obtain two permissions instead of one disk read permission and information about key storage location. It means - two permissions against one permission + some information (which is often well documented in open source projects).

h0bby1 wrote:Potentially, in the extreme, even the kernel itself could not access some resource without an explicit permission from the user.

And it seems the Windows is close to such solution.

Sandbox is good but as I see in android or Mac OS X the profiles, or list of permission rules become very long that most user just press the next button.

IMO that is more of user experience issue than technical issue.

embryo wrote:

h0bby1 wrote:The point is to avoid that something that has not managed to get your permission to do something can still do it.

With crypto even if a program has the permission to read sector on the hardrive, it still can't read your files.

If some program has managed to obtain disk read permission then it is possible to read private key. If private key is encrypted, then it is possible to read encryption key. If the encryption key is encrypted, then it is possible to read another encryption key. And so on.

With permissions it is possible to have disk read permission along with system area read permission. So if something has managed to get disk read permission (or circumvent it) then it is still unable to read the system area. And it requires no permanent overhead with encryption/decryption.

h0bby1 wrote:The point would be that the key to access certain things would only be given to the program that are actually supposed to access it.

It complicates the hacking, but when there are some key owners, hackers just need to circumvent permissions, associated with the key owners. Your case just moves hacker attention from simple disk read to a read from particular location within the key owner storage. In case of fine grained permissions the situation is a bit similar, but hacker should manage to obtain two permissions instead of one disk read permission and information about key storage location. It means - two permissions against one permission + some information (which is often well documented in open source projects).

h0bby1 wrote:Potentially, in the extreme, even the kernel itself could not access some resource without an explicit permission from the user.

And it seems the Windows is close to such solution.

the way i see it, those private keys would be generated at boot time, and eventually recycled as frequently as possible, the kernel in the absolute just has to keep track of the key used by running application, but it would not be specially for file/disk encryption, but for the side of authentification in general. To have a way to identify application as being 'genuinely' authorized to do what it pretend it can do in a secure manner.

If the program run in user space, it's easy to limit the access to the hardware if all access go through kernel calls, which would most likely be the case if you want security anyway, and it would be totally possible to make some area of the harddrive unaccessible through kernel calls. And put any security related information there. Any system of permission would be based on the ability of kernel to limit access to hardware anyway. Encryption just make identification more secure.


It's not so much the fact that the data will be "crypted" or "hidden", but that if you have a known set of data, the data resulting from the original data being encrypted with a specific key cannot be falsified.

With a system of crypto, the kernel can have a way to make sure the data it send has not be modified by another program. If you use some kind of token generated by the kernel used to identify the application permission level.

It's not so much to hide this data to the application, but to make the application unable to generate valid data without knowing the private key that encrypted it. If the application has to use kernel generated identification, encrypting them add a layer of security to it. If some permission/Security credential has to be generated by the kernel to be used by an application, encrypting them can make sure the application cannot modify them, or generate valid credentials.

An 'admin' mode would just be used to create and modify those permission level and eventually something to automatically associate certain application with a certain level of permission.

It would still need some equivalent of gid associated with application, but application would be run on the basis of some application domain, and given a credential associated with this permission level in a encrypted form by the kernel that would then condition what function or api the application can use. Could be sort of like a gid, but more flexible. And not only limited to file system access, or even directly linked to file permission at all.

With asymmetric crypto, the destination program can identity the source of the data in a reliable manner from it's public key, and the source program can make sure only the program who has the public key can use the data. But the program having access to public key cannot encrypt data that would be decryptable using this public key.

But it's more the properties to be able to 'sign' the data using a private key that can be used rather than the property to make it hidden or encrypted.

Storing permanent encrypted data is different matter than control of general system function. For system function, the key doesn't have to make it ever on the harddrive, or to user space memory, they just have to be stored in kernel space memory for running application and control authorized action in general.

For file encryption, the key must not be wrote on the hard drive, or not on place that any program can read that's pretty clear lol Either the user would have to enter the key manually, or it would need some special handling in the kernel if the key are to be stored somewhere.

If you had some kind of very sensitive information on your hard drive like some industrial secret, and that you want to be able to run random internet application on it, then the only way to really protect the file from being leaked without bothering about having several account is to crypt them, but the key should be then either entered manually, or stored on a specific media, or on a place that is not readable by applications.

A set of 'permanent' private key could be managed via the kernel, for the purpose of encrypting non temporary data on hard drive, and it could at least be made easier to track and control access to this data, without having to deal with file system based permissions. Even if the kernel has to store a set of permanent key, it can be made in sort that those key never make it to user space at all. But associated with some permission level, and only application run with that permission level can read the information (but can still alterate or modify or delete it if it has harddrive access).

A system like that could be used to reinforce or complement file system based permission, you could make in sort to have application in a certain application domain automatically store all files in an encrypted form, and then not having to bother too much about file system permission regarding potential leaking. But it would require to store those encryption key in a place that is never accessible at all other than in admin mode to add new application domain.

It cannot replace entirely file system based permission for file access, but can help to have solid mechanism to protect data privacy, by requiring explicit user interaction to authorize application to reach some application domain associated with sensitive data for ex, and even if file system security is compromised, it doesn't give the program access to read the sensitive data (provided the key are stored somehow outside of the file system, in a place that is handled specially by the kernel with other interface than file system). It give potentially another level of authorization/security than purely file system based to protect sensitive data from leak.

A file could be stored in any place, in any folder or moved around, from an hd to another or anything without you have to worry about it's permission (unless you want to also prevent delete/corruption).

h0bby1 wrote:if you had some kind of very sensitive information on your hard drive like some industrial secret, and that you want to be able to run random internet application on it, then the only way to really protect the file from being leaked without bothering about having several account

Applications don't need accounts, and they certainly have no business prying in my account.

All these complicated schemes of yours are just replacements for missing basic facilities that the operating system should have implemented in the first place. Instead of the user telling the program some secret code so that it can prove itself to the operating system, the user should just be able tell the operating system directly through an UI provided by the system.

And if a program is producing data for consumption by another program, the programs themselves have no need to verify that they are indeed communicating with the correct program, unless they are communicating over an insecure channel, which would imply that there is a very serious problem with the design of those programs or with the operating system. Whoever invoked those programs should also be the one connecting the output of one to the input of the other, so that nothing gets left to chance.

bluemoon wrote:Sandbox is good but as I see in android or Mac OS X the profiles, or list of permission rules become very long that most user just press the next button.

I am guessing that most applications don't really need all those permissions. For example, any action that would require user confirmation does not need to be approved in advance. It should also be possible to deny some of the requested permissions and still be able to run the program. In a well designed program, a dialog should pop up whenever the program needs something to continue. The user would also typically select a provider for the requested function. It does not need to ask for all these things at startup or during installation. Android leaves you with little choice - if an application might ever need to access some function, the user must approve this access in advance to even be allowed to install the application, which is a huge design flaw.