It would be to have something like
get_access(AUDI_CARD,&permissions);
set_mic_sample_rate(&permissions);
start_reccording(&permissions);
set_reccording_volume(&permissions);
permissions can be just yes/no, or anything that the driver or service provider will need to determine what the application can do on the audio card, returned in crypted form. Eventually with asymetric crypto the application can be made able to read it but cannot modify and reencrypt it.
Or wathever instead of microphone, could be access to any device, or system interface, ip range, file directory, or anything.
The private key used to encrypt the permission infos would never make it to user space or hard drive.
And all access control can be centralized on the 'get_access', and only done once for the application/client life time and would add minimum overhead in the driver/service provider code and memory. Just code to decrypt and parse the permissions informations that the get_access call created. The same system can be used for IPC, remote access, or anything else without any over head anywhere else.
Just need to have an index to a permission set for the application, like a gid, and a set of private encryption key in kernel memory. Then the access the application can have is determined based on the 'permission level index' the application is run on, and could be conditionally granted to an application at runtime, then stored in application/client memory in a crypted form.
On mono user desktop system, it could mostly replace the whole user account thing, just having an admin mode to create permissions set, to automatically allow some request to be performed by applications being run at a specific level. Or having something like an 'authorize'/'ask'/'reject' automatic behavior potentially defined for all properties of each permission level.
Then on mainly mono user system, you just have to choose at which permission level you want to run an application, or having a default permission at low level , or having profile for each type of application (game, office, internet, potential virus, server, whatever), and eventually being able to change them at runtime 'on demand' without over head in the task manager or anywhere else.
For multi user system, it could be added on top the user/login system to add more flexibility to resource access on a per user basis. Certain user could have access to certain permissions levels etc.
Eventually, it could replace also file system permissions, if file system access of some application profile can be limited to a directory, or to a list of directory, but it would not be very efficient for file server oriented system. It could be efficient on file system for system with low number of different potential access , like desktop station mostly.
For file server oriented system who can have to manage lot of different applications who can access a lot of different files locations, it could not replace efficiently file system based permissions.
For a home computer, you could have a media server running at some permissions level, but you want to grant specially another access to another client, you could just set the permission to 'ask', and then authorize it specifically one time for one connection, if the client application keep its permission token, it will be able to have access to the resource, without you have to reconfigure anything specially for it. It could eventually be time stamped.
For file system access, you could have a permissions description looking like :
<permission_level name="my permission level" default="reject">
<permission type="directory_access" path="/my_dir/" grant="accept">
</permission_level>
then application would be run with this permission level, and do
buffer_t my_permission;
get_access(DIRECTORY,"/my_dir",&my_permission);
my_permission would be like
"<permission type="directory_access" path="/my_dir/" granted="true">"
sent in crypted form, eventually with asymmetric crypto, the application could still read it.
then the application would do
open_directory("/my_dir"/,&my_permission);
read_file("/my_dir/my_file",&my_permission);
do something else, wait user input
write_file("/my_dir/my_file",&my_permission);
create_file("/my_dir/new_file",&my_permission);
etc
and the file system driver would decrypt the permission buffer, and use it to determine the permission of the application. And it could be used as well for IPC, or remote access in the exact same manner. Could be used for webcam, audio device, video card, or any other service provider who would have to control access to some resources.
It's to have a flexible system of permission without adding too much overhead in the global system code or system memory in case of a server. Like a decentralized and flexible session system. Eventually for more security, the kernel could keep an id/timestamp for each request in the system memory and check it against the data, but it should not even be necessary, with this system only the application/client need to keep this data in it's own memory.
A file server could restrict a client access at connection time without having to run a thread at the specific permission level. And it would not need to check any file system permission or do anything special for each subsequent request the client make using the token he received at the time he made the permission request. And the server doesn't have to maintain any client specific data at all.
HTTP or FTP server could be programmed on top of it, but it would need to keep the permission token in it's memory for each client connection.
Some file sharing protocol like samba could easily be made on top of it without the server would have to create a specific thread, or keep anything in memory for each client or needing any file system permission.
It would just need to do the access authorization once, based on a permission level selection for the client, and then all subsequent request made with this token will be restricted to what is allowed by the permission level contained in the token. Without having to deal with file system permission, or task system at all anywhere in the process, without major overhead, only the permissions that the application explicitly requested and need for the request would be transmitted. In the example i put them in XML-like form, but it could be in binary form and/or compressed.
All the request could be served from an unique thread with a unique permission level, and a token generated for each specific client based on a internal permission system granting access to some directory, or any resource, without having anything else like system user/uid and file system permissions. And without the file server need to know any specifics of the file system permission system, it just need to know the function to grant access to some directory to a client, and then transmit clients file request alongside with the token directly to the kernel and file system driver.
Permanent private encryption keys for file encryption could be stored with the permission level definition to grant access to encrypted files on the harddrive to application running at that application level. Other application on other permission level could still use the same directory access permission without being able to read the file.The access for the private key associated with the file could be forced to be asked at runtime.
The admin permission would be basically to grant access to the permission level definitions.
Then applications are run using those permission level, and there would be no need for anything else to control access to any system resources.
If you run a doubty application that is supposed to be a webcam program, you can run it with basic permission level, and grant it access to webcam at runtime when it request it. If you want to revoke all access to the webcam, just need to generate a new private key to access that resource. Then if the permission definition level has something like <webcam grant="ask">, you can restrict any access to the webcam at kernel level.
If a web application need to be restricted to only some domain name, or IP range it could be included in the permission definition as well. And same the token being created at application start, and passed by the application to host resolving function, and network related functions. And potentially a domain can be manually authorized at runtime on demand, without anything being stored in the system memory at all.