OSDev.org

Brendan wrote:Hi,

For things I'm doing:

• Micro-kernel. The attack surface for a monolithic kernel so massive that you're guaranteed to have "privilege escalation" vulnerabilities.
• Versioning file system. This means that nothing can modify a file (you can only create new version/s of a file). Combined with "delete only marks files as deleted and doesn't actually remove anything" this means that crypto-ransomware can't prevent access to the original unencrypted versions of files. It also means you can do "global file system roll back" relatively cheaply, just by marking newer files and directories as deleted and "undeleting" files and directories that were deleted after the time you're rolling back to.
• All executables digitally signed by the publisher's key; where you must be able to identify the publisher (publisher ID determines which private key is needed to decrypt the signature), and can have a blacklist of "known bad publishers".
• All executables given their own "userID" when they're installed; where an executable's "userID" is used for file system permissions. To access files using the currently logged in user's "userID" an executable has to ask the "station manager" to do it on its behalf. Note: "Station manager" is a layer that sits between user related device drivers (video, sound, keyboard, mouse, ...) and the GUI, that handles things like user log on/off, etc.
• No "all powerful admin/root". There are only "infrastructure officer" and "security officer" roles; where both of these are only able to use a special "management tool" designed for their role. Infrastructure officers and security officers are not able to use normal applications or use any files.
• Role-based access control and a "security manager" service. This is used for more than just file system permissions - any software or service can ask "security manager" to create a new security category, and ask "security manager" to do permission checks for its security category. For a relatively random example, maybe the networking stack creates a "TCP/IP security category" and assigns different access levels within that category to different TCP/IP ports, and uses "security manager" to check if executables and people have access to TCP/IP ports. Security officers (using their management tool) would grant executables and users a "min/max access level range" for the network stack's "TCP/IP security category". Note: Infrastructure officers and security officers don't take part in the role-based access control system, because they're only able to use the special "management tool" designed for their role. E.g. a rogue security officer can not give themselves access to confidential files.
• Only infrastructure officers are able to install executables. When executables are installed they're given "default access" (which is no access to anything other than the executable's own files). Security officers (using their management tool) have to explicitly grant additional access. Note: This means that at least 2 people need to conspire to install malware - one rogue infrastructure officer isn't enough (because they can't grant access), and one rogue security officer isn't enough (because they can't install it).

I also have a bunch of other security features ("no execute" page protection, physical address space randomisation, IOMMU restrictions for drivers, quotas for various resources, etc).

Of course the security for my OS is designed for larger distributed systems (lots of computers and lots of users). For a traditional desktop OS (e.g. one computer with one user) it'd be far too painful to tolerate. I'm not entirely sure if I'm going to do anything about that - I might (or might not) add some kind of "relaxed security mode" where a normal user is able to do everything themselves.

I'd also point out that my role-based access control system currently scares me. It's something I've not done before (previous versions of my OS had "vaguely unix like" file system permissions and not much else) and something I have no experience with, and I'm forcing it into my OS design without really being able to foresee all the consequences.


Cheers,

Brendan

This sound very very impressive. Why don't you sell your OS. By looking at it, it is far more secure than Windows. I just can't describe how bad Windows is when it comes to security. Also why don't you showcase your OS, I would really like to see how it looks/works? You are always mentioning it as it was something super cool, by the looks of things it is, but I would like to see it in action somewhere.

Capability-based security is another good option - it avoids the confused deputy problem of RBAC systems and enforces the least necessary privilege principle.

Hi,

Octacone wrote:

Brendan wrote:For things I'm doing:

This sound very very impressive. Why don't you sell your OS. By looking at it, it is far more secure than Windows. I just can't describe how bad Windows is when it comes to security. Also why don't you showcase your OS, I would really like to see how it looks/works? You are always mentioning it as it was something super cool, by the looks of things it is, but I would like to see it in action somewhere.

