OSDev.org

iansjack wrote:

AndrewAPrice wrote:Most end-user devices I've had have only a single user profile.

That must mean that you log on to your desktop and laptop as the root user. I'm surprised that anyone on these forums is that foolish.

All my computers have ordinary accounts as well as the root account and I always use the less privileged account 99% of the time.

Sorry, I mean I have one end-user profile. The fact that 'sudo' and other system configuration tools ask for my account's password means it's to protect against mallicious software rather than me being a mallicious user who's going to break my own personal computer.

But, would these use cases be better handled by a per-process permissions system? e.g. It's probably more devastating if a mallicious program deleted my user files (code, documents, save games, etc.) than system files (which I can reinstall.) So rather than having access to every file that your user has access to, processes could be granted individual permissions such as:

• Can read system files
• Can modify system files
• Can read user documents
• Can modify user documents
• Can modify the files of [insert other application's name]

The granularity of such controls can be debated (for example, your word processor could be locked down to just reading and writing one specific directory.)

Imagine being prompted:

"Minesweeper wants to install 'Tr0j@n H@x'.
[Allow], [Just this once], [Deny]"

There shouldn't be a reason to need to run as a seperate user if it's just to sandbox processes from doing things they shouldn't. There can be permissions for accessing the camera, playing audio, the network, going fullscreen. Permissions could expire if a program hasn't used them for a while.

The most interesting developments regarding this is happening in the mobile realm.



So yeah, even though Android and most OS's have root users, this shouldn't be neccessary, and I believe you could design a functional desktop OS without users profiles.

Schol-R-LEA wrote: This is an extremely disingenuous answer, given the embedded-system usage model of your OS. A general-purpose OS simply won't be practical working that way in any realistic scenario. You have computers used by different people over time, computers with varying hardware configurations which may change over time (and whose users won't want or be able to recompile the kernel on each and every configuration change), computers which need to share file systems, computers which need to share peripherals, peripherals which may be connected only part of the time, and so on. All of these present security concerns which a real-world GPOS has to address.

I use it for controling my house too and I have a webpage (home.rdos.net) where I show realtime data. However. the only thing people can do with it is to view data. They cannot log in (and nor can I), which is the intention. I can get into it from my local network, or by using the physical laptop. Actually, I also have a real-time display with more detailed data that I show on the laptop. This is not an embedded system, rather it uses a standard laptop, an USB-to-485 converter and a home-built USB card. It collects data by using Modbus and the webpages of my inverters. It has a command shell and a controller program.

Schol-R-LEA wrote: My impression is that your design really comes down to, "general-purpose computing is a mistake, make everything a kiosk or embedded system instead", which I really doubt was your intention. While it is true that a system which does nothing to prevent malicious intrusion is worse than useless, so is one which does so by locking down everything into a fixed system which the user can't subvert because there is no user (not that I think your system can't be subverted in other ways, anyway, as there is no way to build a system which can't, at the very least, be physically destroyed by an attacker).

The best way to avoid malicious intrusion is to know exactly what software you have, which services you have enabled, something you practically never know on a Windows or Linux system. At least not the usual desktop stuff.

AndrewAPrice wrote: Are single-user general purpose operating systems as useless as you are implying?

Most end-user devices I've had have only a single user profile. My laptop, my desktop, my phone, my Xbox. Even when I use my wife's laptop, I don't create a new user account on it, I just log in as her. If she wants to use my phone, I just unlock my phone and hand it to her. Yes, she can send emails as me, but you don't hand your smartphone to people you don't trust. I think most household computers are personal devices, or if they are shared they share a single user profile for the sake of simplicity.

Exactly. At home we typically have our own laptops / PCs, and they are personal and we only use one user account on them.

The extreme example is a laptop (or pad) with only a webbrowser, and then you don't need user accounts unless you autosave passwords for sites. And you can implement that in much simpler ways than with user accounts if there is no file manager and no direct access to files. Actually, by denying the webbrowser access to the filesystem malicious sites could not infect it.

iansjack wrote:

