6 ms·

> The only practical security boundary for software as complex as Linux or Windows is physically separate hardware So because you can't really secure a linux k

• wahern 10y ago
  Using prepared SQL statements is about writing correct software. My point is that expecting containers to "secure" broken software is a delusion, especially when the implementation enforcing the constraints--in this case, the Linux kernel--is fundamentally broken from a security perspective in the relevant dimension (that is, local exploits leading to privilege escalation). Arguing defense in depth in this case is like arguing that stacking 3 web application firewalls on top of an application is better than just 1. The problem being that none of them are capable of addressing the bulk of the proven exploits. Back to your prepared SQL statement analogy, consider that nobody should be running software with root privileges today, regardless. Whether your network daemon is run in a container or not, it shouldn't being running as root in its steady state. So trying to lock down a container in such an instance is like trying to prevent SQL injection in software that concatenates data into the SQL statement string. It's intrinsically a failed strategy, and not in any sense an engineering solution. It's like saying doing something is better than doing nothing. Well, actually, in reality that's not the case; in reality sometimes doing something is just as bad as doing nothing (sometimes it's even worse, but that's not the argument I'm making here). There are other, similar reasons why it's a bad strategy to see containers as a security measure. And I fail to see how anybody who has spent any amount of time in this industry, and who has spent any amount of time applying privilege separation principles, could reasonably disagree. Now, can containers help you write more secure software? Yes, depending on context. But not to the exclusion of other techniques. Containers don't add a useful security layer by themselves, and shipping with slightly tighter capabilities doesn't change this fact in practice. Again, saying that shipping with slightly tighter capabilities (the particular capabilities system at issue here) is better than not is a distinction without a difference when most kernel-based root exploits are in innocuous system calls (e.g. networking system calls) that you could never lock down in a default container setting. If an application writer can't be bothered to make their software work without root, there are evidently other things going on.[1] Again, the problem in reality is software quality--bad kernel quality, bad application quality--and papering over this doesn't help. [1] A simple, single setuid call shortly after application startup would work at least as well as narrowing process capabilities, though likely be more effective. Even better, write your application to inherit socket and file descriptors so inetd or systemd can implement those privileged operations. These are minimal things all _correctly_ written software should support. If an application doesn't support at least the former, it's fundamentally broken and it's foolhardy to believe this can be papered over. Also, newsflash, systemd doesn't solve PID file races for uncooperative network daemons. That's another instance where people believed somebody came up with some magic software that inherently solved a problem without having to fix the underlying software. The difference being PID file races aren't a comparable security issue because they usually already require local, root capabilities; and systemd's solution arguably makes such a race meaningfully more difficult to exploit. So a misinformed engineer's decision in that context is unlikely to be part of a chain of events leading to billions of dollars of valuation going up in smoke.
  • hackits 10y ago
    As a side not I think your view is a bit too simplistic. For my own situation and I guess many other that most software packages assume some level or another root access and trying to manage all the hybrid of configuration files when you're deploying multiple web-frameworks on the same machine/vm can be a configuration nightmare. Put it more simply, yes to do it correct requires inspecting each and every web-tire solution, and its sockets, permissions, group permissions, and dependencies . This consumes a hell of a lot of time! The alternative is to throw the web-tire solutions or package in it's own container, and place monitoring software on the container to kill the container if things go wild or somebody figures out how to hack through the web-tire solution.
  • viraptor 10y ago
    Why would you use pid files when you've got systemd available? All the process management can be done directly with children or cgroups for some crazy runaway processes.
    • JdeBP 10y ago
      Or, more generally: > Why would you use PID files when you've got proper service management available? as of course the flawed PID file mechanism was addressed long before systemd was even an idea. cgroups do not solve the problem of "crazy runaway processes", by the way. cgroups are not jobs (in the Windows NT and VMS senses), and lack the functionality of a true job mechanism. When systemd terminates all of the processes in a cgroup, it doesn't issue a single "terminate job" system call. There isn't such a thing. It sits in a loop in application-mode code repeatedly scanning all of the process IDs in the cgroup (by re-reading a file full of PID numbers) and sending signals to new processes that it hasn't seen before. There are several problems with this. A first problem is that systemd can be slower than whatever is reaping child processes within the process group, leading to the termination signals being sent to completely the wrong process: one that just happened to re-use the same process ID in between systemd reading the cgroup's process list file and it actually getting around to sending signals to the list of processes. The order of events is: (1) systemd reads PID N from the cgroup's process ID list, then its timeslice happens to expire; (2) process N is scheduled and exits; (3) process N's reaper (its parent, or a sub-reaper) cleans up the zombie in the process table; (4) some vital part of the system is scheduled and spawns a new process re-using ID N; (5) systemd is finally scheduled, works down the list of PIDs that it read before, and merrily kills the new process. A second problem is that a program that forks new processes quickly enough within the cgroup can keep systemd spinning for a long time, in theory indefinitely as long as suitable "weather" prevails, as at each loop iteration there will be one more process to kill. Note that this does not have to be a fork bomb. It only has to fork enough that systemd sees at least one more new process ID in the cgroup every time that it runs its loop. A third problem is that systemd keeps process IDs of processes that it has already signalled in a set, to know which ones it won't try to send signals to again. It's possible that a process with ID N could be signalled, terminate, and be cleaned out of the process table by a reaper/parent; and then something within the cgroup fork a new process that is allocated the same process ID N once again. systemd will re-read the cgroup's process ID list, think that it has already signalled the new process, and not signal it at all. These are addressed by a true "job" mechanism. But cgroups are not such.
• marcosdumay 10y ago
  > Defence in depth. You know, nearly every time I hear that phrase, something bad follows. You are kind of an exception, that's not a bad set of protections, except that they are off-topic, and won't apply to container design. In practice real defense does not have depth. If you are in a position where you can apply a deep stack of protections, you've already lost.
  • TheDong 10y ago
    Only one of those doesn't apply actually! > run my processes as uid!=0, shouldn't use selinux You can automatically have your applications all run in usernamespaces (uid!=0) with containers. You can automatically apply selinux policies to all containers and then layer further contexts.
  • unethical_ban 10y ago
    Please, just please tell me you don't work in cyber security full time. That "if you can't secure it perfectly with one tool, you're doing it wrong/you've lost/etc." is so mind-bogglingly anti-security that if you are in charge of more than your home network for network security, that company has lost. That's like saying "If your application needs high availability instead of just being reliable, you've already lost." We secure networks by putting things on different VLANs. And putting them through firewalls that govern access between different parts of the network. And by enforcing user-based access control via the firewall ("next-gen" features) and then hopefully, at the application level. And for privileged systems, we are pushing to use two-factor authentication. I just listed off 6 different access controls for a given application. Hopefully, each one of those independently would secure the application pretty well. But the sum of all those make for a very well secured app, with no single point of failure.