The current implementation of my OS is nowhere near ready for release, and (based on past history) will probably get deleted and replaced by the next implementation of my OS (which will also probably get deleted/replaced by the next implementation, which ...).

To understand this, consider this part of my last reply:

• "I'd also point out that my role-based access control system currently scares me. It's something I've not done before (previous versions of my OS had "vaguely unix like" file system permissions and not much else) and something I have no experience with, and I'm forcing it into my OS design without really being able to foresee all the consequences."

The chance of me actually being happy with my first implementation of role-based access control is very small. The things I learn implementing it the first time will make the next implementation far better, because then I'll have experience with it and be able to "foresee in hindsight"(!) much more of the consequences.

To understand this more, consider backward compatibility - "released" means that all of the design mistakes and things that could've done better end up locked in and must be upheld forever thereafter, because completely changing something fundamental (e.g. the role-based access control system) would break everything, and nobody (including me) wants to depend on an OS where everything can become broken in future updates. I'd also be tempted to suggest that a lot of the things I don't like about existing OSs, and a lot of the security problems built into existing OSs, still exist and will continue to exist because of backward compatibility - they can't be changed/fixed because too much depends on them.


Cheers,

Brendan

Brendan wrote:Hi,

Octacone wrote:

Brendan wrote:For things I'm doing:

This sound very very impressive. Why don't you sell your OS. By looking at it, it is far more secure than Windows. I just can't describe how bad Windows is when it comes to security. Also why don't you showcase your OS, I would really like to see how it looks/works? You are always mentioning it as it was something super cool, by the looks of things it is, but I would like to see it in action somewhere.

The current implementation of my OS is nowhere near ready for release, and (based on past history) will probably get deleted and replaced by the next implementation of my OS (which will also probably get deleted/replaced by the next implementation, which ...).

To understand this, consider this part of my last reply:

• "I'd also point out that my role-based access control system currently scares me. It's something I've not done before (previous versions of my OS had "vaguely unix like" file system permissions and not much else) and something I have no experience with, and I'm forcing it into my OS design without really being able to foresee all the consequences."

The chance of me actually being happy with my first implementation of role-based access control is very small. The things I learn implementing it the first time will make the next implementation far better, because then I'll have experience with it and be able to "foresee in hindsight"(!) much more of the consequences.

To understand this more, consider backward compatibility - "released" means that all of the design mistakes and things that could've done better end up locked in and must be upheld forever thereafter, because completely changing something fundamental (e.g. the role-based access control system) would break everything, and nobody (including me) wants to depend on an OS where everything can become broken in future updates. I'd also be tempted to suggest that a lot of the things I don't like about existing OSs, and a lot of the security problems built into existing OSs, still exist and will continue to exist because of backward compatibility - they can't be changed/fixed because too much depends on them.


Cheers,

Brendan

Well, I certainly understand what it means to do something without much understanding of it. I can relate this to my OS. Where in every next revision I improve something fundamental, that I didn't use to know so much about. But why to worry about backwards compatibility when there are standards. Just fix the previous bugs making sure that the standards are met. Why would somebody keep something old and broken, just improve it and make sure it works on older hardware. Hardware ages and I think that the software should age too. Why to risk having a broken software on newer hardware just to support the old stuff. Old stuff is not relevant any more so it the software. You can't expect to run the latest software on a machine that is 20 (even 10 these days) years old. Just move forward. Let me compare this to something: you have a CPU from 2017 that can't fit in a 2002 socket. Which means that the processor I am talking about is built for that specific generation without caring about older hardware and being backwards compatible. Developers are just bloating their OS'es with unnecessary stuff. Make sure it is as modern as possible, that it supports as much as it can from this century and that is it. Also does your os have a GUI/some advanced TUI, if so I would like to see a screenshot of it.

thepowersgang wrote:The solution I was going for was that untrusted programs (or even all programs) can't open files themselves (outside of their install/data directory) - Instead they as a per-user server to open a file (which might ask the user to pick the file they want to open).

