| pappy- | Greetings |
| trulux | hi all, me and pappy are going to talk a relatively new project called Hardened Debian |
| trulux | started in a few months ago, it aims to improve several security-related enhancements for Debian and Debian-based distributions |
| trulux | also it aims to make collaboration, simplicity and good work the philosophy of the project |
| trulux | we can find more information about the project at http://www.debian-hardened.org |
| trulux | the slides for the talk are located at http://www.debian-hardened.org/papers/hardened-debian-en-2005/ |
| trulux | for those who don't have broadband connections a PDF document has made available at http://www.debian-hardened.org/papers/hardened-debian-2005-en.pdf |
| trulux | so, let's start |
| trulux | we are going to introduce ourselves |
| trulux | i'm Lorenzo Hernández Garcia-Hierro, from Spain, my age doesn't matter really but i'm young.I'm the head developer and project manager of Hardened Debian since the project started.I have a bit of experience in GNU/Linux security frameworks and solutions but i'm not an expert. |
| trulux | i just hope i can learn from others and also teach hat i already know |
| trulux | pappy-, let's introduce yourself please, i know you like this part ;-) |
| pappy- | Good evening, my name is Alexander Gabert and i was responsible for integrating the hardened PIE SSP toolchain in the Gentoo Hardened project of Gentoo Linux. |
| pappy- | I am located in germany and are currently at a university in Trier, near Luxembourg. |
| pappy- | Thats all, the rest is just boring details about my work. |
| pappy- | :-) |
| trulux | heh, ok, after this introduction, the talk starts |
| trulux | (switch to second slide) |
| trulux | Debian as a trusted, secure environment <- |
| trulux | As we said, our main goal is to make Debian and it's derivated works really more secure |
| trulux | our main target is changing now to Ubuntu Hoary, until Sarge gets released as stable Debian wouldn't accept us as official sub project |
| trulux | also, our philosophy sometimes differ from Debian developers' one, we like often to make things quickly, stress testing and then fast releases |
| trulux | not the releasing times common of Debian |
| trulux | also a bit of kamikaze work to get things working as well asspossible |
| trulux | s/assposible/as posible/ |
| trulux | one of the things that need to be done for this is to make developers following a development model that guarentees the security |
| trulux | let me explain this: |
| trulux | Upstreams, the developers which make the software (not the packagers), must take care of they're work |
| trulux | respect the full-disclosure, having collaboration and security in mind |
| trulux | we submit bug reports and so on for those bugs which are related with specific upstream issues: a problem in XYZ software which makes us unable to use PaX with it |
| pappy- | But, to keep the things working for the users of the distribution, we are incorporating a "value added" toolchain that keeps things "security oriented" and tries to introduce an additional kind of "in-depth" defensive layer. |
| trulux | PaX is a kernel-level security enhancement which implements the NX bit on memory pages |
| trulux | pappy-, right |
| pappy- | ACTION nods |
| trulux | pappy, explain us what a hardened toolchain means |
| pappy- | A hardened toolchain is a piece of software that will not guarantee "total security" but rather "raise the bar" for attackers. |
| pappy- | As trulux noted, we need support from upstream maintainers and source developers to adhere to proper mechanisms of code auditing, code improvement and security orientation. |
| pappy- | There is no way around this. |
| pappy- | But we have a technical choice. |
| pappy- | We can "arm" our executables with SSP, which is a stack smashing protection i will go into detail about later, and make them look randomized to an attacker via PIE, that is process randomization which i will explain now. |
| trulux | yeah, let's explain about PaX and ASLR (Adress Space Layout Randomization) |
| pappy- | When an attacker tries to intrude into a PaX protected machine, she or he has little chances to find a writable segment in the running process that can be abused for introducing and executing code. |
| pappy- | this is, as trulux' slides show, due to the linker |
| pappy- | sorry, phone |
| trulux | ok, i will continue a bit |
| pappy- | trulux: i can go on |
| trulux | ok |
| pappy- | just hang up and cut it short. |
| pappy- | well |
| pappy- | the linker sets up the segments to "pair together" readonly executable pages |
| pappy- | in memory |
| pappy- | so, the attacker has writable segments (like stack and heap) but cannot execute code any more |
| pappy- | however, there is a pitfall |
| pappy- | due to the stack layout on hardware, critical data is stored there that can be abused for changing execution flow |
| pappy- | well |
| pappy- | then the attacker tries to introduce a "return to glibc" attack which will alter a return address on the stack |
| pappy- | and this is where position independence, or randomziaton, comes into play |
| pappy- | sorry, randomization that is. |
| trulux | yes, and there's no way than that one to prevent so-called ret2libc exploits, not as open source/free software solutions |
| pappy- | so when we have position independent executables that are getting randomized by the pax kernel, we can prevent those attacks by suppressing critical information that is necessary for succeeding. |
| pappy- | next is SSP |
| trulux | right, after i will introduce the SbD/Proactive security concept |
| pappy- | given the problems with return2libc, we can install an additional countermeasure to make overwriting the stack harder. |
| pappy- | overwriting the stack will mean introducing complete new stack frames, which means new return addresses, stack pointers and frame pointers (all of which is saved on a hardware stack on a stack machina) |
| pappy- | so |
| pappy- | SSP is placing a little "canary" on the right position on the stack frame segment |
| pappy- | and after the function has done its work, the gcc has added, when compiling, a little "epilogue" attachment to the function |
| trulux | pappy-, explian the canary concept an also the terminator canary one |
| pappy- | which compares the placed canary (named after the canary in coal mines to detect early gas alert) to a "safe" location in either glibc, libgcc or libssp |
| trulux | as we are going to see later, libssp is our implementation of SSP/ProPolice |
| pappy- | so, trulux will explain and keep it on. |
| pappy- | have fun and see you |
| pappy- | :-) |
| trulux | kay, we were talking about the hardened toolchain |
| trulux | as pappy- said, SSP adds an "attachment" that is checked for stack smashing after main() gets executed |
| trulux | it's also a random canary |
| trulux | which introduces the concept of random allocation of the canary address |
| trulux | also as a enhancement to prevent it to get overwritten |
| trulux | More information can be found at http://en.wikipedia.org/wiki/Stack-Smashing_Protector |
| trulux | Also, for those interested in how canaries work, they are encouraged to read http://en.wikipedia.org/wiki/Stack-smashing_protection |
| trulux | These articles were written by a project member, John Richard Mosser |
| trulux | now we are going to see how SSP/ProPolice can be implemented, and the different possibilities to do it |
| trulux | A little summary can be found at http://wiki.debian-hardened.org/SSP/ProPolice_Implementations |
| trulux | As a little introduction for that, we need to know how SSP started, and how it was implemented by the different projects like Hardened Gentoo, Adamantix and finally Hardened Debian |
| trulux |
|
| trulux | PaX protects the memory by making pages not executable and writable in the same time |
| trulux | so, it protects any attack which needs to execute code on a writable page |
| trulux | btw, rjc has done a great job on getting SELinux inside Debian, maybe he could talk when we get in that point |
| trulux | so, first implementation of SSP was inside libgcc |
| trulux | libgcc is the GCC library which gives the most important symbols for the compiler |
| trulux | it's a crappy implementation, it's not as usable as others and it also creates conflicts when / is in diff partition than /usr/lib |
| trulux | it also makes compatibility issues |
| trulux | when you update your GCC packages or simply symbols get dropped or position changed (ie: moved to Glibc) your binaries compiled with SSP wouldn't run anymore |
| trulux | giving __guard symbol errors over there and there |
| trulux | this is the way as Adamantix (http://www.adamantix.org) implemented SSP |
| trulux | and it's also the default implementationas it comes from the IBM patches |
| trulux | now we are going to talk about Hardened Gentoo implementation |
| trulux | pappy-, when he was developing there, made a Glibc-based implementation of SSP |
| trulux | but later he got disgusted about it |
| trulux | let's see the reasons: |
| trulux | - it's an important change to Glibc |
| trulux | - it needs mainly the dl_execstack stuff which is not in 2.3.2 (or in debian version indeed) |
| trulux | - it's crappy as libgcc, even more |
| trulux | if you update the glibc you will have problems with binaries compiled with SSP in glibc |
| trulux | as a first test, Hardened Debian made a hardened glibc (i'm currently the guy in charge of it) |
| trulux | which hasn't any good results as the debian packaging never happened |
| trulux | see: http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/glibc-dh/libc/ |
| trulux | also, after a little research and after i met pappy for first time, we decided to use a new way to implement SSP |
| trulux | libssp |
| trulux | or SSP/ProPolice as s shared library |
| trulux | it's main benefits are: |
| trulux | - backwards compatibility |
| trulux | (with SSP inside LIBC) |
| trulux | - only ssp needs to be recompiled to update ssp code |
| trulux | - support for strange, unusual configuration of partitions |
| trulux | it was simple, we added a few enhancements to make it using the symbols as we configured in compile time: |
| trulux | _LIBC_PROVIDES_SSP_ and _LIBSSP_PROVIDES_SSP_ |
| trulux | just a bit of tweak inside libgcc1 Makefile.in and then we had a non agressive implementation of SSP |
| unizar.es.uninet.edu MODE #linux +o AfC | |
| trulux | now we are going to see the concept of Proactive Security |
| trulux | one of our main goals was providing a system Secure by Default |
| trulux | which means, "bulletproof" in default configuration |
| trulux | to test this i'm going to show a good example using a realistic environment |
| trulux | switch to slide 3 |
| trulux | Proof of the Proactive Security Concept (I) |
| trulux | An enterprise is using a simple program to manage employees inside a database |
| trulux | it's called employee2 |
| trulux | it uses simple authentication, based on the free rfc-respecting md5 implementation |
| trulux | it gets a string from argv[1] and saves it inside a 512 bytes limited buffer with the insecure strcpy() call |
| trulux | without checking if argv[1] is longer than 512 bytes |
| trulux | then it makes a md5 hash of the string and strcmp()'s with a compiled-in one |
| trulux | ACTION chroots sarge environment to show the real life demo |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ ./employee2 |
| trulux | - No password provided for authentication. |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ ./employee2 l33t_b0ss |
| trulux | (!) Logged in. |
| trulux | ===========ACME Inc. Employees============= |
| trulux | A: Add an employee to the database |
| trulux | D: Display employee information |
| trulux | L: List employees |
| trulux | M: Load Database |
| trulux | R: Raise the salary of an employee |
| trulux | S: Save Database |
| trulux | X: Exit |
| trulux | Your choice: |
| trulux | Your choice: A |
| trulux | Enter the employee's full name: Foo |
| trulux | Enter the employee's job title: Ish |
| trulux | Enter the employee's salary: 50 |
| trulux | Foo added to database! |
| trulux | right |
| trulux | let's introduce DeadBeef (don't ask me for the name, he just dislikes it) |
| trulux | deadbeef is one of the employees, he's upset with the human resources boss |
| trulux | he gets sadly a small salary, he's work conditions are crap and also he dislikes to go over there and fix that crap stuff everyday |
| trulux | after a little research and also getting help from one of the coding guys, he knows there's a stack smashing vulnerability in employee2 |
| trulux | the only one vulnerable parameter (in the terms that he can see) is the passwd string provided by argv[1] |
| trulux | so, he thinks that the problem is there |
| trulux | he's right |
| trulux | key, he makes a further research: |
| trulux | employee2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped |
| trulux | nice, he can debug it |
| trulux | he also notes a hash string in the text strings inside employee2 |
| trulux | 6a3649f2caa1602c52252f336c43a6cc |
| trulux | nothing strange and that's not the thing he's looking for |
| trulux | then he notes that employee2 has the setuid bit enabled |
| trulux | so, he makes a further research on it |
| trulux | the vulnerable code looks as follows: |
| unizar.es.uninet.edu MODE #linux +o fernand0 | |
| trulux | int main(int argc, char *argv[]) |
| trulux | { |
| trulux | /* Some-type of lame authentication, but works! */ |
| trulux | char userpbuffer[512]; |
| trulux | md5_state_t state; |
| trulux | md5_byte_t digest[16]; |
| trulux | char hex_output[16*2 + 1]; |
| trulux | int di; |
| trulux | char *password = "6a3649f2caa1602c52252f336c43a6cc"; /* l33t_b0ss */ |
| trulux | if (argc > 1) { |
| trulux | strcpy(userpbuffer, argv[1]); |
| trulux | md5_init(&state); |
| trulux | md5_append(&state, (const md5_byte_t *)userpbuffer, strlen(userpbuffer)); |
| trulux | md5_finish(&state, digest); |
| trulux | for (di = 0; di < 16; ++di) |
| trulux | sprintf(hex_output + di * 2, "%02x", digest[di]); |
| trulux | /* compare password hashes */ |
| trulux | if (!strcmp(password, hex_output)) |
| trulux | (sorry of the flood, but better than pasting it at rafb) |
| trulux | strcpy(userpbuffer, argv[1]); <- strcpy() call against userpbuffer and argv[1] |
| trulux | char userpbuffer[512]; <- limited buffer -> vulnerable buffer |
| trulux | deadbeef, after having a look on many so-called security and exploit sites finds Aleph1's article on Phrack |
| trulux | http://www.phrack.org/phrack/49/P49-14 |
| trulux | Smashing the Stack for Fun and Profit |
| trulux | (nice one for those who want to understand the bof concept, btw ;D) |
| trulux | het gets the code of the shellcode egg "cooker" |
| trulux | it simply gets an offset to return the shellcode and a buffer size, oversize by 100 bytes |
| trulux | so, as b size we have 612 bytes and as offset we must do some gdb-fu |
| trulux | let's see |
| trulux | ACTION gets gdb (yes, i don't have it in this chroot) |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ gdb employee2 |
| trulux | (gdb) disassemble main |
| trulux | Dump of assembler code for function main: |
| trulux |
0x00000a84 |
| trulux |
0x00000a85 |
| trulux |
0x00000a87 |
| trulux |
0x00000a88 |
| trulux |
0x00000a8e |
| trulux |
0x00000a93 |
| trulux |
0x00000a99 |
| trulux | key, we see that it sets the frame pointer and allocates some stack space |
| trulux | that code is just helpful to trace the memory usage and try to guess the magic offset where we must return the shellcode |
| trulux | a few lines below... |
| trulux |
0x00000a9c |
| trulux |
0x00000aa1 |
| trulux |
0x00000aa3 |
| trulux |
0x00000aa9 |
| trulux |
0x00000aaf |
| trulux |
0x00000ab3 |
| trulux |
jle 0xbc1 |
| trulux | we can have a look in the assembler code of employee2, because we have the source |
| trulux | (deadbeef sadly does not and guesses the offset alone) |
| trulux | main: |
| trulux | pushl %ebp |
| trulux | movl %esp, %ebp |
| trulux | pushl %ebx |
| trulux | subl $724, %esp |
| trulux | call __i686.get_pc_thunk.bx |
| trulux | addl $_GLOBAL_OFFSET_TABLE_, %ebx |
| trulux | (...) |
| trulux | movl (%eax), %eax |
| trulux | movl %eax, 4(%esp) |
| trulux | leal -520(%ebp), %eax |
| trulux | movl %eax, (%esp) |
| trulux | call strcpy@PLT |
| trulux | leal -616(%ebp), %eax |
| trulux | movl %eax, (%esp) |
| trulux | call md5_init@PLT |
| trulux | call strcpy@PLT <- here our string gets strcpy()'ed in userpbuffer |
| trulux | ok, this is getting a bit heavy, most of this stuff is boring+ |
| trulux | let's go forward to the end: |
| trulux | he sues fun1 to prepare the shellcode and turns on a subshell: |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ ./breakfast 612 317 |
| trulux | + Using address: 0xbffff6cb |
| trulux | + Entering a subshell...Enjoy your egg ;-) |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ ./employee2 $EGG |
| trulux | - Wrong password! |
| trulux | and after that a root (#) shell spawns |
| trulux | game over |
| trulux | now see what happens when it gets compiled with SSP: |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ gcc employee2.c -fstack-protector -lssp -lm md5.c -o employee2 |
| trulux | /tmp/ccMeHfij.o(.text+0x203): En la función `.L10': |
| trulux | employee2.c: warning: the `gets' function is dangerous and should not be used. |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ ./breakfast 612 317 |
| trulux | + Using address: 0xbffff6cb |
| trulux | + Entering a subshell...Enjoy your egg ;-) |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ ./employee2 $EGG |
| trulux | - Wrong password! |
| trulux | employee2: stack smashing attack in function main() |
| trulux | - main=0x80002848 __guard_setup=0x4001baf0 __guard=0x2e812ab5 ppid=24082 pid=24094 uid=1000 euid=1000 gid=1000 egid=1000 - |
| trulux | Abortado |
| trulux | lorenzo@estila:~/LIBSSP/tests/employee-0.1$ |
| trulux | SSP stopped the attack without divine nor developers intervention |
| trulux | this means Proactive Security |
| trulux | stopping attacks which we don't really know |
| trulux | but we just know they follow a similar pattern |
| trulux | ok |
| trulux | now it's time to talk about the protectionlayers |
| trulux | slide 7 |
| trulux | switch to Protection layers |
| trulux | we have here rjc, a person who has done a great job with SELinux |
| trulux | rjc, hi |
| rjc | hi |
| trulux | Russell, can you introduce yourself? |
| rjc | I've been a Debian Developer for 4-5 years. I started working on SE Linux after OLS 2001 when I atteneded Pete Loscocco's talk. |
| trulux | rjc, as we can see in the protection layers diagram (http://www.debian-hardened.org/papers/hardened-debian-en-2005/img7.png), there are some attack vectors that can be prevented and blocked with already available technologies |
| trulux | one of them , and one of the most important is SELinux |
| rjc | SE Linux is a system for MAC (Mandatory Access Control) based on the LSM (Linux Security Modules) interface. At a kernel summit the NSA and several other groups showed Linus information on their GPL MAC systems for Linux. Linus didn't like the idea of being forced to choose so he insisted that they develop a common interface. LSM was the result, but so far only SE Linux has adopted LSM so SE Linux is the only MAC system in the kernel.or |
| rjc | For over a year now I've been working for Red Hat on SE Linux in Fedora. Fedora has a very complete implementation of SE Linux, probably the most complete of any distribution. |
| rjc | FC2 introduced it but had it disabled by default. FC3 made it the default and added the "targeted" policy that causes less complaints from users. |
| rjc | Debian was the first distribution to have SE Linux support, but it is still a work in progress. |
| rjc | After Sarge is released libselinux1 will go into base and we will get SE Linux support included in core packages such as sysvinit. |
| rjc | Debian kernel is already being compiled with SE Linux support (apparently). |
| trulux | rjc, right |
| trulux | Debian kernel is going to have the SELinux enhancements inside it |
| trulux | Hardened Debian kernels already have selinux but Debian needs a few improvements to get in the rid of hardened desktop environments |
| rjc | The main point of MAC is to prevent inappropriate access to resources. Often programs don't properly secure their resources, or users make mistakes. MAC does not permit the program/user to control the access that is granted to it's resrources. So a program might create a file in /tmp with mode 777 (some do), but SE Linux will still greatly restrict access to it according to the security policy. |
| trulux | rjc, as maybe some people here wouldn't know it would be great idea to talk about what domain and contexts mean |
| rjc | The SE Linux policy is written in the M4 macro language, and after macros are expanded it's compiled into a binary form that can be loaded into the kernel. Policies are big, here is the summary produced on a compile on my laptop: |
| rjc | security: 5 users, 6 roles, 1236 types, 37 bools |
| rjc | security: 54 classes, 292325 rules |
| rjc | The policy binary is over 8M in size. This is largely due to having the policy for all possible daemons compiled in, if I remove the policy source files related to daemons I don't use then I could significantly reduce the size. |
| rjc | A concern that many people have is that the number of rules is so large. However in Unix permissions you will often have more than 300,000 files each of which can impact the security policy of the system. There are no tools in common use to analyse a Unix file system and determine what level of access might be granted by a combination of SETGID and SETUID program executions. |
| rjc | For SE Linux the company Tresys http://www.tresys.com/ has released a tool named "apol" to analyse policy. This allows you to determine exactly what access is granted to each program. |
| trulux | also Tresys developed the v16 policies aka Conditional policies |
| trulux | which are part of the SELinux backport for 2.4 |
| rjc | During the SE Linux work we have discovered quite a number of bugs in application code that may have security implications. The general proceedure when writing policy is to write for what you think the program should be doing and then run it and see the difference between your expectations and the reality. The difference will be due to a lack of understanding of how the program works (no-one ever documents these things), a bug in the pro |
| rjc | or a mis-feature or unexpected feature. |
| rjc | Bugs that are often found are due to file handle inheritance. A program opens some files, network sockets, etc, then fork's a child and executes another program while leaving the file handles open. The program should either close the file handles explicitely or set them to close-on-exec. |
| rjc | SE Linux implements the domain-type, role-based, and MLS security methods. |
| trulux | Type Enforcement (r) |
| rjc | In SE Linux every process and every object that a process may access has a "security context". The security context of a process includes the "domain" that it runs in, the security context of an object includes the "type". Domains are a sub-set of types - types that may be assigned to processes. |
| trulux | btw, just to remember that by now SELinux (updated source and bug fixes, enhancements,etc) are only available for 2.6 kernel brand |
| trulux | personally, i'm trying to change this by doing a small backporting effort |
| rjc | The polixy database has a set of rules which specify for combinations of domain, type, and object-clase the access that is to be granted. The "object-class" is one of process, file, lnk_file, dir, etc. The access may be "allow" (permit and don't audit), "dontaudit" (don't audit anything but don't permit the operation), "auditallow" (audit an operation that is allowed - needs a separate allow rule to actually permit the operation), and |
| rjc | "neverallow" which is not compiled into the binary, it's just an assertion for the compiler. If the policy tries to allow an operation that a neverallow statement doesn't permit then the compilation will fail. |
| trulux | current there's a backport for 2.4.28 which adds support to v15 policies, but i'm working on a new one that adds support to latest policy versions |
| rjc | In SE Linux each process has an "identity" as part of the security context. For a daemon the identity is "system_u", for a user process it will either be the user-name for a user who has their name compiled into the policy database or "user_u". |
| rjc | The identity restricts which roles the user may enter, and the role restricts which domains may be entered. So therefore the identity of the process determines the access that may be granted to all child processes. |
| trulux | ok, now we are going to comment quickly the attack vectors and the way to stop them |
| rjc | For non-administrative processes on the strict policy the identity never changes. So regardless of executing SETUID programs or programs who's type causes a domain transition (the SE Linux equivalent of SETUID) you will still know who started it, and the kernel will use that information in access control decisions. |
| trulux | buffer overflows are stopped by PaX and stack-based buffer overflows/stack smashing are stopped by SSP/ProPolice and also PaX |
| trulux | Return to libc (ret2libc) tricks are prevented by the PaX ASLR and PIE binaries |
| trulux | and as we can see at http://www.debian-hardened.org/papers/hardened-debian-en-2005/img7.png |
| trulux | information leaks, memory corruption, chroot jails escaping, fork() bombs and so on are stopped by systems like SELinux |
| trulux | RSBAC |
| trulux | grSecurity (RBAC) |
| trulux | etc |
| trulux | also, Trusted Path Execution prevents most of the attacks against, for example, web servers using buggy versions of PHP or vulnerable scripts |
| rjc | trulux: Fork bombs are not stopped by SE Linux. SE Linux is not designed to control abuse of resources or covert channel attacks. |
| trulux | rjc, a crappy way to prevent them is to use ulimit |
| trulux | but grSecurity provides fork() bombs protection |
| rjc | In many cases chroot environmnts give no benefit on SE Linux as you can write policy for a domain that is not chrooted that restrict it more than a chroot would. For example in Debian I run postfix without the chroot facility. |
| trulux | yeah |
| trulux | grSecurity provides chroot protections |
| trulux | ok, i must go for dinner and be back in a few minutes, rjc, you can talk about these vectors |
| rjc | ulimit doesn't restrict root processes for fork. We need another LSM module to protect against resource abuse. |
| rjc | Several Linux security systems provide virtual environments or secure chroot's that prevent killing a process in a different chroot, seeing such processes in "ps" output, etc. SE Linux implements such access controls on a per-domain basis. So the domain that you use for a chroot may be permitted some access to other domains if appropriate (it's a decision you can make when writing the policy). |
| rjc | SE Linux provides very fine grained access control and has a very fleible configuration. There are currently two main policies, "strict" (in which every daemon has it's own domain and non-admin users have restricted access to the system), and "targeted" where most daemons and all user processes run in a domain that is not restricted by SE Linux. |
| rjc | strict gives the best security and targeted gives the best ease of use. But there are lots of other possibilities. Some people are mixing policy between strict and targeted to address their security requirements. |
| rjc | Another feature that is supported in SE Linux (but not in the Debian or Red Hat implementations of it) is MLS (Multi-Level Security). MLS assigns levels such as "secret" and "top secret" to processes and controls access to prevent write-down (top-secret process writing to a secret file) and read-up (secret process reading a top-secret file). MLS just aims to prevent data excaping to a lower classification, while domain-type aims to restr |
| rjc | access to important files to protect both secrecy and integrite as appropriate. |
| rjc | From time to time I run SE Linux "play machines" which have free root access and only SE Linux restricting access to the system. They permit operations such as "rm -rf /" as root without causing any harm. I will have one online again soon. |
| rjc | Are there any questions at this time? |
| trulux | rjc, back |
| trulux | rjc, questions on #qc |
| trulux | seems currently no questions |
| trulux | as rjc said, SELinux provides a smart way to limit the capabilities of a chrooted process |
| trulux | like doing a nice raising or even a outside-chroot-process killing |
| trulux | the point is simple: one of our goals is to get those protections in Debian |
| trulux |
|
| trulux | MLS provides information leak protection and one of the adavantages is to prevent corruption, so, that can be prevented without a lot of pain |
| rjc | alejandro: MLS is not really designed for that. The domain-type model is better suited to such things (if you are referring to preventing root from removing all files). |
| trulux | yeah |
| trulux | i don't know SELinux as rjc does, i'm just new but concerned of its advantages |
| trulux | now we are going to switch to the 8 slide |
| trulux | Bugs to stop |
| trulux | by now, the bugs/security braks that appear there are prevented by our current security model |
| trulux | Kernel-level/space enhancements and userland improvements |
| trulux | switch to slide 9 |
| trulux | PaX Executable Space Protections |
| trulux | There we can see an example of what PaX memory protection does |
| trulux | that's how an execution of xmms could be |
| trulux | loads the library symbols at memory |
| trulux | and so on |
| trulux | in the right diagram we see that EVERYTHING is writable & executable |
| trulux | which means: crap thing |
| trulux | insecure and not-preventing at all stack or even any type of memory corruption |
| trulux | in the left diagram we see how looks the same with a PaX enabled kernel |
| trulux | nothing is PROT_WRITE and PROT_EXEC same time |
| trulux | for a few information about what is and how works PROT_EXEC look at: |
| trulux | http://bernia.disca.upv.es/lxr/http/source/fs/binfmt_elf.c |
| trulux | IE: if (eppnt->p_flags & PF_X) elf_prot = PROT_EXEC; |
| trulux | and so on |
| trulux | also PaX prevents the status changing of pages with mmap() and mprotect() |
| trulux | disallowing pages to get into a PROT_WRITE + PROT_EXEC status |
| trulux | after this brief explanation about PaX protections, we need to know the PaX & PIE overhead |
| trulux | switch to slide n 10 |
| trulux | Performance impacts of PIE & PaX |
| trulux | A brief explanation of how the becnhmarks worked go to http://d-sbd.alioth.debian.org/www/pax/picpiefun.txt |
| trulux | On AMD64: http://d-sbd.alioth.debian.org/www/pax/pie.txt |
| trulux | umm, kay |
| trulux | as we see the red accounts an inability of -fomit-frame-pointer to increase performance of PIC/PIE binaries |
| trulux | this is crap because there's no real overhead at all, except for that 1.69% of overhead in i386 |
| trulux | as a conclusion: these enhancements DON'T cause IMPORTANT overhead in the systems using them |
| trulux | indeed, amd64 has NO overhead |
| trulux | and older studies on this are now useless |
| trulux | switch to slide number 11 |
| trulux | SELinux |
| trulux | rjc, myabe you can briefly comment on it |
| trulux | it shows a basic execution of a ssh session |
| trulux | and a user<-role->domain digram |
| trulux | s/digram/diagram/ |
| trulux | as i said before i'm working on a 2.4 backport with the help of Russell and mainly Stephen Smalley from the NSA |
| trulux | an initial release supporting v15 policies can be found at: |
| trulux | https://sourceforge.net/project/showfiles.php?group_id=118309&package_id=137453 |
| trulux | If someone wants to test selinux without pain use Hardened Gentoo livecd |
| trulux | but i couldn't get the ISO recorded correctly so, i can't provide access to a test machine with SELinux |
| trulux | sorry ;P |
| trulux | we are getting near to the end |
| trulux | switch to slide 12 |
| trulux | Advantages |
| trulux | the most important: |
| trulux | any derivated work of Debian , including but not limiting to, debian-based distros would take benefit of these security improvements |
| trulux | ie: Linex, UBUNTU, Knoppix, Gnoppix, Xandros, Linspire, Corel Linux, Esware, Stonegate, etc |
| trulux | (not including Hispafuentes because a simple reason: if you use Debian trademark in your product name first take care of knwoing what you are doing and also what it's Debian about) |
| trulux |
|
| trulux |
|
| trulux | yeah, ajmitch is doing an effort in improving SELinux for Debian also, hopefully i ask him to contribute to Hardened Debian ;D |
| trulux | the problem is that we are not going to be part of Debian until sarge gets released |
| trulux | that gives us a little couple of time |
| trulux | to improve our style |
| trulux | we are going to move forward to Debian but Ubuntu is now in our mind |
| trulux | and we have the support of some Ubuntu developers |
| trulux | see http://wiki.debian-hardened.org/Ubuntu-Hardened_Debian_Collaboration for more info |
| trulux | also |
| trulux | the *best* thing for a security response team is to make their work a secondary priority: software bugfixes and updates |
| trulux | which means in development terms: |
| trulux | preventing 40% of security issues in Ubuntu -> Debian |
| trulux | for more information we can see a good study by John Richard Moser: |
| trulux | https://www.ubuntulinux.org/wiki/USNAnalysis |
| trulux | 40 of 100 security issues is a great thing, which makes all of this worthy |
| trulux | ending with the Advantages section we should say that the free software (and open source) communities can give us support |
| trulux | collaboration |
| trulux | and freedom of choice, voice and development |
| trulux | also a great environment for gathering enterprises attention and users feedback |
| trulux | ok, switch to slide 13 |
| trulux | Disadvantages |
| trulux | some enhancements would cause errors that we would know after LONG testing periods |
| trulux | unmderstanding this effort in the users side is HARD |
| trulux | sysadmins would need to add some additional steps to their everyday work (being root not anymore possible, need to get the sysadmin role, and so on) |
| trulux | (but that could be solved without pain) |
| trulux | also, SSP/ProPolice is not working on up-growing stacks based architectures. |
| trulux | i wouldn't talk about them here because there's no point at all to spend time on it |
| trulux | (it'slate i think :P) |
| trulux | usability is important so, many of the efforts will go in that way |
| trulux | as Alan Cox says: |
| trulux | keep it simple |
| trulux | ;-) |
| trulux | err, i forgot the "stupid!" part, right? |
| trulux | heh, ok, btw, just to say that there are many FUDS over the technologies we are deploying now |
| trulux | many of them because old experiences with crappy, buggy, damn stuff |
| trulux | as we demonstrated, these stuff has entered a mature state of development |
| trulux | ready for production |
| trulux | switch to slide 14 |
| trulux | Inmediate future. |
| trulux | progressive inclussion in the Debian project |
| trulux | priority number 1 |
| trulux | progressive inclusion in Ubuntu project |
| trulux | priority number 1 and half ;D |
| trulux | also wide support for architectures |
| trulux | forgot the HP-UX 'cos it's an OS , the arch is HPPA |
| trulux | ACTION MADE A MISTAKE THERE |
| trulux | sorry of the caps |
| trulux | again the SELinux backport for 2.4 |
| rjc | For the sshd example domain_trans() is used for the user sessions, the sshd requests the appropriate context for the user session after querying the kernel about which domains are permitted for the user. |
| trulux | with the help of the NSA guys it would happen soon |
| trulux | rjc, thanks for the point! |
| trulux | btw, the OSSI or Open Source Security Initiative is an initiative to standarize open source and free (free as in freedom) security technologies |
| trulux | promoting alliances and collaborative efforts |
| trulux | i've started it since i think that collaboration in this type of projects sucks |
| trulux | so, it's still a draft |
| trulux | read http://wiki.debian-hardened.org/OSSI for more info |
| trulux | (and feel free to support it ;D) |
| trulux | ending.... switch to slides 15 and 16 |
| trulux | References |
| trulux | you can find a few fine links there to read about all of this stuff |
| trulux | now i want to present a tool i'm developing |
| trulux | before finishing the talk |
| trulux | it's called Collision, it's a RTS (Regression Test Suite) which tests the security of *BSD and mainly GNU/Linux systems security |
| trulux | it can test chroot jails related security breaks and vulnerabilities |
| trulux | memory related protections and address space layout randomization |
| trulux | also other things like RSBAC jails |
| trulux | and a cryptographic test for fips140-2 compliance |
| trulux | which is the official NIST specification for random numbers generation devices: |
| trulux | RNGs |
| trulux | (/dev/random and /dev/urandom) |
| trulux | (for example :P) |
| trulux | it's based on Peter Busser's paxtest, but most base code changed |
| trulux | this is how it works: |
| trulux | let me set up my testing box and show how a hardened kernel looks in the side of a regression test suite |
| trulux | ok, compiling the rts |
| trulux | ok, it's large so, big flood: |
| trulux | oot@ecate:~/collision-rts-0.1/src# ./collision-rts blackhat |
| trulux |
Collision RTS - Copyright(c) 2004 by Lorenzo Hernández García-Hierro |
| trulux | Released under the GNU Public License version 2 or later |
| trulux | Writing results to collision-rts.log |
| trulux | It may take a while for the tests to complete |
| trulux | Tests results: |
| trulux |
Collision RTS - Copyright(c) 2004 by Lorenzo Hernández García-Hierro |
| trulux | Released under the GNU Public License version 2 or later |
| trulux | Mode: blackhat |
| trulux | Linux ecate.tuxedo-es.org 2.6.7-hardened #1 Wed Nov 17 21:19:05 UTC 2004 i586 GNU/Linux |
| trulux | Executable anonymous mapping : Executable bss : Executable data : Executable heap : Executable stack : Executable anonymous mapping (mprotect) : Executable bss (mprotect) : Executable data (mprotect) : Executable heap (mprotect) : Executable stack (mprotect) : Executable shared library bss (mprote |
| trulux | ct) : Executable shared library data (mprotect): Writable text segments : Killed |
| trulux | Anonymous mapping randomization test : 15 bits (guessed) |
| trulux | Heap randomisation test (ET_EXEC) : 13 bits (guessed) |
| trulux | Heap randomisation test (ET_DYN) : 23 bits (guessed) |
| trulux | Main executable randomisation (ET_EXEC) : No randomization |
| trulux | Main executable randomization (ET_DYN) : 15 bits (guessed) |
| trulux | Shared library randomisation test : 15 bits (guessed) |
| trulux | Stack randomisation test (SEGMEXEC) : 23 bits (guessed) |
| trulux | Stack randomisation test (PAGEEXEC) : 24 bits (guessed) |
| trulux | Return to function (strcpy) : Vulnerable |
| trulux | Return to function (memcpy) : Vulnerable |
| trulux | Return to function (strcpy, RANDEXEC) : Vulnerable |
| trulux | Return to function (memcpy, RANDEXEC) : Vulnerable |
| trulux | Executable shared library bss : Executable shared library data : FIPS-140-2 Compliance tests for RNG dev : /dev/urandom |
| trulux | MonoBit test: : Passed |
| trulux | Poker test: |
| trulux | RUNS test: : Passed |
| trulux | LongRun test: : Passed |
| trulux | Position Independent Executables support : Unsupported. |
| trulux | SSP/ProPolice arg-based overflow : Vulnerable |
| trulux | SSP/ProPolice stack smashing test : Vulnerable |
| trulux | SSP/ProPolice live exploit test : Vulnerable |
| trulux | PID Randomization : Not vulnerable |
| trulux | Raw IO access restrictions : |
| trulux | Testing denied ioperm : Not vulnerable |
| trulux | Testing denied iopl : Not vulnerable |
| trulux | DMESG Restrictions : Not vulnerable |
| trulux | Symlink restrictions : Vulnerable |
| trulux | Hardlinking restrictions : N/A |
| trulux | Chroot jails regression tests : |
| trulux | Chdir("/") on chroot : Not vulnerable |
| trulux | Testing double chroot : Vulnerable |
| trulux | Dangerous capabilities inside chroot : Not vulnerable |
| trulux | Fchmod +s inside chroot : Not vulnerable |
| trulux | Chmod +s in chroot : Not vulnerable |
| trulux | Kill process outside chroot : Not vulnerable |
| trulux | mknod() inside chroot : Not vulnerable |
| trulux | Nice raise in chroot : Not vulnerable |
| trulux | Priority raise in chroot : Not vulnerable |
| trulux | sysctl() inside chroot : Not vulnerable |
| trulux | Abstract Unix socket() outside chroot : Not vulnerable |
| trulux | SHM attach outside chroot (non-root) : Not vulnerable |
| trulux | SHM attach outside chroot : Not vulnerable |
| trulux | ptrace() attach outside chroot : Vulnerable |
| trulux | RSBAC Jail regression test : rsbac_jail() unsupported |
| trulux | as you can see the output is a bit messed up due to some chnages i made to the outputting one day ago |
| trulux | it needs a few improvements and double chroot test failes because we haven't set to on the double chroot protection on our kernel in run time |
| trulux | ptrace outside chroot is also not vulnerable |
| trulux | but failes |
| trulux | anyway |
| trulux | this rts is going to be published after the NSA releases a selinux testsuite that is under development |
| trulux | i have received, thanks to them by that, the sources and we will have a great tool for testing SELinux |
| trulux | also IBM is developing a LSM testsuite, which Trent Jagger from the USA hq's sent to me, it's a big one but it will be also a good suite |
| trulux | all of these suites will be used to enhance my collision-rts and that's because until they get public released i can't put in public domain any code |
| trulux | and now SWITCH to last slide |
| trulux | ENd, Questions comments etc |
| trulux | this has FINISHED |
| trulux | thanks for all of your attention |
| trulux | i know this got long and long |
| trulux | also thanks to Russell for giving us a bit of his time |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| fernand0 | plas plas plas plas plas plas plas plas |
| fernand0 | plas plas plas plas plas plas plas plas |
| damage | clap clap clap clap clap clap clap |
| fernand0 | plas plas plas plas plas plas plas plas |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| fernand0 | plas plas plas plas plas plas plas plas |
| damage | clap clap clap clap clap clap clap |
| damage | clap clap clap clap clap clap clap |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| fernand0 | plas plas plas plas plas plas plas plas |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| damage | clap clap clap clap clap clap clap |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| fernand0 | plas plas plas plas plas plas plas plas |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| fernand0 | plas plas plas plas plas plas plas plas |
| krocz | CLAP CLAP CLAP CLAP CLAP |
| fernand0 | gracias! |
| antlarr | plas plas plas plas plas plas plas plas |
| antlarr | plas plas plas plas plas plas plas plas |
| antlarr | plas plas plas plas plas plas plas plas |
| antlarr | plas plas plas plas plas plas plas plas |
| krocz | 3 horas |
| damage | exelente |
| krocz | creo que rompiste el record |
| krocz | :) |
| krocz | ahora a remojar los dedos |
| pappy- | very good |
| trulux | gracias a todos |
| trulux | y perdonad por el fl00d ;D |
| krocz | trulux excelente material |
| damage | exelente trulux, pappy- y rjc |
| trulux | rjc, thanks again |
| krocz | ho thanks pappy- and rjc |
| pappy- | trulux: thanks for the presentation |
| pappy- | really impressive |
| pappy- | thanks to Russel too. |
| damage | thanks pappy- and rjc, very nice presentation |
| krocz | jaime: endlogs #linux |
| krocz | jaime: endlog #linux |
The Organizing Comittee
