From owner-freebsd-questions@FreeBSD.ORG Sat Feb 22 17:03:26 2014 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8E76865A for ; Sat, 22 Feb 2014 17:03:26 +0000 (UTC) Received: from mx01.qsc.de (mx01.qsc.de [213.148.129.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EDB581890 for ; Sat, 22 Feb 2014 17:03:25 +0000 (UTC) Received: from r56.edvax.de (port-92-195-11-141.dynamic.qsc.de [92.195.11.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPS id D5CCA3CCE7; Sat, 22 Feb 2014 18:03:17 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id s1MH2svo002160; Sat, 22 Feb 2014 18:02:54 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Sat, 22 Feb 2014 18:02:54 +0100 From: Polytropon To: Jeremiah Subject: Re: Idea to make package vulnerabilities not matter, along with third party software Message-Id: <20140222180254.a2d8a865.freebsd@edvax.de> In-Reply-To: <7934675E-6EAB-406A-90C4-61CDF901594F@yahoo.com> References: <7934675E-6EAB-406A-90C4-61CDF901594F@yahoo.com> Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "questions@freebsd.org" X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Polytropon List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 17:03:26 -0000 On Fri, 21 Feb 2014 23:36:11 -0600, Jeremiah wrote: > The basics behind the idea is simple. I was going to tell openbsd, > but they seem arrogant about security, whereas you all are honest... In my opinion, they are not arrogant, they just put very strong emphasize on security and the concepts they have in place to improve it. :-) > 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? Code made available in the ports collection is usually tested to run on FreeBSD, and certain patches perform the "adaption" for programs coming from Linux land. Of course, this does not prevent runtime errors. Programs that have known vulnerabilities are marked accordingly. They will be restricted, i. e. they cannot be installed until the vendor fixes the security problem. There's portaudit to help you find such programs easily. > 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... It's _very_ hard to catch those at runtime. Many programming languages allow you to do "strange things", even stupid things, simply because preventing you to do stupid things would also prevent you from doing clever things. Good and bad programs can be written in any language (whereas some languages are known for being the source where really really bad programs come from). > 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... Viruses are primarily existing on "Windows" platforms. :-) You're talking about memory protection? "Old stuff" since OS/MFT. FreeBSD contains such mechanisms, but as memory access can happen on different "levels" (user program, system library, kernel) there are different kinds of "access rights". > 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. No neccessarily. Let's just assume a program P allocates 1 MB of RAM. A kind of virus V (or whatever we want to call it) is part of the program or will be loaded by it (e. g. via HTTP resource). The code will be placed into that 1 MB chunk and execution will be handed over to it. Bang! Program V is running. > -you can validate data being passed into methods, for example > making sure they are the right data type and size This is a matter primarily of the programming language, because after compiling those things don't matter much anymore. Memory content gets some aligning, sure, but basically what remains are memory addresses and "lengths". Programming languages with static typing can help a lot here. Already at the compiler stage the correct passing of function arguments will be checked. Again, note that programming languages like C allow you to do "strange things" like type casting or pointer manipulation. > -you can protect files to a whitelist open function, where > only certain apps have access. This again is a feature of the file system. FreeBSD uses the UFS file system which contains standard permissions (user, group, world) and can also apply ACLs. Programs are bound to those permissions. But as soon as a program gets run with UID == 0 (runs as root, maximum privileges), permissions don't really matter anymore. > 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... That requirement is fully against the UNIX principle. And how would you do that on a server, a system where security is _very_ important? The server doesn't run a GUI. It doesn't even have a screen. Not even a graphics card. Modification by GUI means manual modification. That is very uncomfortable and inefficient. There is no way to automate tasks (except you can "remote-control" the GUI, which again is against your idea of "not through a script, program, or command"). Data _that_ important should not be kept in files which are accessed only via a GUI editor. They are so important that they should be part of the file system. Just imagine what happens if the file gets mangled or deleted - you cannot access anything anymore, your OS will crash. UFS keeps such information within the file system, but not as files: they are called meta-data, some of them are even kept in multiple copies. If you want to learn more about how advanced UFS is, read the FFS related articles by Marshall Kirk McKusick. > (The next one ties in). By doing this you eliminate payloads > of most malware Not neccessarily. It would be imaginable that malware uses approaches comparable to what it does on "Windows" to hide infront of virus software (which I hesitate to call "antivirus" for obvious reasons). > -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. FreeBSD offers differnt kinds of firewall machanisms. The ipfw firewall is "IP based", whereas pf is a packet filter. This way, "malicious network packets" can be identified before they reach a user program. > -you know by your packages already what filed, directories, > and sites they need access to. If the package in question is a web browser, it's hard to predict which site it will access. :-) > So there you have a big edge in that you can automatically > set these last two things up for the user. That would eliminate the requirement of a working brain for the user, which generally isn't a good idea. :-) > -the above stops the majority, but more needs to be done I hardly see this, but of course much more can be done. The biggest problem however, the PEBCAK, cannot be eliminated in most constellations. > -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. Checksum tests are usually performed when downloading a program binary or as a source archive. If the checksum does not verify, chances are high that the source has been compromized, and the installation won't continue. Using tools like mtree can be used to verify the "after installation status" as ports contain an exact description of which files are installed to where, which is important for later removal. The OS also performs periodic tasks (usually at 3 o'clock in the night) to check for suspicious changes, for example, if a new program has suddenly got "run with UID 0" permissions. > -most viruses steal information. Not neccessarily. Established kinds of malware encrypt everything they can find, and then present a friendly GUI wizard for the user to transfer bitcoins if he wants his data back. This kind is called ransomware. Stealing information (usually _copying_, because the source often stays where it is) is an important topic today. The best OS concepts cannot help if users give their data to malware without using their brains. However, FreeBSD has lots of security concepts in place, starting from networking access, file permissions, access to mass storage devices and finally packet inspection. In the field of malware, scareware, trojans, ransomware and viruses, many "applications" (kinds of use) can be imagined. It starts by malware hiding in the background, making the "Windows" PC part of a botnet to send spam, continues to software that captures magnetic card data and PINs at the local supermarket, and doesn't even end at software that accesses camera and microphone of a laptop that the guy with the tie took to the secret and imporant meeting where the offers and the calculations will be discussed. > 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). FreeBSD has ELF, not EXE. :-) To run a program on FreeBSD, there are requirements that need to be met: executable bit set, permissions and so on. Probably you've also noticed one of the "modern ways" of how software is installed nowadays: $ curl http://get.example.com/install.sh | sudo bash This pattern has been emerging in the last few years and should be discouraged. But it's "too easy", so it becomes very convenient, and generally people don't care. This attitude can even be found among the technology-savvy and security-aware users of Linux and Mac OS X. Given the command above, you can surely spot many problems, such has "http" (nothing encrypted, MITM possible) and "sudo bash" (all the permissions). On FreeBSD, it's common to install software through system means, using the package management that has security checks in place to prevent modification of what will be executed after the download. > 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. As I said, the GUI idea is a really bad idea. Limiting file system and network access in _that_ way and requiring manual interaction with a GUI would make program installation a pain. And _who_ knows what all the things are, anyway? Have you recently installed a program and made it through the "make config-recursive" screens? You actually need to have a second system available to find out what Nepomuk, Bonobo, Avahi, Orbit... and Shlorts and all those are (and why you're going to need them). :-) > That will mitigate the vast majority of risks. Not sure about that... > -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... Tools like dtrace can do exactly that. So you would have to run your programs under permanent dtrace control and have the output parsed "in real-time" to check for malicious patterns. I'm not sure how many false-positives one would get by running complex applications like a fullblown desktop environment. > -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. Again, it would be required to monitor the file, save its content for reference, and check all outgoing connections (network) or writes (file system) of the program to see if the content matches. But when the content gets scrambled or encryptet, this task gets harder. > 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... As a programmer, I sometimes find the lack of documentation on Linux disturbing. FreeBSD developers put much work in creating quality source code which includes proper documentation (for example man pages). There's also much more fragmentation there (but that's not a problem, it's a property by concept). > 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. Patent of swinging on a swing? :-) Most security concepts in FreeBSD are openly documented and released under the permissive license of the BSD license. I don't know how much of that has been printed into patents, given the fact that unknown masses of manufacturers are putting BSD into their routers, firewalls, modems, NAS or whatever, and we don't know about it. But as I said, the licensing terms allow this kind of usage. > 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. I think with FreeBSD (or the BSDs in general, especially OpenBSD) you already have a very good foundation for a secure system. But keep one thing in mind: Security is not a state, it's a process. It involves you as much as it involves others. And a healthy common sense is the most important part of this conglomerate. Most malware around targets the "market leader", which is "Windows". FreeBSD does not participate because most of the stuff simply doesn't run out of the box, which is a good thing. Now go ahead and open INVOICE.XLS.EXE. Trust it! It's very important! ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...