Is it something like Storage Access Framework?

i think protecting the users from viruses like that ransomware, is the question of the software that is displaying the websites/emails of these infected sites, and not the operating system itself. an operating system cant really do anything about the viruses besides protecting important system files (irrelevant), or displaying a panel to allow a file access outside the software directory (and pray the user will actually click on NO). priviliges, hardware security, process separation, and all other technologies of the todays are unable to hold on against threats like this.

Geri wrote:i think protecting the users from viruses like that ransomware, is the question of the software that is displaying the websites/emails of these infected sites, and not the operating system itself. an operating system cant really do anything about the viruses besides protecting important system files (irrelevant), or displaying a panel to allow a file access outside the software directory (and pray the user will actually click on NO). priviliges, hardware security, process separation, and all other technologies of the todays are unable to hold on against threats like this.

Please read the thread. The fact that you can't comprehend does not mean it's not possible. There ARE indeed many way the OS can do about security. As for your concern about file access, there are solution that does not require user clicking Yes/No, for example, sandbox - which application can only access its own files, or apparmor - administrator(or security experts) defines a strict rule which normal user can just apply.

Hi,

Octacone wrote:Well, I certainly understand what it means to do something without much understanding of it. I can relate this to my OS. Where in every next revision I improve something fundamental, that I didn't use to know so much about. But why to worry about backwards compatibility when there are standards. Just fix the previous bugs making sure that the standards are met.

An OS is a set of standards (for one example, UNIX System V). I'm creating an OS, which means I'm creating a set of standards. I'm also creating implementation/s of my OS, but they're mostly just to ensure that the OS (the standards) aren't too broken.

For any new OS there's a huge "catch 22" problem; where developers won't write applications or drivers because there's no users, and users won't use the OS because there's no applications or drivers. It's extremely difficult to break out of the "catch 22" problem. Every time you change the OS (change the standards) in a way that break compatibility you go right back to "catch 22", and each time you do it you make it harder it is to break out of the "catch 22" problem again because fewer people (users and developers) trust you.

Note that it is possible to break backward compatibility if you do it extremely slowly - e.g. create an alternative API/interface/utility/whatever; then mark the old thing as "deprecated", then wait for at least 10 years before nobody cares about any software that still depends on whatever you deprecated.


Cheers,

Brendan

Since sandboxing keeps being brought up, some random thought I had: it could be argued that programs are not sandboxed enough (even in sandboxed environments).

Consider this: why should the codec in a music player have to know about the file? And why should it have access to the sound device? Just give it an input stream (with the file data) and an output stream (that goes to the sound system) without ever letting it know the sources for them. And why should the GUI have access to those streams? It should only be able to send messages to whatever is controlling the codec to let it know when to play/stop/seek/whatever and that's it. And why should the shuffle feature have access to anything more than just the list of songs? Etc. If you want to be really strict, each of those should be their own process completely isolated from each other.

In practice such a system would be a pain in the @$$: context switching still takes a lot of time, and this would be doing switches about as often as a traditional program would do function calls. That would completely destroy performance. To make something like this feasible you'd also need a CPU where context switching is extremely fast (which to be fair, would also improve things for more traditional systems as well).

And that's ignoring the part you can't just enforce it at the OS level since the OS would not know exactly where the boundaries should be, so you're still relying on application developers to just do the right thing...

glauxosdever wrote:

onlyonemac wrote:I also think there's too much focus on making the system secure rather than protecting user's data.

The latest attack involved destroying/encrypting user data, which unfortunately didn't require explicit permission from the user. And this exactly proves your point, and this is something we, as developers, should be more than concerned about.

Yes, exactly. Even Linux, for example, offers full access to the user's data by default. The only mainstream OS that I'm aware of that attempts to prevent unwanted access to the user's data is Android. Of course, Linux is still less likely to be affected by something such as this ransomware because the ransomware has to execute on the target system before it can do anything, which requires a remote code execution vulnerability.

