Idea to make package vulnerabilities not matter, along with third party software

Jeremiah jeremiah.twidwell at
Sat Feb 22 05:38:18 UTC 2014

The basics behind the idea is simple. I was going to tell openbsd, but they seem arrogant about security, whereas you all are honest...

You can control your os, but you can't control vulnerabilities in third party packages or software, and you end up patching it all for them - or can you simply make it not matter?

Actually, you can. Most viruses require some form of vulnerability (also hacking) to spread. The objective then for the operating system is to catch those things in action and throw an error...

For example, consider buffer overflows. What do they all have in common?  Some other process or dynamic library is accessing the memory spaces of processes it shouldn't access. So all you need to do to limit most viruses is to run with that idea...

It's access control, only on processes instead of the user. As examples of what you can do with program acess control:

-prevents memory problem vulnerabilities by maintaining a mapping of what process creates and allocates, and so 'owns' segments or ram, heaps, pointers, etc. all those vulnerabilities gone with just that one thing. 

-you can validate data being passed into methods, for example making sure they are the right data type and size

-you can protect files to a whitelist open function, where only certain apps have access. This gets easy by using a config file, which cannot be accessed by anything except the os, and further it can only be modified by a GUI editor, not through a script, program, or command... (The next one ties in). By doing this you eliminate payloads of most malware

-you can do the same access control as files with processes accessing the Internet. Back doors by themselves do not have a payload, but if you all do this right, a new firewall protecting process instead of ports with a whitelist/blackist is a much better firewall anyway. 

-you know by your packages already what filed, directories, and sites they need access to. So there you have a big edge in that you can automatically set these last two things up for the user. 

-the above stops the majority, but more needs to be done

-viruses spread. Memory residency doesn't matter if it can't attach to anything, which we may have already solved above. To know if a virus has infected a package, if that package changed since its last install/update that is a dead give-away. You could also checksum it before it runs and compare with either a local file or your server. 

-most viruses steal information. By default any program or executable (unless it was compiled by the user - but that doesn't mean you can't ac the file name as an exe, etc). So by default anything you don't know in packages or ports has no file or network access, and further if it can't execute something except a GUI, the user will be pretty suspicious. That will mitigate the vast majority of risks. 

-for hacking, a similar method can be employed. Basically what you have to do is you should know the socket, program, or is does something unique to make a socket blow up into a root shell; for example. So what you do is if you can just catch that event(s), you've stopped hacking almost completely. But it's going to take a lot of memory and sys analysis...

-now all that is left is what to do about applications that should have access to a file, but shouldn't be transmitting any of that data. That's the tough one, but I'll leave it to you to see what you can come up with. 

I had these ideas ever since 2005. I was going to do it on Linux at first; but honestly that platform is a free for all and bad is more suitable. I thought you all should be the ones...

If it works well, patent immediately. If not, maybe it needs a little refinement. I haven't tested any of it, but the theory should hold. 

If you need me to provide more information or explain further just let me know. I need a secure os at least, would be nice if you folks could do this. 

Later, man. 

- Jeremiah

More information about the freebsd-questions mailing list