Tuesday, August 19, 2008

Slackware 12.0 - Safety Part 1: expectations

high expectations, low knowledge, under-equipped


We typical home pc users combine our computer security system, end-user applications, and our critical data into a single box. Further, we design this arrangement without IT or programming experience. How effective do you believe such a security arrangement is likely to be?

Accordingly, seen in security terms, our home computer systems are an "opportunity". In large organizations, well-paid IT professionals design layers of dedicated security systems to protect workstation computer networks and data is backed up and retained elsewhere. Since we don't have that option, let's at least think about our configuration.

situational awareness - threats


Given that our home systems present opportunities, are there threats which seek to take advantage of them? First, it appears one may assume governments, US or otherwise, can easily penetrate our leaky home systems, and perhaps they do so regularly. It's also likely a large number of civilian entities penetrate our home computer systems. Given the opportunity and the threat, and our typical lack of resources to build a $3-5K layered and ported system, about all we can do is make ourselves a less inviting target than other home machines out there. Let's suppose here we're going to make the effort, where do we begin?

step one - no security


Linux security features sometimes function like shells around processes, sometimes around files, sometimes around ports, sometimes around data streams, sometimes around other things. The security system is complex. The dedicated security servers of the corporate world do this more easily since they operate with firmware or static-linked libraries and have no other applications or data to interfere. But we want applications and data on our home systems. This means we're bound to have permission or authentication problems when we configure complex security functions around desktop applications and web interfaces. Accordingly, I have one rule for a home system prior to activating iptables.chains,tripwire,ssh, really any security function - the system has to work exactly the way it's supposed to work before the security is implemented, and hopefully before it's connected to any network. If we don't have desktop functionality first, is the permission problem we see when activating security related to the security configuration or is it due to the user configuration? We have no way to cut the problem in half. Alternatively, we could bring up our security half before the desktop operations half, but this means we would have to estimate user applications in advance. So the first step of (home) security is to configure the desktop system to run reliably, including all it's peripherals of printers, scanners, cameras, audio inputs, and so on. Subsequently, we will activate our security and the net packages together, and adjust the mix when a desktop application ceases to work due to security layers. Ideally, we should test system applications after adding each security layer.

No comments: