|
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
|
PaX tambien protege del ataque de escritura del HEAP?
|
|
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 : push %ebp
|
|
trulux
|
0x00000a85 : mov %esp,%ebp
|
|
trulux
|
0x00000a87 : push %ebx
|
|
trulux
|
0x00000a88 : sub $0x2d4,%esp
|
|
trulux
|
0x00000a8e : call 0xa80 <__i686.get_pc_thunk.bx>
|
|
trulux
|
0x00000a93 : add $0x2675,%ebx
|
|
trulux
|
0x00000a99 : and $0xfffffff0,%esp
|
|
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 : mov $0x0,%eax
|
|
trulux
|
0x00000aa1 : sub %eax,%esp
|
|
trulux
|
0x00000aa3 : lea 0xfffff3b8(%ebx),%eax
|
|
trulux
|
0x00000aa9 : mov %eax,0xfffffd50(%ebp)
|
|
trulux
|
0x00000aaf : cmpl $0x1,0x8(%ebp)
|
|
trulux
|
0x00000ab3 : jle 0xbc1
|
|
trulux
|
jle 0xbc1 <- 317 is our offset
|
|
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: then is MLS that protects attacks like 'rm -rf' with polices, no?
|
|
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
|
|
|