AndrewAPrice wrote:Most end-user devices I've had have only a single user profile.

That must mean that you log on to your desktop and laptop as the root user. I'm surprised that anyone on these forums is that foolish.

All my computers have ordinary accounts as well as the root account and I always use the less privileged account 99% of the time.

I don't think this has much meaning when you don't know what services are run in the background, or what back-doors your OS developper decided they wanted or needed. These typically run in kernel space and so don't care much about privilege or as system processes with unknown privilege .

Besides, I'm more worried about my documents getting deleted or corrupted than the operating system or installed software. I can always reinstall the operating system and the software.

rdos wrote:Besides, I'm more worried about my documents getting deleted or corrupted than the operating system or installed software. I can always reinstall the operating system and the software.

+1 to this. The security-via-user abstraction makes the most sense on a shared server where you do want to protect against other malicious users. On a personal computing device, I don't want protection against myself (I can reinstall the OS), I want protection against malicious programs.

AndrewAPrice wrote:So yeah, even though Android and most OS's have root users, this shouldn't be neccessary, and I believe you could design a functional desktop OS without users profiles.

So when you hand your phone to your kids (because they've forgotten/lost/lent theirs), do you want the same set of permissions to apply? Children are wildcards--even the nice ones. But it's not just permissions. Do you want them to see and use all of your apps?

Having said that, I've thought for a long time that individual app permissions such as Android has are a good thing. Unix traditionally achieved it by having special user accounts, but that's clumsy. It doesn't cleanly address the problem at all. It might have been different if Unix had had good IPC from the beginning; it could have had gatekeeper services. For example, this would have greatly improved the record-keeping of who is and who was logged in, in place of those files with the awful need for every terminal emulator to be set suid.

An up-side of Plan 9's namespaces is any process's access to anything can be controlled with granularity right down to individual files if you want, but this is not usually done. You can bind /dev/null over any file, or in 9front, /dev/mordor for read/write errors. (It's an in-joke. When opening a file in Plan 9, the system walks through the elements of its path. "One does not simply walk into Mordor." ) It's also possible to bind an empty tmpfs over a directory without write permissions, or possibly even an empty directory from mntgen, although that's using mntgen backwards from its intended purpose. There's a way to build complex namespaces from files which would help in all this. The files can mostly be generated by ns, although some services will only show as the generic "pipe server".

This reminds me of the very first thing which annoyed me about Linux. I didn't feel like I could get a good view of what all the background processes were doing. I suppose I could have if I tried hard enough, and you can find out which server is serving each "pipe service" if you try in Plan 9, but I never felt either OS made it easy enough. My limited attention span doesn't help; otherwise lsof (list open files) would have been a more useful tool. At least both systems have grep which helps me with any listing tool.

I have an FTP server class that I can add to applications, or use for debug boots. I simply define in software what directory to link to the FTP root for which users, and if the content can be modified or not. This doesn't need access rights in the filesystem. I simply block FTP commands that modify content, and setup the root based on the username provided (or disallow access if username is not allowed or password is wrong). For debug purposes, I have an FTP program that has one standard username & password per drive that I can autostart. Then I can easily download programs or data for test. In production releases, I don't autostart it, or provide more restricted access in the programs I run.

Also, filesystem based user rights are only good as long as you boot the operating system that created them. If I boot RDOS with ext drivers (if I had those) on a Linux system, I could modify anything I wanted. Same with NTFS if I had a driver. If a disc has an EFI system partition, I mount it to b: without any restrictions, which is quite useful for modifying locked-down EFI boots when booting with USB disc is possible. In Windows, you cannot easily access the EFI system partition.

I like the idea of app based rights a lot more than the outdated user account model. About the only thing that this protects you from in Linux are from yourself, and often yhou wish this stuff just didn't exist so you didn't have to figure out how to disable it. As an example, I have an web host with an dedicated server, and some of the files where created by a now deleted user, and so I cannot delete them myself without the help from admins.

eekee wrote:Having said that, I've thought for a long time that individual app permissions such as Android has are a good thing. Unix traditionally achieved it by having special user accounts, but that's clumsy.

But mobile device operating systems are used differently than desktop OSes.
For example, there's a database somewhere on every Android system that holds which permissions each individual app has.
That's alright for apps. They are all stored in one place (well, sorta), all accounted for, etc.

However, on desktop OSes, users may run executables they download from the internet, build themselves, etc. and they won't all be in the same place.
Some executables might be moved to a different folder. It's a lot harder to keep track of the permissions per each executable.
I guess one possible solution would be to create a custom filesystem that supports permissions.

Anyways, those were just my thoughts on the permission model thing.

rdos wrote:The best way to avoid malicious intrusion is to know exactly what software you have, which services you have enabled, something you practically never know on a Windows or Linux system.

This is a fair point (though strictly speaking, the real 'best way' is to not run the computer at all, or better still, not have one in the first place - but these are not acceptable solutions, I imagine). It is also impractical to expect the average user to know these things, or even understand what they are. People only have so much time in the day, and expecting them to learn all of these details is a good way to ensure that most people will choose a different OS.

rdos wrote: I don't think this has much meaning when you don't know what services are run in the background, or what back-doors your OS developer decided they wanted or needed.

Quick thought experiment: try to explain to a non-programmer what a 'system service' is. Now try to think of a situation where an average user would care, or find it acceptable that they would need to know that.

rdos wrote:or what back-doors your OS developer decided they wanted or needed.

And why should the trust your system not to have any, when pretty much every other OS dev has done so in the past? I suppose the argument is whether they trust the OS dev, but as Thompson argued in "Reflections on Trusting Trust" (where he revealed a backdoor in the original Unix, and a related Trojan Horse hack in its C compiler which ensured the backdoor is automatically inserted into the OS at compile time), a 'trusted computing resource' is only as trustworthy as those developing it. As Thompson says, "You can't trust code that you did not totally create yourself", but that's not an option for almost anyone.

An OS developed by a single person has only one point of trust, true, but at the same time there are no checks on their authority as would be the case for a system developed by several persons who are confirming the validity of each others' work. That 'single point of failure' is a potentially big one.

rdos wrote:These typically run in kernel space and so don't care much about privilege or as system processes with unknown privilege .

I don't disagree that running services with blanket privileges is a bad idea; but to me, this indicates that one should have a more elaborate security system, perhaps using capabilities, rather than the binary all-or-nothing dichotomous system seen in both Windows and Unices.

There is going to be a need for loadable system services in any truly general-purpose OS, simply because general-purpose systems are designed to be used, well, generally - they are not, and cannot be, designed to be complete at compile time, or even designed to be configured for all possible uses at installation time. It isn't feasible to expect non-OS-dev users to be able to know ahead of time what they will need when the system is installed, nor should they be expected to re-install the whole OS whenever the drivers are changed. The problem has nothing to do with OS design and everything to do with how they are used - they must be usable by ordinary people, people who simply don't have time to administrate their systems manually.

The average user never installs a new OS on their hardware, and requiring it whenever the hardware is changed is not going to be acceptable to users who want a system that behaves like an appliance.

rdos wrote:Besides, I'm more worried about my documents getting deleted or corrupted than the operating system or installed software. I can always reinstall the operating system and the software.

AndrewAPrice wrote:+1 to this. The security-via-user abstraction makes the most sense on a shared server where you do want to protect against other malicious users. On a personal computing device, I don't want protection against myself (I can reinstall the OS), I want protection against malicious programs.

Again, I agree, but I think Andrew and rdos are looking at this from very different perspectives - Andrew, IIUC, is advocating a capabilities-based security system (security-by-process rather than by-user) whereas rdos is arguing that the need for security in the usual sense can be completely obviated, but at the cost of locking down such that only a handful of pre-installed, whitelisted applications can be run, and all hardware services are compiled into the kernel at installation time. While I agree in principle (clearly you can't run malicious code if you can't add new code at all), I cannot see it being practical for a mainstream user base.

And it isn't as if it hasn't been tried before. The Canon Cat, which in some ways was very well-designed and innovative, failed to get any real traction. Netbooks and similar systems tried working with a limited application suite stored remotely, only to find most users needed more and more different applications as time went on. Hell, the original idea of the Chromebook (which admittedly used a stripped-down Linux rather than the sort of simpler OS that it could have) was that everything would be run through the browser, only to find that the browser itself rapidly evolved into (with apologies to Phil Greenspun) an ad hoc, informally-specified, bug-ridden, slow implementation of half of Linux.

As for Android and iOS, as I've said many times before, the important part of those isn't the OS, it's the application ecosystem. While I have problems with both of those OSes (and their ecosystems), the truth is that the real problem is the one holding the device, not the software itself, and the fact that they need the system to do what they require it to with as little effort on their own part as possible.

No one - no matter how experienced as a user, programmer, or sysadmin - never makes a mistake in using a computer. A locked-down system only lowers the risks, it does not eliminate it, and the cost of locking it down is not going to be acceptable to most users.

As I have said before, my plan is to sandbox everything, such that each program only has the access to what it needs. This, however, is easier said than done, as there is no way that a programmer can know ahead of time whether they will need access to, say, a printer or a storage device which wasn't available when it was installed. Even in a single-user home environment, the system has to be able to give access to resources which may not be online all the time, might not have been part of the system at install time, or might in the future develop a fault which the system will need to detect and disable access to. Capabilities seem a suitable way forward for this, which is why I intend to use them.

eekee wrote:So when you hand your phone to your kids (because they've forgotten/lost/lent theirs), do you want the same set of permissions to apply? Children are wildcards--even the nice ones. But it's not just permissions. Do you want them to see and use all of your apps?

How many parents just unlock their phone and hand it to their kid? Not saying it's the safest thing to do, but individual apps such as my bank's and stock broker's app make me sign in again. You can configure the app store to prompt you for your password before purchases. Of course, they can still send a "I QUIT AND HATE YOU ALL" email to your work.

foliagecanine wrote: However, on desktop OSes, users may run executables they download from the internet, build themselves, etc. and they won't all be in the same place.
Some executables might be moved to a different folder. It's a lot harder to keep track of the permissions per each executable.
I guess one possible solution would be to create a custom filesystem that supports permissions.

Anyways, those were just my thoughts on the permission model thing.

The same system could apply. A brand new never seen before program would have no permissions, and you'll be prompted with a "[Allow] [Just this once] [Deny]" prompt when it tries to do something it doesn't have permission to do. Maybe your permissions system can remember permissions by binary path or something, so if you're rapidly iterating and rebuilding, it's not constantly reprompting you for the same old permissions.

AndrewAPrice wrote:The same system could apply. A brand new never seen before program would have no permissions, and you'll be prompted with a "[Allow] [Just this once] [Deny]" prompt when it tries to do something it doesn't have permission to do. Maybe your permissions system can remember permissions by binary path or something, so if you're rapidly iterating and rebuilding, it's not constantly reprompting you for the same old permissions.

Where does the permission data get stored (for the "[Allow]" button to work)? A database?
And WHAT gets stored to identify the program? The path? A hash?

If it's a path then if it gets moved/copied you'll need to give new permissions.
Also, you might end up with a dead entry in the database (pointing to nowhere).
And how would you prevent something from replacing the executable and getting the same permissions?

If you use a hash, you'll be forced to give permissions every time the program updates.

foliagecanine wrote:Where does the permission data get stored (for the "[Allow]" button to work)? A database?

It's up to you. Windows has a registry. My OS is has a microkernel, so I'm going to have a Permissions Manager. It'll store the permissions in a file. If it's a single user system and you answer [Allow] to "Tr0j@n H0R53 wants access to modify the files of Permissions Manager." then I can't protect you against yourself. Maybe for certain suspicious permissions I could double prompt the user with a description of the consequences. But, the OS isn't a nanny. If you want want to reformat your hard drive, the OS shouldn't try to stop you.

foliagecanine wrote:And WHAT gets stored to identify the program? The path? A hash?

I'm going to KISS and use paths for now.

foliagecanine wrote:If it's a path then if it gets moved/copied you'll need to give new permissions.

Rarely am I moving release versions of binaries around on my computer. I'm ok being reprompted. Maybe an application can request permissions in bulk at startup (although I'm against granting all-or-nothing permissions - they should be individually configurable, but it can all be done on one dialog and not 20 dialogs?)

foliagecanine wrote:Also, you might end up with a dead entry in the database (pointing to nowhere).

I'm thinking it might be wise to let permissions expire, say after 1 month, so entries to dead programs will be cleaned up.

foliagecanine wrote:And how would you prevent something from replacing the executable and getting the same permissions?

So in my OS, release applications live in /applications/ and modifying an application's private files requires special permission and will prompt the user.

There's still the issue of if you give permission low level disk access to "/documents/programming/DiskDefragmenter/build/perception-optimized/DiskDefragmenter.app" that you're developing, then you have a malicious compiler that writes ransomware to DiskDefragmenter.app. Maybe I could limit permissions to programs outside of /applications/ to 24 hours, with the option of the user selecting [Just this once]?

Can you think of a better solution?

Schol-R-LEA wrote:This is a fair point (though strictly speaking, the real 'best way' is to not run the computer at all, or better still, not have one in the first place - but these are not acceptable solutions, I imagine). It is also impractical to expect the average user to know these things, or even understand what they are. People only have so much time in the day, and expecting them to learn all of these details is a good way to ensure that most people will choose a different OS.

Fair enough, but as a more advanced user you should be able to figure this out. I'm not much concerned about the typical desktop user that mostly browses the web anyway, more with people that are designing advanced technical systems or that want to be able to configure their system according to their needs.

Schol-R-LEA wrote:And why should the trust your system not to have any, when pretty much every other OS dev has done so in the past? I suppose the argument is whether they trust the OS dev, but as Thompson argued in "Reflections on Trusting Trust" (where he revealed a backdoor in the original Unix, and a related Trojan Horse hack in its C compiler which ensured the backdoor is automatically inserted into the OS at compile time), a 'trusted computing resource' is only as trustworthy as those developing it. As Thompson says, "You can't trust code that you did not totally create yourself", but that's not an option for almost anyone.

An OS developed by a single person has only one point of trust, true, but at the same time there are no checks on their authority as would be the case for a system developed by several persons who are confirming the validity of each others' work. That 'single point of failure' is a potentially big one.

Today, there are two primary models in this area:
1. Provide a preconfigured OS that installs itself & configures itself. (Windows & Linux distros)
2. Build you own kernel.

I don't find any of these acceptable solutions. I don't want to have to compile the kernel to select which drivers to include. I want to do this with a build tool (not a compiler or linker), rather a program that is multiplatform and a configuration file. I also don't want the system to be able to load additional kernel-mode drivers or server processes since I already told the system which one's that are acceptable to include. You don't need to be an expert to tell the system you want an FTP server, a webserver, the debug enviroment and a command shell.

Schol-R-LEA wrote: There is going to be a need for loadable system services in any truly general-purpose OS, simply because general-purpose systems are designed to be used, well, generally - they are not, and cannot be, designed to be complete at compile time, or even designed to be configured for all possible uses at installation time. It isn't feasible to expect non-OS-dev users to be able to know ahead of time what they will need when the system is installed, nor should they be expected to re-install the whole OS whenever the drivers are changed. The problem has nothing to do with OS design and everything to do with how they are used - they must be usable by ordinary people, people who simply don't have time to administrate their systems manually.

I don't think so. You don't need to build the kernel to select which devices to include and you can proload the services you want at build time and deny any additional services from being started. If you want to add additional services, you simply go back to your build tool & configuration script and add them. If you design the build tool properly, even non-expert users will be able to use it. It can look much like the add/remove programs in Windows.

Schol-R-LEA wrote: Again, I agree, but I think Andrew and rdos are looking at this from very different perspectives - Andrew, IIUC, is advocating a capabilities-based security system (security-by-process rather than by-user) whereas rdos is arguing that the need for security in the usual sense can be completely obviated, but at the cost of locking down such that only a handful of pre-installed, whitelisted applications can be run, and all hardware services are compiled into the kernel at installation time. While I agree in principle (clearly you can't run malicious code if you can't add new code at all), I cannot see it being practical for a mainstream user base.

I like Andrews idea a lot and it makes much more sense than the user account model. I don't focus on the consumer market, or the mainstream user base so I have no intention of actually implementing this in my system, but I still like the idea behind it.

foliagecanine wrote:However, on desktop OSes, users may run executables they download from the internet, build themselves, etc. and they won't all be in the same place.
Some executables might be moved to a different folder. It's a lot harder to keep track of the permissions per each executable.

This is a problem in so many ways that I'm trying to get ideas for dealing with it. The problem is that the canonical way to find a file is the same as the user's tool for organizing that thing. Thus, when the user decides to reorganize, the system is broken - file-type associations get broken for example. It's a very difficult problem to generally fix. OS X seems to have solved it for the file association case. (I'm not sure how. Perhaps the filesystem updates the file association database. If true, I'm sure this method would give Unix purists the screaming heebie-jeebies! I'm almost sure the suckless guys are Unix purists and I know many Plan 9ers are.) 'Proper' Unix and Plan 9 have effectively 'solved' the problem for file associations by scattering applications all over the tree! This muddies the user's view of each package's installation while requiring they use complex, awkward package managers. (Package managers have also contributed to today's software problems by trivializing dependencies.) Android (and I imagine iOS) have solved the problem for many things by disallowing reorganization of the hierarchy and limiting where apps can install files.

The trouble with all this is it's very difficult to imagine one really good fix. The need for different storage for temporary files, variable files, and read-only files can be solved with file attributes which the OS uses to decide which backend storage to use for each file, but this doesn't help with file associations. File associations and security alike might seem to be solved by the method I described in parentheses above, but this has a huge gaping hole: what happens when a user copies an application and deletes the original. Hard problem, no good solution!


On simplicity, here's a very interesting paragraph from colorForth in Black & White by Howerd Oakford:

Philosophy : Keep It Simple
It is not easy to define simplicity – it is more of a direction than a goal. Sometimes adding complexity in one area can decrease the complexity overall. An example is the simple Text Input Buffer in conventional Forth being replaced by a pre-parsing Shannon-Fano encoder in colorForth – but this simplifies the compiler.

I recall coming to the same conclusion independently while reasoning about how to improve my Plan 9 use, but Howerd Oakford expresses it more clearly. It ultimately led to me abandoning daily use of Plan 9 and going off suckless. Note the suckless philosophy document makes no mention of the value of appropriately applied complexity.

If I seem to be beating overly hard on suckless, it's because of experience. I subscribed to the philosophy to the extent that I was genuinely angry with complex software and thought technology could genuinely be improved by "simplicity". Then I came to realize it's a shallow way of thinking. To summarize my feelings: Augh! All the same, it's hard to hate the people involved in forming the philosophy, such as troubled angry Uriel who tried so hard to promote Plan 9, or the founder of suckless.org, Anselm R. Garbe who was nice to everyone as far as I could see. We were all just trying to make life easier in a difficult field, and we'd fallen into the dead ends of Unix and Plan 9... which in turn were made by Ken Thompson who also seems to have idolized simplicity.

...Sometimes adding complexity in one area can decrease the complexity overall...

Definitely.

If I seem to be beating overly hard on suckless, it's because of experience. I subscribed to the philosophy to the extent that I was genuinely angry with complex software and thought technology could genuinely be improved by "simplicity".

I still think so. I experienced the people at suckless.org are quite stubborn and unfriendly (while they probably think I'm an a***). But I still think they are right on the cause. So I don't go with the suckless-organisation, but I go with their philosophy.

I still think that the X window system and the Linux kernel, to name just two examples, are too complex. They are good reasons for that complexity, for example X bringing up a portable and extensible interface and Linux following the "bazaar" development style. But anyway.

Greetings
Peter