Date: Fri, 21 Feb 2014 23:36:11 -0600 From: Jeremiah <jeremiah.twidwell@yahoo.com> To: "questions@freebsd.org" <questions@freebsd.org> Subject: Idea to make package vulnerabilities not matter, along with third party software Message-ID: <7934675E-6EAB-406A-90C4-61CDF901594F@yahoo.com>
next in thread | raw e-mail | index | archive | help
The basics behind the idea is simple. I was going to tell openbsd, but they s= eem arrogant about security, whereas you all are honest... You can control your os, but you can't control vulnerabilities in third part= y 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 hac= king) to spread. The objective then for the operating system is to catch tho= se things in action and throw an error... For example, consider buffer overflows. What do they all have in common? So= me other process or dynamic library is accessing the memory spaces of proces= ses it shouldn't access. So all you need to do to limit most viruses is to r= un with that idea... It's access control, only on processes instead of the user. As examples of w= hat you can do with program acess control: -prevents memory problem vulnerabilities by maintaining a mapping of what pr= ocess creates and allocates, and so 'owns' segments or ram, heaps, pointers,= etc. all those vulnerabilities gone with just that one thing.=20 -you can validate data being passed into methods, for example making sure th= ey 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 accesse= d by anything except the os, and further it can only be modified by a GUI ed= itor, not through a script, program, or command... (The next one ties in). B= y doing this you eliminate payloads of most malware -you can do the same access control as files with processes accessing the In= ternet. Back doors by themselves do not have a payload, but if you all do th= is right, a new firewall protecting process instead of ports with a whitelis= t/blackist is a much better firewall anyway.=20 -you know by your packages already what filed, directories, and sites they n= eed access to. So there you have a big edge in that you can automatically se= t these last two things up for the user.=20 -the above stops the majority, but more needs to be done -viruses spread. Memory residency doesn't matter if it can't attach to anyth= ing, 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 d= ead give-away. You could also checksum it before it runs and compare with ei= ther a local file or your server.=20 -most viruses steal information. By default any program or executable (unles= s it was compiled by the user - but that doesn't mean you can't ac the file n= ame as an exe, etc). So by default anything you don't know in packages or po= rts 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 va= st majority of risks.=20 -for hacking, a similar method can be employed. Basically what you have to d= o is you should know the socket, program, or is does something unique to mak= e a socket blow up into a root shell; for example. So what you do is if you c= an just catch that event(s), you've stopped hacking almost completely. But i= t'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 acce= ss to a file, but shouldn't be transmitting any of that data. That's the tou= gh one, but I'll leave it to you to see what you can come up with.=20 I had these ideas ever since 2005. I was going to do it on Linux at first; b= ut honestly that platform is a free for all and bad is more suitable. I thou= ght you all should be the ones... If it works well, patent immediately. If not, maybe it needs a little refine= ment. I haven't tested any of it, but the theory should hold.=20 If you need me to provide more information or explain further just let me kn= ow. I need a secure os at least, would be nice if you folks could do this.=20= Later, man.=20 - Jeremiah=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7934675E-6EAB-406A-90C4-61CDF901594F>