Hi,

onlyonemac wrote:Of course, Linux is still less likely to be affected by something such as this ransomware because the ransomware has to execute on the target system before it can do anything, which requires a remote code execution vulnerability.

An unsuspecting user thinking they downloaded a legitimate program is an option too.

Basically, there are two kinds of sources of threats: malicious users and unsuspecting users. For both of them, there should exist counter-measures to protect the system. For malicious users, the already-discussed (and more) counter-measures can and should be implemented. For unsuspecting users, the matter probably is more complicated. What if the user thinks they downloaded a legitimate and secure program and starts assigning it permissions it shouldn't have? How would you guard against that?


Regards,
glauxosdever

If you are talking about EternalBlue and DoublePulsar, remember:
- Products are sold after security reviews. Those review are done in a finite amount of time: its costy and non exhaustive. It is done on a non finished product, with company budget.

- on the other hand, you have people working full time to discover vulnerabilities, with a big state budget.

Every OS/hardware have vulnerabilities and they will someday be exploited. Even if your OS was formally proven safe, what about the hardware ? And every stuff installed in it ?

Imho the only thing you can do is to make your users learn about not opening topsecret.zip.exe files, and make them learn what phishing is.

If i were working in IT security for my company, i would send fake phishing mails to random people every year, with content generated based on existing email they receive.
People who would fall into it would be put on a list of people who need courses. Or salary cuts.

glauxosdever wrote:What if the user thinks they downloaded a legitimate and secure program and starts assigning it permissions it shouldn't have? How would you guard against that?

There's no way to protect a stupid user from accepting requests for an application to access their data when it shouldn't need to. You can require active confirmation of each request (unless a "do not ask me again for this application" option is chosen) but in the end they'll still say "yes", just like they'd to give their phone number to someone on the street who asks for it.

onlyonemac wrote:

glauxosdever wrote:What if the user thinks they downloaded a legitimate and secure program and starts assigning it permissions it shouldn't have? How would you guard against that?

There's no way to protect a stupid user from accepting requests for an application to access their data when it shouldn't need to. You can require active confirmation of each request (unless a "do not ask me again for this application" option is chosen) but in the end they'll still say "yes", just like they'd to give their phone number to someone on the street who asks for it.

There is no reason for such a mechanism to exist in the first place. Random applications have no business asking for full access to all of the user's data.

Granting access should always involve more than just clicking on a "Yes" button. The user should explicitly designate the resource that is to be accessed, being able to see and control which access rights are being granted. Then, he should verify by clicking an "OK" button. If there is a default suggestion, it should either be harmless (for example, access to a resource that logically belongs to the application itself) or require a key press or button click separate from clicking on "OK", and come with a warning when appropriate.

Sik wrote:Consider this: why should the codec in a music player have to know about the file? And why should it have access to the sound device? Just give it an input stream (with the file data) and an output stream (that goes to the sound system) without ever letting it know the sources for them. And why should the GUI have access to those streams? It should only be able to send messages to whatever is controlling the codec to let it know when to play/stop/seek/whatever and that's it. And why should the shuffle feature have access to anything more than just the list of songs? Etc. If you want to be really strict, each of those should be their own process completely isolated from each other.

That would probably be going a bit overboard. Out of all these, everything except for the codec is probably written by the same author and part of the same product. Separation into different processes is only required when a component having access to a set a resources needs to involve another component that the user doesn't trust with access to those same resources. A component can be untrusted because it is written by an untrustworthy author, or because it deals with untrusted data while not being proven to have no security holes. If it is okay for the codec to make the music player crash, or play a different song in the user's playlist from what the user intended, then it is okay to load it into the same process. On the other hand, if the music player is being set up to send those annoying "Now listening to" messages on IRC, it would probably not be funny if a random codec downloaded from a shady website suddenly decided to publicly claim that you're listening to something embarrassing.