Look beyond the bells and whistles, and make sure the security’s tough.
OS makers: Security is job No. 1
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Linux/Unix already has some built in features you will see Longhorn add as default, such as getting granny off the admin account, firewall permissions will be more robust and browsers will be untangled from the OS..
Virtual Machining may be the future, I love VMWare and it’s snapshot idea..oops I got a virus..snapshot recover..walaa back to new..rinse…repeat
X
All I see is a gigantic ad for AMD.
/clicks though anyway
com.com.com.com going the way of IGN and other such ad-laden sites?
but I’m constantly told security is at the mercy of the clueless users, implying there’s nothing more than can be done to improve OS security.
Users need to have the ability to install software and modify the OS but programs should not. How do you let users do something that software cant? Simple.. provide software an API where they can ask permission to do certain things.
Programs should have to ask permission before they:
o install software on local disk
o modify firewall settings to let a port in
o install a system tray icon
o setup software to start on boot
o add quicklaunch/desktop icons
o read or modfy homepage and and bookmarks
o read or modify email address books
o open network connections
o create network services
These changes should be impossible for a piece of software to perform without making a call into an API that asks for permission first. There will be lots of fine tuning necessary to balance between pestering you and preventing unwanted activity but in the end we need this functionality.
You should be able to deny any request and have the software install not know about it. There could be a “pretend I allowed all actions” checkbox at the bottom so, for example, real player couldn’t forbid installation without modification of your homepage or adding a system tray icon.
The unix way of running non-privileged by default isn’t enough to solve this problem. Not being able to install software without root privileges means a software install script has root privileges and therefore could completely take over your machine changing things to work however it wants to.
Also.. just because software is running as a non-privileged user doesn’t mean it can’t do anything bad. They can still add desktop items, change homepages, add bookmarks, read your email address book and upload it across the internet. Asking permission seems like the best way of solving the problem.
Along with my previous post about popping up dialog boxes to ask for permission, there is another tool to solving this problem. It’s modified form of something that was mentioned before. By running software in a virtual machine (ala VMWare) you can eliminate it’s ability to do many unwanted things. This is very heavy handed though and doesn’t allow for allowing software to do certain things that you want it to be able to do.
A much lighter weight way to implement this is to sandbox an application. In unix this is mostly accomplished with a chroot jail. This concept could be refined so that an application has access to only those things that are specifically allowed by the OS’s environment. All file access could be restricted to a certain folder (ala chroot) and all access to OS API’s could be filtered so that, for example, a call to install a system tray icon would only succeed if the application was allowed to do that.
Java has used the concept of sandboxing with applets for years. Combining it with asking permission (to do things the sandbox doesn’t allow by default) could make for truely powerful controll over what an aplication can do on your machine.
New features and GUI enhancements will always be the front runner of any OS update. Security will always take second stage, that’s just how it is.
No matter how bad the security is . . . . the average use doesn’t really care, they just want something pretty.
Believe me, if the majority was voicing better security, it would be item number one. But it’s only the power users who are crying security, and we are the minority.
If you want security. Probably better than BSD. Definitely better than windows or linux.
http://jnode.sourceforge.net/portal/
Great article summary.
The java vm is only more secure because it doesn’t have access to your actual operating system.
If your operating system is the java vm then how is that more secure than anything else.
Aren’t buffer overflows the main target of hackers ?
Well then….
Those popup boxes could soon become a security nightmare. How long will it take before trojans just fire up a popup box saying “please enter the root password below”? An ignorant user (being used to this kind of popup boxes) will simply enter the root pw.
Yeah, I think the VMWare snapshot feature would be a great OS feature, I hate to reinstall Windows alle the time, would have been nice to just revert to latest snapshot.
—
http://bitsofnews.com Giving you the latest bits
And how do you imagine this would be implemented?
The key point is, how does the API know the “OK” answer was provided by the user and not some software posing as the user.
Actually, what _is_ the “user”, from the system’s point of view? For the OS, there are just processes. Some started by the user, some started by other processes. How do you discriminate, on read() level, that the “a” you see really comes from a keyboard and from from a pipe?
I understand what you imagine. I, however, fail to imagine, how to implement it.
Regardless of wether the new features in Longhorn actually help secure a home user, its giving the casual user peace of mind; a placebo to persuade someone to upgrade to Longhorn under the knowledge (false?) that it is more secure against those nasty evil hackers they keep hearing about.
Yes, there is much better methods Windows could use to secure a system but sadly the key feature that makes Windows popular is that its normally idiot proof – you start asking users to remember root passwords and permissions, before long said users will be locked out their own computers (and consequently phone tech support).
All commodity OSs suffer from the same fundamental problem – flawed security model. Briefly, privileges of an application are determined by the privileges of the user that is running the application. I have no way to forbid Microsoft Word to access any file that I can access. If Word has a virus or a security hole, my computer is at its mercy. What is sorely needed is a capability security OS: every piece of code runs under principle of least authority (POLA) and even if it is infected, it is unable to do harm. Web browser has no business installing software on my machine or writing to registry; Word has no business executing any code other than its own executable. This is not fantasy, it has been done (e.g. check KeyKos). But it has to be built into an OS from the ground up, it cannot be done by patching a system.
For this reason I think that the mode of thinking that says “security is a process, not a state” is wrong. We cannot expect that Microsoft will see the light, they just cannot afford to start an OS from scratch. The same goes for Linux, FreeBSD or any other mass-use operating system; this is not a matter of proprietary vs open source.
I believe this will eventually be done. Eventually capability security operating systems will prevail because they will be so superior that nobody will be able to afford to run anything else, and then the present state of affairs (“security is a process”) will be viewed as prehistory of computing.
[nxt]
> The key point is, how does the API know the “OK” answer was
> provided by the user and not some software posing as the
> user.
> Actually, what _is_ the “user”, from the system’s point of
> view?
The OS always knows who the user is, because he’s using the input devices. Any program can produce the string “ok”, but no program can pretend that the keyboard sends the sequence O,K.
[nxt]
> How do you discriminate, on read() level, that the “a”
> you see really comes from a keyboard and from from a
> pipe?
If that is necessary, you can tag user-input strings and program-generated strings differently. Obviously those tags must be unforgeable by a program, but languages like Java have implemented unforgeable tags quite effeciently.
[Geert Hendrickx]
> Those popup boxes could soon become a security nightmare.
> How long will it take before trojans just fire up a popup
> box saying “please enter the root password below”? An
> ignorant user (being used to this kind of popup boxes)
> will simply enter the root pw.
This is the main reason why I think the “popup box approach” won’t work. Unfortunately, the issue ranges much further than the root password. Users ould be asked for any information by a trojan, and most users would willingly enter that information.
[anon]
> I believe this will eventually be done. Eventually
> capability security operating systems will prevail because
> they will be so superior that nobody will be able to
> afford to run anything else, and then the present state of
> affairs (“security is a process”) will be viewed as
> prehistory of computing.
I have to agree here (except for the statement that capability security is the solution – I know too little about that to make my opinion). “security is a process” may very well describe the current situation, but it’s also a mantra that shields you from new ideas. And one thing is for sure: The average user expects security to be a product, not a process. This won’t change.
If that is necessary, you can tag user-input strings and program-generated strings differently. Obviously those tags must be unforgeable by a program, but languages like Java have implemented unforgeable tags quite effeciently.
Explanation accepted. Yes, that _is_ necessary, if you want to make sure a program only reacts to _user_ input and not to “user input faked by another program”.
The OS always knows who the user is, because he’s using the input devices. Any program can produce the string “ok”, but no program can pretend that the keyboard sends the sequence O,K.
The kernel can know, unless it decides to drop that info.
The point is in letting user-space processes know.
And, theoreticaly, the kernel knows that the keyboard has produced a certain scan-code. It might know, but also might not, how this scan-code will be translated (through keymaps) to a letter. Hence, if someone managed to change your keymaps, you still could get owned.
It does not seem completely easy, to differentiate between the user and a program trying to look like the user.