Recent Features
| |||||||||||||
ComplexityComplexityPosted Sep 23, 2004 2:56 UTC (Thu) by walters (subscriber, #7396)In reply to: Complexity by elanthis Parent article: An introduction to SELinux
As for complexity, Stephen Smalley explains it elegantly. The reason SELinux permissions aren't based on file paths has also been explained many times. Put most simply, there are *many* possible ways to reference a file (inode) in Linux. You can have hard links, bind mounts, symlinks, etc. Having the kernel try to control access via file paths is inherently fragile. You don't want to restrict file paths, you want to restrict access to the actual object.
(Log in to post comments)
Complexity Posted Sep 23, 2004 4:30 UTC (Thu) by dvdeug (subscriber, #10998) [Link] Good security plans are simple, in part because it's simpler to understand a simple plan, and in part because few people really enjoy working with security and will make shortcuts when it gets too complex. It doesn't matter how wonderful SELinux is and how many smartass comments you can make about real-world systems being complex, if it's too complex, then it isn't going to work for most of us.
Complexity Posted Sep 23, 2004 4:57 UTC (Thu) by walters (subscriber, #7396) [Link] The point is that securing a complex system is going to be complex. There simply aren't any shortcuts. However, as Stephen says, SELinux is very flexible, as is exemplified by the new targeted policy. The targeted policy is really quite simple, and it's *very* easy to just turn restrictions on a particular service off now with the support for runtime boolean policy changes.
Complexity Posted Sep 30, 2004 8:44 UTC (Thu) by emj (guest, #14307) [Link] > The point is that securing a complex system is going to be complex.
Well, if setting up an ordinary multiuser shell/ftp/web server is going to be complex, then SELinux is to complex.
Complexity Posted Sep 23, 2004 6:12 UTC (Thu) by bronson (subscriber, #4806) [Link] Well, here's a key phrase from that message:
"Being confident in the correctness of an inadequate security model doesn't help much."
If you can figure out a simple model that both works well and is demonstrably secure, you will gain fame and fortune. However, a great number of people have spent long years working on exactly this problem and there's still no magic bullet. If you're not willing to devote the time needed to create an effective security model then, well, you probably don't need one. Most people don't.
Complexity Posted Sep 23, 2004 9:56 UTC (Thu) by rwmj (subscriber, #5474) [Link] The reason SELinux permissions aren't based on file paths has also been explained many times. Put most simply, there are *many* possible ways to reference a file (inode) in Linux. You can have hard links, bind mounts, symlinks, etc. So why can't the "compiler" work all this stuff out for me? That's what computers are good at: automating all the grunt-work. Rich.
Complexity Posted Sep 23, 2004 13:44 UTC (Thu) by walters (subscriber, #7396) [Link] So why can't the "compiler" work all this stuff out for me? That's what computers are good at: automating all the grunt-work. How can the compiler know what will later happen on your system? If some attacker gains privileges to bind mount /foo to /, then all of a sudden you have a whole other set of access points.
Complexity Posted Sep 23, 2004 14:15 UTC (Thu) by mmarsh (subscriber, #17029) [Link] I think what he meant is that you specify your rules with file paths, and the compiler figures out what device/inode that path references. The final compiled version that actually gets used doesn't have path references. Then you just have to make sure that all of your old path specifications are still correct the next time you compile.
Complexity Posted Sep 23, 2004 16:24 UTC (Thu) by walters (subscriber, #7396) [Link] The files ultimately still need to have types assigned to them. No compiler can figure out what a program is actually doing with all of its files and figure out the best way to assign types to the files in order to achieve least privilege. Having a tool that looked at the file paths the application referenced and guesses types for them while constructing a policy would be somewhat useful. But it would be no substitute for a human. In a number of cases, SELinux has revealed application bugs like the kerberos libraries trying to open /etc/krb5.conf with write permissions.
Complexity Posted Sep 23, 2004 17:09 UTC (Thu) by mmarsh (subscriber, #17029) [Link] That's not how I read the comment, but then I'm also not familiar with SELinux, so this may just be an incorrect reading. My impression was that Rich wanted to assign a type to a file by name and let the rules compiler figure out what the actual object is.
After poking through the documentation, it looks like I might just have been off. There are examples of specifying objects by path, and wildcards to assign a type to everything not otherwise specified.
Complexity Posted Sep 23, 2004 19:14 UTC (Thu) by walters (subscriber, #7396) [Link] Oh, I guess I misunderstood what you were saying. There is a mapping from file names to contexts that SELinux uses to initialize the system. Defining this mapping is part of writing a security policy for a program. However Rich and elanthis seemed to want to do away with types entirely and have them somehow automagically created; that doesn't make sense.
Complexity Posted Sep 24, 2004 3:59 UTC (Fri) by dododge (subscriber, #2870) [Link] As for complexity, Stephen Smalley explains it elegantly.The stuff going on under the hood of a Linux machine can be quite surprising. One of my favorite examples is the "cardmgr" program, part of the PCMCIA suite. When the program starts up, it creates a new device file with a somewhat unpredictable name based on PID and a one-up counter. It does this in one of several directories; it has a list of places it tries, and no, "/dev" is not at the front of that list. It then opens the device and unlinks the file while holding it open. It does this multiple times and it all happens very quickly. As a sysadmin you are very unlikely to ever come across one of these device files or even know that this is going on. See the "open_dev" function in "cardmgr.c" for the details; it's still there in the current 3.8.2 release. Aside: pcmcia-cs even had compile-time shenanigans that could bite you. It made its own copy of the kernel's configuration header for its modules to include, but it only bothered to copy the config settings that it knew about and thought were important. If you had a kernel patch (such as LSM) that added new config settings, the PCMCIA code would ignore them and its modules would be compiled without them. If those config settings resulted in changes to the size and layout of kernel data structures (which LSM certainly did), then loading one of those PCMCIA modules could easily wreak havoc with kernel data. Now that things like LSM and the PCMCIA modules are all in-tree it shouldn't be a problem, though if you were to build your modules out-of-tree from the pcmcia-cs package it might still do this.
|
|||||||||||||