3 ms·

old way: one chroot per user and quota (including ulimit) per user new way: limits handled with cgroups security with namespace related to user's profile. nam

by SFJulie 10y ago

old way: one chroot per user and quota (including ulimit) per user new way: limits handled with cgroups security with namespace related to user's profile. namespace can do syscall limitations, and also offer unique network access per users. Roughly simplified. freebsd jails where known as glass jails that would eventually break, LXC/docker are the same except they hav'nt broke yet at the price of more complexity. They will all dramatically break when people will have figured the trick in 5 years. Simple solution : understand the problem and fix it. Actual solution: throw more complexity and obfuscation at the problem claiming users are THE problem. Companies and devops don't care, they have a future of at least 10 years in fat paychecks and stock options.

koffiezet 10y ago
> They will all dramatically break when people will have figured the trick in 5 years. VM's hypervisors have also seen bugs/exploits to gain hypervisor access, and yet they're still here. These things have been fixed, and people did not stop using them. Also, I don't really see the "more complexity and obfuscation" thrown at "the problem", can you enlighten me?
- SFJulie 10y ago
  Old ways: you trust a person. And You check. New ways: you create very complex sets of syscalls permissions that can be fine tuned by using a Role Based Accounting or any Auth/Profile Framework. The idea is that you got rid of the risk of mischief/compromission by containing the code and people by delegating trust to external stuff : companies, datacenters, external servers, an OS you don't own. But for delegating you use software to delegate en masse :) However, now, your surface of attack is so big that it's impossible to do a full audit of your perimeter. And people focus on code/practices/network. You have delegated a lot. For the sake of discussion what can be the next cost efficient approach for attack with that much smoke? The downside of containers is the physical geographical increase of the perimeter to defend, and for SV to develop their beautiful code, a lot of workers (cleaning personal, transporter, electricians, construction workers, firemen) that are required in the physical world and are so impoverished that they are becoming a vulnerability. Keep It simple, always attack where the costs are less. Bribing a man today to access a physically a server, a router is less expensive than writing an exploit. The obvious problem in the containers is the idea you can trust layers you should not. Maybe, your container runs in a datacenter where a worker infected a printer with a connected cam from home because he is to poor to afford a printer? Maybe from there you can compromise a router, and have a MITM on a VLAN used between 2 servers? Who knows? But how can you know if you cannot check?

by SFJulie 10y ago

koffiezet 10y ago

> They will all dramatically break when people will have figured the trick in 5 years. VM's hypervisors have also seen bugs/exploits to gain hypervisor access, and yet they're still here. These things have been fixed, and people did not stop using them. Also, I don't really see the "more complexity and obfuscation" thrown at "the problem", can you enlighten me?

SFJulie 10y ago
Old ways: you trust a person. And You check. New ways: you create very complex sets of syscalls permissions that can be fine tuned by using a Role Based Accounting or any Auth/Profile Framework. The idea is that you got rid of the risk of mischief/compromission by containing the code and people by delegating trust to external stuff : companies, datacenters, external servers, an OS you don't own. But for delegating you use software to delegate en masse :) However, now, your surface of attack is so big that it's impossible to do a full audit of your perimeter. And people focus on code/practices/network. You have delegated a lot. For the sake of discussion what can be the next cost efficient approach for attack with that much smoke? The downside of containers is the physical geographical increase of the perimeter to defend, and for SV to develop their beautiful code, a lot of workers (cleaning personal, transporter, electricians, construction workers, firemen) that are required in the physical world and are so impoverished that they are becoming a vulnerability. Keep It simple, always attack where the costs are less. Bribing a man today to access a physically a server, a router is less expensive than writing an exploit. The obvious problem in the containers is the idea you can trust layers you should not. Maybe, your container runs in a datacenter where a worker infected a printer with a connected cam from home because he is to poor to afford a printer? Maybe from there you can compromise a router, and have a MITM on a VLAN used between 2 servers? Who knows? But how can you know if you cannot check?