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

[Polytropon]

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, ...