login
Search
Hello all, I'm running OBSD on my older boxes but still Debian on my big box (not ready yet). Linux has SELinux in its 2.6 kernel and debian has gone ahead and compiled SELinux into the libraries, although the SELinux policies aren't ready on debian yet. The whole focus seems to be to make Linux "more secure". I'm not sure what to make of it. I figure that if you want secure, you switch to OBSD. Could someone who knows both the details of OBSDs security enhancements and the details of SELinux comment? Please note: this is _not_ a troll, flame-ware-tinder-box, whatever. I'm genuinly interested. Thanks, Doug.
I don't know all the details, and especially not the SELinux details, but that won't stop me from commenting. Not long ago I was talking with a Linux person about security, and they pointed me to a set of patches that did a lot of nifty stuff. Good stuff, like the things you find OpenBSD doing. But it's not in the mainline kernel, it's a set of patches. Security should not be grafted on, it should be integrated into the main development process. I'm sure the patch maintainers are doing their best, but this doesn't change the fundamental flaw in the process. It's not a flaw of their making, it's inherent in the situation. But it's still a flaw. Compare that to a complete operating system (OpenBSD) where security is part of code quality, and part of the normal mainline development. -- Darrin Chandler | Phoenix BSD User Group | MetaBUG dwchandler@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
If I could add one thing to Darrin's comment (of which I agree completely), it would be this: SELinux is a button. Buttons are easy to turn off. --- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
yes you're right. Although that point no longer holds. SELinux is more
or less "official" now. But for a looong (long) time, it was pretty
apparent what the focus of the developers was *not* on.... And even
button, yes. The scary (or "interesting", depending on how you see it)
bit is that there is a whole infrastructure (LKM) behind it making it
easy(?) to create, and plug in your own buttons to do your own funky
stuff...
-jf
--
In the meantime, here is your PSA:
"It's so hard to write a graphics driver that open-sourcing it would not help."
-- Andrew Fear, Software Product Manager, NVIDIA Corporation
http://kerneltrap.org/node/7228
As I understand it, the patches (the button) are maintained by the US NSA; I suppose as a service to their fellow Americans. That likely brings out the conspiracy theorists who say that there's probably a back-door to allow NSA to read your ssh keys, GPG/PGP keys, whatever. My _personal_ perspective is that OBSD is smaller. You don't have 5,000 or whatever people changing the kernel, plus NSA putting their thumb in it. You have my Fellow Canadian Theo and people he trusts. Thanks for your comments. Doug.
The problem of Linux as a whole is that it tries to resolve security problems not by auditing code but by implementing SELinux. But what the problem would be if OpenBSD has "SeBSD" extension? It's just one of security features, and I don't see the matter for blaming on SELinux. Linux security flaws are not there but in Linux kernel as a
SELinux has clearly defined security mechanisms implemented through different components. It is doing what it was designed for. The real problem with SELinux is the way it hooks to the Linux kernel. The inaccurate marketing of this tool doesn't help too, unsuspecting users are blindly using it as a magical security solution.
I think the nearest equivalent is "TrustedBSD". The main trouble with SELinux is that it's so horrendously complex [1] and fraught with traps for the unwary [2]. The chance that the policy you've written is correct (i.e. without unwanted holes), unless you happen to have a PhD in SELinux, is pretty much zero. On the other hand, the basic Unix permissions model is so simple it's easy to audit. The other problem with SELinux is that there seems to be some smoke and mirrors going on. SELinux: "We don't have a superuser account!" Me: "So how do you configure SELinux policies?" SELinux: "You need to have a special role, sysadm_r" [3] Me: "So someone logged with sysadm_r can change any SELinux policy they like? Or even disable SELinux entirely?" SELinux: "Yes" Me: "So how is that different from having a root account?" SELinux: "Well, only the trusted administrator needs to have this privilege. You don't give it to any of your service daemons, for example, and they can't recover it" Me: "But I don't run any of my daemons as root anyway; they all run as their own separate unprivileged uids." SELinux: "Hmm. Good point. But on a non-SELinux system, you could attempt to break a setuid-root binary to get root again." Me: "But with SELinux, don't you have rules so that privileged applications transition the domain? So for example, when you run tcpdump, it transitions into another domain which has privileges to capture network packets?" SELinux: "Yes. But it's much more granular and configurable than setuid." Me: "I think I've heard enough. Just let me audit my few setuid programs properly, and then I won't need to learn SELinux at all, thank you." [1] http://www.lurking-grue.org/writingselinuxpolicyHOWTO.html [2] http://fedoraproject.org/wiki/SELinux/EnforcePolicy [3] http://docs.fedoraproject.org/selinux-faq-fc3/index.html#id2826056 "How do I temporarily turn off enforcing mode without having to reboot? ... You must issue the setenforce command with the ...
I agree that it is just one of many security technologies, but I also think that it gets misrepresented as "The One and Only Security Feature". That in turn takes attention away from other valuable security technology and practices, a lot of which OpenBSD does work toward. Taking a step back though, most of this discussion seems to be about using SELinux to specify a policy for how a program interacts with the rest of the system. It acts as a monitor, which is something that the traditional unix semantics happen to also do. They both sit in the same layer (the kernel), and so they're both only able to perform checks when the userland program asks the kernel to do something. The difference between the traditional unix checks and the SELinux ones is that SELinux can be a bit more stringent about what it allows. Because SELinux and the unix stuff are separate, you have to specify your policy in both to have them enforced. I would like to point out that OpenBSD provides a specific and stringent monitor for a variety of it's services too. Examples of these services are sshd, bgpd, ospfd, isakmpd, and ntpd. All of these split themselves into separate processes that watch each other and make sure that they're all doing the right thing at the right time. Operations that require privilege are verified by a separate process before being passed onto the operating system itself. For example, an SELinux policy for isakmpd on a linux box may restrict the files it can open to only be host certificates under / etc/isakmpd. While isakmpd is running this may be all it needs to do. On any unixish system though (say, OpenBSD is one of those!), isakmpd could split itself into two, a large fat part that does most of the work, and a small privileged part that is able to open files. When the fat part wants to read a host certificate it will ask the small part to do it on its behalf. The small monitor will verify that the request is fine ...
What makes this so effective is that it's built-in by the people who understand it best, the developers. Not some Jr. Sysadmin tasked with standing up a new Linux server and trying to write his own SELinux policy from scratch. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
On 24.09-10:25, Jason Dixon wrote: little sad to see such slating of extended security feature sets by such a security conscious group. policy cannot be defined or implemented in the application. it must be enforced by the kernel to be meaningful. this, of course, does not preclude privilage seperation within an application but that is good application programming not secure policy. SELinux's policy features are a superset of standard Unix. I was unaware of 'systrace' in openbsd but have found these poor and cumbersome previously but will certainaly review it. i agree completely with the general tack of opinion here, there is very little that cannot be done with consious administration and intelligent use of available features. it's a little like ACLs, it's definately a security feature but getting real value add from it is rare (particularly when you take into account the overhead of these features) and whether it increases or decreses overall security is a serious question too. in many instances (on various trusted operating systems and policy systems, not just selinux) i have seen the most appalling policies simply because administrators became significantly frustrated that they simply "opened" stuff until the application worked.
Hi,
You might be talking about grsecurity and PaX [1]. SELinux hooks
through the LSM [2] framework. LSM was designed to be easily enabled
and disabled, so that should be a fundamental flaw. LSM has valid
criticisms [3] [4].
[1] <http://grsecurity.net>
[2] <http://en.wikipedia.org/wiki/Linux_Security_Modules>
[3] <http://www.grsecurity.net/lsm.php>
[4] <http://www.rsbac.org/documentation/why_rsbac_does_not_use_lsm>
Cheers,
Ed
The OpenBSD developers are trying to make the most secure UNIX system they can; SELinux might or might not be secure, but it's not UNIX. Additionally, it's not entirely clear whether it actually helps; a SELinux configuration is, even at its best, a lot more complex than the equivalent UNIX-ish configuration. Thus, it becomes more likely that there will be either configuration or coding errors. Joachim -- TFMotD: kadmin (8) - Kerberos administration utility
What part of SELinux is NOT Unix? Remember that all traditional Unix For example for blocking some critical operations for ALL users, even root. Of course, that's the case when strict traditional Unix-awareness is not so critical as the security of the system by Every security feature, every OS improvement IS an additional code. That's the problem of proper kernel and security policies audit, not
Insofar as that ls -la shows them, yes. In the sense that files actually Root almost always can gain complete control over the system anyway, so that's not a big issue. Also see my comments below. Still, yes, SELinux can be - rarely - used to solve problems for which no clean UNIX-ish solution exists. Far too often, though, it's thought Yes, but not all code is created equal. Layering a second permission layer into the system integrates closely with all other security mechanisms, which is more dangerous than yet another driver. Additionally, it's completely the wrong way to go about securing a system. The best way not to have any vulnerabilities is not to have any vulnerabilities; stuff like SELinux, Pax, or W^X is cool, but not a substitute for good programming. An OpenBSD system running properly chosen and secured programs without W^X is almost as secure as one with it. I'd argue the same goes a Linux system running a haphazard collection of badly-out-of-date, unpatched monstrosities with or without SELinux. Finally, SELinux is almost never necessary. (But it *is* - rarely - useful.) And takes a lot of time, which is usually better spent doing something actually useful - like log monitoring. Joachim -- TFMotD: packages-specs (7) - binary package names specifications
rhetorical question: why aren't the policies ready? the problem with security by policy is that the policy is always wrong. exercise for the reader: find somebody using SELinux. ask them to describe their policy over the phone. then repeat it back to them. did you get it right?
From what I've seen, 9 times/10, they'll only know they're using it if they had to disable it to fix an app with a broken policy...
I only know (via the mailing list) people running Debian. Debian comes with the SELinux patches compiled into the libraries and kernel but the SELinux policies haven't been integrated into the "Debian way of doing things yet". In other words, since debian packages, by policy, must "just work" on install (come with a reasonable default setup), (except for a few things like the Shorewall firewall builder that installs to a disabled state that prints a warning), once Debian decides on a SELinux policy, all the thousands of packages have to be set up to detect the SELinux policy on the box at the time and integrate themselves into it. That's the limit to what I know about it. It sounds like solving the opening of a can of worms by dumping it into a vermiculture pot. Anyway, thanks for the discussion. For security I'll stick with OBSD. For watching movies, I'll stick with Debian until someone builds a video card that doesn't need a blob driver to run the hardware converter. Doug.
On 22.09-16:21, Douglas A. Tutty wrote: i would be willing to bet this will never happen, particularly in a community like debian's. if, by some miracle, it does i'd make a further bet that they'll have to roll back the decision because their users will be crippled. basically, good programming practices get you a lot more for a lot less than wide ethos changes. having said that the extended feature set of selinux can solve issues that "unix" systems are not able to. in short, stick to openbsd. if you need selinux you'll know it ... then you'll go find another product that's not such a nightmare ... actually, nearly all of them are but that's another story.
OBSD is UNIX, .. SELinux is Linux. If you want a secure, efficient, compact OS done by folks you can trust and actually talk to, use OBSD; if you want 'fairly secure Linux' [which has had thousands of hand in it including NSA, as mentioned previousy], use OpenSUSE with ***AppArmor***. Simple and easy to implement, even by less senior Admins. SELinux is **NOT** ready for primetime, unless it's changed tremenduously in the past couple of years. Last time we tried it, management was totally arcane and the machines would lock up on a regular (monthly) basis. It wasn't worth the time to troubleshoot so we went with AppArmor for that application. Lee ================================================ Leland V. Lammert lvl@omnitec.net Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net ================================================
Can you say "root can only run this and that application when su'ed from that guy, and may not open any net connection, but open this file and none A couple of years is a long time, in terms of software, so I'd expect such instabilities, if SELinux is the culprit, to be fixed. But I won't deny it's learning curve is extremely steep. So steep indeed that most of the time it's easier to have carefully laid out standard unix permissions associated with sudo and specific users for specific software. The *need* for things like SELinux exists in some niche markets where higher levels of security are necessary. Remember: OpenBSD still doesn't have a digitally signed code distribution, and in some places that means it can't enter! Stupid, I know, but not too stupid for the "blame game" rules, which sort of ignore the "secure by design" initiatives. Rui -- All Hail Discordia! Today is Sweetmorn, the 47th day of Bureaucracy in the YOLD 3173 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...?
Sure it does, just pull from CVS over SSH and compile your own. Only requires trusting one download, ever, and that can be verified by downloading from n servers from m distinct network locations, and verifying that the checksums match. I do get what you are hinting at, but it's not an insurmountable issue. Joachim -- TFMotD: pflogd (8) - packet filter logging daemon
It depends on the rules. If they say it must be digitally signed... one may be SOL :| -- Wibble. Today is Sweetmorn, the 47th day of Bureaucracy in the YOLD 3173 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...?
Where do I get the ssh fingerprints of the CVS servers? And if I use cvsync, where do I get fingerprints? Best Martin
You can fingerprint the tarballs and compare against the ones on the CD you bought to support the project ? :-) Gilles
I can. But can we agree that packages are not digitally signed, patches are not digitally signed and the methods used to distribute sources online also don't use digital signatures? And that md5/sha1 and pgp are older than OBSD? And to further the flamefest: This is one area where most Linux distros are better. Best Martin
I just wanted to add that MD5 sums are being integrated. IIRC they just weren't functioning totally fullproof (with the x* sets), and the listing seems to confirm this. lftp ftp.openbsd.org:/pub/OpenBSD/snapshots/i386> cat MD5 MD5 (INSTALL.i386) = a215ca115157db97f1bcebee2cc0940c MD5 (INSTALL.linux) = 34ab7e52e8b1ed96682349a2f0addcce MD5 (base42.tgz) = d3d5c580e38d8a7621ad67e8e2b38f6a MD5 (bsd) = 9cc36c08f6e3575107ace6c9eadd1a1a MD5 (bsd.mp) = 410c815dd7b929c9a71c830d2dd0b12f MD5 (bsd.rd) = 15398b92a616885c5af42bdf26a4568f MD5 (cd42.iso) = 005f1cb47bbf5f482ac8250a2cc853a0 MD5 (cdboot) = cfa4e53323285805313c7efcce7a3331 MD5 (cdbr) = ec1630b9b53d47bdfe0037fa9324a9e6 MD5 (cdemu42.iso) = bbb30515ef07a75a168709ec497c7892 MD5 (comp42.tgz) = ab11daa30094e393f97914013d2aa21f MD5 (etc42.tgz) = 76c91a12150f726c20de1c3b20240c0b MD5 (floppy42.fs) = 96514601275e06f08e3b672d2ebdf60f MD5 (floppyB42.fs) = fe5f2eb1b3fdbfb54103010beeee93f0 MD5 (floppyC42.fs) = b3aa430e003772a9fc0cdcf5921cc842 MD5 (game42.tgz) = c30b70aa932e6538a90bc3dad0689847 MD5 (install42.iso) = 60a02a003cd15bf556e3c5d15de1e8e1 MD5 (man42.tgz) = 9bb112644a8e5da552aed13111a0f5d0 MD5 (misc42.tgz) = fe299ac3e268bc13d7bb041c0618a422 MD5 (pxeboot) = e34f00355fb312b97b6b8fa7d9ad684f -- Antti Harri
Where do you get the public keys for the digitally signed distributions? --- Lars Hansson
http://www.openbsd.org/anoncvs.html#CVSROOT, of course. Not all are listed, but one can either use one that needs verified or contact the maintainer for a correct fingerprint. DS
You solve the problem a different way: - You don't give the guy root access, but their own userid - You set file permissions so this userid can read only the file of interest - You use pf rules so that this user ID cannot send network packets - If this guy needs root for something (e.g. to bind to port 80), then you write a three-line setuid root wrapper which binds to port 80 for them. If you have a lot of this to do, then consider an 'open server' which returns the open file descriptor. Regards, Brian.
Hi, All in all, forms of doing it all, but doing all you described creates a lot more work than creating an SELinux policy :) Best, Rui -- Umlaut Zebra o?=ber alles! Today is Boomtime, the 48th day of Bureaucracy in the YOLD 3173 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...?
In all my experience, every single complex security policy I've seen has very serious issues. Complexity kills it. There's always a scenario somewhere that someone has forgotten about that breaks stuff. Heck, this even happens with access control systems like PAM. About every 3 months, we hear of a security hole where some distro has managed to ship an ssh policy that makes it possible for root to login remotely without entering a password, provided he does not have a DSA key (don't believe my word, read bugtraq!). There is no model of complex security authentication systems. There is no tool that allows people to configure this kind of stuff properly, *and check the results*. Not just write documents, but actually verify that *every case* makes sense. Consider the combinatorial complexity of that. Consider real information systems, where people either have ten passwords to remember, or they use some account that's not there, or there is some temporal incongruity between what should be and what is. (Tivoli is probably the closest there is to that in the proprietary world). In the end, you want simple security. If you need ACLs, then you probably fucked up your design, and decided to add an architectural band-aid to cater over the holes of the broken design. That said, ACLs and mandatory access control make for great security theater (see Bruce Schneier's website if you don't get the reference). It's the kind of expertise that allows consulting business to make a living in security IT. Not much actual security, though.
Just for the fun of it, some people subscribe to misc@ from politically correct accounts. So, I got a bounce on my last email, because I was saying that complex security ACLs were fucked up by design. This email is probably going to get blocked too, which is all that they deserve. Fucking retards.
man 4 systrace
does http://marc.info/?l=openbsd-misc&m=118649819926825&w=2 have any implications for whether or not to use systrace? i've found systrace to be a challenge to implement but it feels very warm and fuzzy when it works. --
the exploit requires two processes that the user controls. you can use systrace to prevent this from happening.
The first thing people do when they run with SELinux is disabling it. You decide how great it is.
A capsule summary of the situation is: OpenBSD aims to improve security by taking advantage of easy-to-use, hard-to-disable, low-overhead technologies. yes, you can disable propolice if you need to, but you have to know how. yes, you can disable random library mappings, but you have to know how. yes, you can disable W^X, but you have to try. you could turn off the security features, but why would you, since they don't get in your way, and they don't slow you down all that much. i've not seen SELinux installations (or similar technologies) that are easy to use correctly... -- GDB has a 'break' feature; why doesn't it have 'fix' too?
In terms of mandatory access controls, OpenBSD only has systrace. Every medium to large Linux deployment that I am aware off has switched SELinux off. Once you stray from the default configurations that the system distributors ship with the default policies no longer work and things start to break. In my admittedly limited experience, this happens very quickly. If the policy language was halfway sane then this wouldn't be so bad - a skilled administrator could adjust the policy. Unfortunately: 1) skilled administrators are hard to come by, and their time is usually better spent *not* tweaking brittle mandatory access control policies 2) the SELinux policy language is nowhere near sane. OpenBSD's systrace suffers from #1 - it is a generic problem with these sorts of access control mechanisms, and it is one reason why it has never been enabled by default. The brittleness is a real problem - I use systrace for a few things and often need to update my policies because of software upgrades or libc changes. Oh, and "skilled administrator" means someone deeply familiar with the Unix system interface - not a just a graduate of certification course de jour. The Linux solution to #2 seems to be to add various wizards and other abstraction between the administrator and the policy, rather than tossing the horrid mess and replacing it with something more comprehensible. I'm sure you could use SELinux to improve the security of a system but it would require quite a bit of time and effort, both initial and ongoing. -d
