Vulnerabilities
 
Operating Systems: How Good is Your System?

Everyone uses an Operating System.  Thus, security flaws in an operating system, especially a widely used one, have an immense impact on many users and many pieces of software.
 
CHOOSE an OPERATING SYSTEM.
If you are personally familiar with an Operating System other than Windows or Linux, please choose that one.  For example, if you have an Apple computer, choose that (perhaps macOS or iOS).
If you are familiar with Linux, beyond just what you learned with Hackbox and Devbox, please choose that one. 
If you are familiar with Windows, you may choose it, of course.  But I would like Apple and Linux represented in the class, if possible.
 
NOTE WHAT VERSION
Whatever the operating system, determine what version it is.
 
CHECK FOR VULNERABILITIES
Do a Web search.  Find security vulnerabilities for your OS.
For each one you find, briefly identify it.  Mention whether it has been fixed or not in your computer;
if it has not been fixed and a fix is possible, describe the fix;
if you know of a problem, and a fix is not possible, explain.
 
CONSIDER OPEN SOURCE versus CLOSED SOURCE
What are things that make an OPEN SOURCE OS [Linux] more vulnerable?
What are things that make an OPEN SOURCE OS[Linus] less vulnerable?
What are things that make an OPEN SOURCE OS [Windows] more vulnerable?
What are things that make an OPEN SOURCE OS[windows] less vulnerable?
 
CONSIDER: HOW ARE VULNERABLITIES FOUND?

 

Remember, among the things the OS can do are:
• examine or alter any process’s memory
• read, write, delete or corrupt any file on any writeable persistent storage medium, including hard disks and flash drives
• change the scheduling or even halt execution of any process
 • send any message to anywhere, including altered versions of those a process wished to send
 • enable or disable any peripheral device
We want to have:
• Confidentiality – If some piece of information is supposed to be hidden from others, don’t allow them to find it out. For example, you don’t want someone to learn what your credit card number is – you want that number kept confidential.
• Integrity – If some piece of information or component of a system is supposed to be in a particular state, don’t allow an adversary to change it. For example, if you’ve placed an online order for delivery of one pepperoni pizza, you don’t want a malicious prankster to change your order to 1000 anchovy pizzas. One important aspect of integrity is authenticity. It’s often important to be sure not only that information has not changed, but that it was created by a particular party and not by an adversary.
• Availability – If some information or service is supposed to be available for your own or others’ use, make sure an attacker cannot prevent its use. For example, if your business is having a big sale, you don’t want your competitors to be able to block off the streets around your store, preventing your customers from reaching you.
An important extra dimension of all three of these goals is that we want controlled sharing in our systems.

Principles for Designing a Secure System
1. Economy of mechanism – This basically means keep your system as small and simple as possible. Simple systems have fewer bugs and it’s easier to understand their behavior. If you don’t understand your system’s behavior, you’re not likely to know if it achieves its security goals.
2. Fail-safe defaults – Default to security, not insecurity. If policies can be set to determine the behavior of a system, have the default for those policies be more secure, not less.
3. Complete mediation – This is a security term meaning that you should check if an action to be performed meets security policies every single time the action is taken .
4. Open design – Assume your adversary knows every detail of your design. If the system can achieve its security goals anyway, you’re in good shape. This principle does not necessarily mean that you actually tell everyone all the details, but base your security on the assumption that the attacker has learned everything. He often has, in practice.
5. Separation of privilege – Require separate parties or credentials to perform critical actions. For example, two-factor authentication, where you use both a password and possession of a piece of hardware to determine identity, is more secure than using either one of those methods alone.
 6. Least privilege – Give a user or a process the minimum privileges required to perform the actions you wish to allow. The more privileges you give to a party, the greater the danger that they will abuse those privileges. Even if you are confident that the party is not malicious, if they make a mistake, an adversary can leverage their error to use their superfluous privileges in harmful ways.
7. Least common mechanism – For different users or processes, use separate data structures or mechanisms to handle them. For example, each process gets its own page table in a virtual memory system, ensuring that one process cannot access another’s pages.
8. Acceptability – A critical property not dear to the hearts of many programmers. If your users won’t use it, your system is worthless. Far too many promising secure systems have been abandoned because they asked too much of their users.
In most operating systems, processes access system services by making an explicit system call.
 
Attackers tend to be both smart and lazy.  That implies that attackers tend to go for the easiest possible way to overcome your system’s security. They’re not going to search for a zero-day buffer overflow if you’ve chosen “password” as your password to access the system. The practical implication for you is that you should spend most of the time you devote to securing your system to identifying and strengthening your weakest link. Your weakest link is the least protected part of your system, the one that’s easiest to attack, the one you can’t hide away or augment with some external security system. Often, a running system’s weakest link is actually its human users, not its software.