Re: digitally signed distribution (was: OBSD's perspective on SELinux)
On 9/24/07, Martin Schrvder [EMAIL PROTECTED] wrote: 2007/9/24, Joachim Schipper [EMAIL PROTECTED]: Sure it does, just pull from CVS over SSH and compile your own. Only Where do I get the ssh fingerprints of the CVS servers? Where do you get the public keys for the digitally signed distributions? --- Lars Hansson
Re: digitally signed distribution (was: OBSD's perspective on SELinux)
Sure it does, just pull from CVS over SSH and compile your own. Only Where do I get the ssh fingerprints of the CVS servers? 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
Re: OBSD's perspective on SELinux
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.
Re: OBSD's perspective on SELinux
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.
Re: OBSD's perspective on SELinux
On 23/09/2007, at 3:38 AM, Ihar Hrachyshka wrote: The problem of Linux as a whole is that it tries to resolve security problems not by auditing code but by implementing SELinux. That is a really interesting statement. 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 bunch of badly tested code. 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 before doing it, which sounds pretty similar to what an SELinux policy would do. It's just at a different layer. What I'm trying to say is that all the services I listed before make their own little SELinux layer with appropriate policy built into them. Better than SELinux though is that the monitor is enabled by default and generally can't be turned off. Even more interesting is that this policy enforcement is portable to other unix like operating systems, it's not restricted to the OpenBSD kernel. So if anyone asks why OpenBSD doesn't have SELinux, perhaps we could answer that we do have policy enforcement layers in our operating system that are tied to specific services. dlg
Re: OBSD's perspective on SELinux
On Tue, 25 Sep 2007 00:08:15 +1000, David Gwynne [EMAIL PROTECTED] wrote: What I'm trying to say is that all the services I listed before make their own little SELinux layer with appropriate policy built into them. Better than SELinux though is that the monitor is enabled by default and generally can't be turned off. Even more interesting is that this policy enforcement is portable to other unix like operating systems, it's not restricted to the OpenBSD kernel. 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
Re: OBSD's perspective on SELinux
On 9/22/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: Could someone who knows both the details of OBSDs security enhancements and the details of SELinux comment? 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?
Re: digitally signed distribution (was: OBSD's perspective on SELinux)
2007/9/24, Joachim Schipper [EMAIL PROTECTED]: Sure it does, just pull from CVS over SSH and compile your own. Only Where do I get the ssh fingerprints of the CVS servers? And if I use cvsync, where do I get fingerprints? Best Martin
Re: digitally signed distribution (was: OBSD's perspective on SELinux)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Schrvder Sent: Monday, September 24, 2007 11:18 AM To: misc@openbsd.org Subject: Re: digitally signed distribution (was: OBSD's perspective on SELinux) 2007/9/24, Joachim Schipper [EMAIL PROTECTED]: Sure it does, just pull from CVS over SSH and compile your own. Only Where do I get the ssh fingerprints of the CVS servers? And if I use cvsync, where do I get fingerprints? http://www.openbsd.org/anoncvs.html#CVSROOT
Re: OBSD's perspective on SELinux
On Sun, Sep 23, 2007 at 10:54:06PM +0100, Rui Miguel Silva Seabra wrote: On Sat, Sep 22, 2007 at 06:47:46PM -0500, L. V. Lammert wrote: 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. 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 else in OpenBSD? If so, how can I do it? :) 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.
Re: digitally signed distribution (was: OBSD's perspective on SELinux)
On Mon, Sep 24, 2007 at 05:18:05PM +0200, Martin Schr?der wrote: 2007/9/24, Joachim Schipper [EMAIL PROTECTED]: Sure it does, just pull from CVS over SSH and compile your own. Only Where do I get the ssh fingerprints of the CVS servers? And if I use cvsync, where do I get fingerprints? You can fingerprint the tarballs and compare against the ones on the CD you bought to support the project ? :-) Gilles
Re: digitally signed distribution (was: OBSD's perspective on SELinux)
2007/9/24, Wade, Daniel [EMAIL PROTECTED]: Where do I get the ssh fingerprints of the CVS servers? And if I use cvsync, where do I get fingerprints? http://www.openbsd.org/anoncvs.html#CVSROOT Thanks. It's not complete (i.e. not all servers have fingerprints), but a start. This doesn't help with cvsync, though. ;-} Best Martin
Re: digitally signed distribution (was: OBSD's perspective on SELinux)
2007/9/24, Gilles Chehade [EMAIL PROTECTED]: You can fingerprint the tarballs and compare against the ones on the CD you bought to support the project ? :-) 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
Re: OBSD's perspective on SELinux
Hi,
On Mon, Sep 24, 2007 at 04:31:22PM +0100, Brian Candler wrote:
On Sun, Sep 23, 2007 at 10:54:06PM +0100, Rui Miguel Silva Seabra wrote:
On Sat, Sep 22, 2007 at 06:47:46PM -0500, L. V. Lammert wrote:
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.
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
else in OpenBSD? If so, how can I do it? :)
You solve the problem a different way:
- You don't give the guy root access, but their own userid
The guy can be some stupid binary software with an if(uid!=root) bail();
- You set file permissions so this userid can read only the file of interest
none else = find / -type f -exec chmod o-r \{\} \; is a lot of overkill
- 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.
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...?
Re: OBSD's perspective on SELinux
On 9/23/07, Rui Miguel Silva Seabra [EMAIL PROTECTED] wrote: 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 else in OpenBSD? If so, how can I do it? :) man 4 systrace
Re: digitally signed distribution (was: OBSD's perspective on SELinux)
On Mon, 24 Sep 2007, Martin Schrvder wrote: 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? 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) = fe5f2eb1b3fdbfb54103010b93f0 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
Re: OBSD's perspective on SELinux
Ted Unangst wrote: On 9/23/07, Rui Miguel Silva Seabra [EMAIL PROTECTED] wrote: 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 else in OpenBSD? If so, how can I do it? :) man 4 systrace does http://marc.info/?l=openbsd-miscm=118649819926825w=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. --
Re: OBSD's perspective on SELinux
On 24.09-10:25, Jason Dixon wrote: [ ... ] What I'm trying to say is that all the services I listed before make their own little SELinux layer with appropriate policy built into them. Better than SELinux though is that the monitor is enabled by default and generally can't be turned off. Even more interesting is that this policy enforcement is portable to other unix like operating systems, it's not restricted to the OpenBSD kernel. 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. 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.
Re: OBSD's perspective on SELinux
Rui Miguel Silva Seabra wrote:
Hi,
On Mon, Sep 24, 2007 at 04:31:22PM +0100, Brian Candler wrote:
On Sun, Sep 23, 2007 at 10:54:06PM +0100, Rui Miguel Silva Seabra wrote:
On Sat, Sep 22, 2007 at 06:47:46PM -0500, L. V. Lammert wrote:
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.
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
else in OpenBSD? If so, how can I do it? :)
You solve the problem a different way:
- You don't give the guy root access, but their own userid
The guy can be some stupid binary software with an if(uid!=root) bail();
People running arbitrary binary software requiring root on their systems
deserve what they get. You can not work around this stupidity by ANY policy.
- You set file permissions so this userid can read only the file of interest
none else = find / -type f -exec chmod o-r \{\} \; is a lot of overkill
You do not to do it everywhere, just protect what is needed (logs, data
whatever)
Most daemons in OpenBSD run isolated (chroot) in their own space without
access
to anything at all, without resorting to magic solutions, and any additional
work on the part of the administrator.
- 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.
All in all, forms of doing it all, but doing all you described creates a lot
more work than creating an SELinux policy :)
We have also systrace, which allows to create SELinux like policies.
Disregard its vulnerabilities for a moment and think about it.
What happened? (even before the vulnerabilities were announced)
Nobody used it.
No general/global repository of policies survived.
Few security tools attempted to use it.
It's only good use so far is in the ports tree, making sure
that port authors can be sure that programs did not access unwanted parts of
the filesystem. This is not a security use. It is useful as tool to help
for porters.
Why?
Every system and setup is unique. You can not define 'tight' policies and
expect them to be valid in other systems.
If you are an experienced systems administrator, you can make anything work.
Knowing the limitations and vulnerabilities, you can put systrace, to
good use as an extra line of defense.
But such complex mechanisms rarely aid the overall security.
It creates a false sense of security (tm)
Few take full advantage of it.
The rest are either turned off or misconfigured.
Most wrongly believe that they are magically protected.
Look at Windows. It has some advanced filesystem permissions stuff,
with elaborate rights, inheritance, bells and whistles.
Is it used correctly? No.
Is it easily auditable? No.
Can you easily tighten default permissions without breaking lots of
stuff? Very unlikely.
You come accross all kinds of programs using it incorrectly and create a
whole bunch of security problems.
It does make good marketing material though.
In security, complex != good.
Can
--
In theory, there is no difference between theory and practice.
But, in practice, there is.
Re: OBSD's perspective on SELinux
On 9/24/07, Jacob Yocom-Piatt [EMAIL PROTECTED] wrote: Ted Unangst wrote: On 9/23/07, Rui Miguel Silva Seabra [EMAIL PROTECTED] wrote: 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 else in OpenBSD? If so, how can I do it? :) man 4 systrace does http://marc.info/?l=openbsd-miscm=118649819926825w=2 have any implications for whether or not to use systrace? the exploit requires two processes that the user controls. you can use systrace to prevent this from happening.
Re: OBSD's perspective on SELinux
On 24.09-11:49, Can E. Acar wrote: [ ... ] The guy can be some stupid binary software with an if(uid!=root) bail(); People running arbitrary binary software requiring root on their systems deserve what they get. You can not work around this stupidity by ANY policy. that is not the case and is, in fact, the entire point of defining policy. to define what the applications on the system can and cannot do, irrespective of how stupid they (or their programmer), or how malicious they (or their programmer) is / was.
Re: OBSD's perspective on SELinux
On 9/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On 24.09-11:49, Can E. Acar wrote: [ ... ] The guy can be some stupid binary software with an if(uid!=root) bail(); People running arbitrary binary software requiring root on their systems deserve what they get. You can not work around this stupidity by ANY policy. that is not the case and is, in fact, the entire point of defining policy. to define what the applications on the system can and cannot do, irrespective of how stupid they (or their programmer), or how malicious they (or their programmer) is / was. Oh, that sounds like a recipe for success. - Run _arbitrary_ _binary_ application on system. Intend to use policy wrapper to restrict to allowed operations. - Can't figure out how to get a working policy (made harder because you can't debug the damn blob well anyway). (made harder because the ppl who sold you that application aren't going to be able to help you when you ask them why is this app doing X Y and Z? when X Y and Z are system calls they've never heard of.) - So, disable policy stuff or just allow all just to get it working. Face it; the fact that you're running the dumb binary app in the first place is because its so critical you can't do without it. Given the choice between having a mission critical app (that you probably paid good money for) crippled by the policy layer or not having to deal with it, what are people going to do? The intentions are great and look good on paper. The reality is a bit different, as others have pointed out. DS
Re: OBSD's perspective on SELinux
On Mon, Sep 24, 2007 at 11:49:20AM -0700, Can E. Acar wrote: In security, complex != good. Yes, which is one of the reasons I personally believe Visa's PCI is an extortion sham. However, some hugely influential entities happen to require those complexities, and no reason on the world will convince anyone (who doesn't know but decides) on the virtues of the KISS principle. Rui -- Frink! 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...?
Re: OBSD's perspective on SELinux
The guy can be some stupid binary software with an if(uid!=root) bail(); People running arbitrary binary software requiring root on their systems deserve what they get. You can not work around this stupidity by ANY policy. that is not the case and is, in fact, the entire point of defining policy. to define what the applications on the system can and cannot do, irrespective of how stupid they (or their programmer), or how malicious they (or their programmer) is / was. Intelligent sysadmins know every setuid binary on their system. Unintelligent ones get owned.
Re: OBSD's perspective on SELinux
On 24.09-13:48, Darren Spruell wrote: [ ... ] Oh, that sounds like a recipe for success. - Run _arbitrary_ _binary_ application on system. Intend to use policy wrapper to restrict to allowed operations. exactly, if the application cannot run within the defined policies it will not be allowed to run, this is precisely the assurance that some businesses look for. it is, in fact, a process that helps identify poor applications. whether the system is opened up or not depends on the business. The intentions are great and look good on paper. The reality is a bit different, as others have pointed out. indeed, i am one of them. and probably as painfully aware of it as any. that is not the point, writing them off wholesale is folly, and suggesting the same can be achieved with current toolsets available is just plain wrong.
Re: OBSD's perspective on SELinux
On 24.09-14:28, Luke Bakken wrote: [ ... ] Intelligent sysadmins know every setuid binary on their system. Unintelligent ones get owned. you'll forgive me if this does not sound intelligent to me. a consiencous sysadmin looks at the requirements and picks the best tools to match. in the vast majority of cases best results can be achieved with simplicity and an intelligent use of basic tools. complex policy systems have diminising returns but there is no question that they bring additional tools to the toolkit.
Re: OBSD's perspective on SELinux
[EMAIL PROTECTED] wrote: On 24.09-13:48, Darren Spruell wrote: [ ... ] Oh, that sounds like a recipe for success. - Run _arbitrary_ _binary_ application on system. Intend to use policy wrapper to restrict to allowed operations. exactly, if the application cannot run within the defined policies it will not be allowed to run, this is precisely the assurance that some businesses look for. it is, in fact, a process that helps identify poor applications. whether the system is opened up or not depends on the business. ... Whether or not the business wants to stay in business. Security policy seems like a very effective tool for Denial of Service. Burroughs Computers essentially went out of business because their computers refused to do illegal operations while IBM's computers very happily did all sorts of illegal stuff. The problem is that if you must wait for perfection, you're dead. Approaching perfection becomes combinatorially explosive. The intentions are great and look good on paper. The reality is a bit different, as others have pointed out. indeed, i am one of them. and probably as painfully aware of it as any. that is not the point, writing them off wholesale is folly, and suggesting the same can be achieved with current toolsets available is just plain wrong. It is always a case of what can be achieved with how much effort. There are many cases where people fix what they can fix, independent of where the problems actually happen to be.
Re: OBSD's perspective on SELinux
On 9/24/07, Tony Abernethy [EMAIL PROTECTED] wrote: snip Burroughs Computers essentially went out of business because their computers refused to do illegal operations This is ironic considering that Burroughs Corp was founded by William S. Burroughs' grandfather ;-)
Re: OBSD's perspective on SELinux
On Sat, 22 Sep 2007, Douglas A. Tutty wrote: 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? 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
Re: OBSD's perspective on SELinux
Burroughs Computers essentially went out of business because their computers refused to do illegal operations while IBM's computers very happily did all sorts of illegal stuff. Way off topic here... Burroughs became part of Unisys and the architecture that refused to do illegal operations still exists in products sold today. Well, its emulated on intel hardware these days, so perhaps that doesn't count. I miss coding in algol :-) // marc
Re: OBSD's perspective on SELinux
On Sat, Sep 22, 2007 at 08:38:17PM +0300, Ihar Hrachyshka wrote: 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? 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 sysadm_r role; to do so, use the newrole command. Alternately, if you switch to root using su -, you gain the sysadm_r role automatically. [4] http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/selg-section-0107.html Should an attacker gain root control, they could rebuild the policy to weaken or neutralize SELinux
Re: OBSD's perspective on SELinux
On Sat, Sep 22, 2007 at 06:47:46PM -0500, L. V. Lammert wrote: 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. 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 else in OpenBSD? If so, how can I do it? :) 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. 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...?
Re: digitally signed distribution (was: OBSD's perspective on SELinux)
On Sun, Sep 23, 2007 at 10:54:06PM +0100, Rui Miguel Silva Seabra wrote: 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. 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
Re: digitally signed distribution (was: OBSD's perspective on SELinux)
On Mon, Sep 24, 2007 at 12:35:54AM +0200, Joachim Schipper wrote: On Sun, Sep 23, 2007 at 10:54:06PM +0100, Rui Miguel Silva Seabra wrote: 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. 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. 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...?
OBSD's perspective on SELinux
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.
Re: OBSD's perspective on SELinux
On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote: 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? 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 [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: OBSD's perspective on SELinux
On Sep 22, 2007, at 12:00 PM, Darrin Chandler wrote: On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote: 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? 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. 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
Re: OBSD's perspective on SELinux
On 9/23/07, Jason Dixon [EMAIL PROTECTED] wrote: On Sep 22, 2007, at 12:00 PM, Darrin Chandler wrote: On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote: 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? 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. 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 now so (IMO) 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. 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. 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
Re: OBSD's perspective on SELinux
On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote: 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. 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
Re: OBSD's perspective on SELinux
2007/9/22, Joachim Schipper [EMAIL PROTECTED]: 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. What part of SELinux is NOT Unix? Remember that all traditional Unix rwx permissions are still there. Additionally, it's not entirely clear whether it actually helps; 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 itself. 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. Every security feature, every OS improvement IS an additional code. That's the problem of proper kernel and security policies audit, not SELinux as an idea. Joachim -- TFMotD: kadmin (8) - Kerberos administration utility
Re: OBSD's perspective on SELinux
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 On 9/23/07, Darrin Chandler [EMAIL PROTECTED] wrote: On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote: 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? 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 [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: OBSD's perspective on SELinux
On Sat, Sep 22, 2007 at 12:20:34PM -0400, Jason Dixon wrote: On Sep 22, 2007, at 12:00 PM, Darrin Chandler wrote: On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote: 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? 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. 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. 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.
Re: OBSD's perspective on SELinux
2007/9/22, Douglas A. Tutty [EMAIL PROTECTED]: On Sat, Sep 22, 2007 at 12:20:34PM -0400, Jason Dixon wrote: On Sep 22, 2007, at 12:00 PM, Darrin Chandler wrote: On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote: 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? 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. 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. 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. GPL code, isn't it? Go read it! Go find backdoors! 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. 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 bunch of badly tested code. Thanks for your comments. Doug.
Re: OBSD's perspective on SELinux
On Sep 22, 2007, at 12:28 PM, Ihar Hrachyshka [EMAIL PROTECTED] wrote: 2007/9/22, Jason Dixon [EMAIL PROTECTED]: On Sep 22, 2007, at 12:00 PM, Darrin Chandler wrote: On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote: 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? 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. 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. You can also turn off OBSD security features by lowering its level, isn't it? Only in single-user mode, not in a running multi-user system. Please see securelevel(8). Men, just say that OBSD doesn't support task-based security policies, sure. It's not so bad, not really, because most of OSs don't have it too. But please stop blaming about Linux flaws: SELinux IS in kernel mainline, so what's the problems with it, hum? It's a button. Buttons are easily turned off. Ask *any* Linux server admin. Odds are 10-1 they've disabled SELinux. --- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: OBSD's perspective on SELinux
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. On 9/23/07, Ihar Hrachyshka [EMAIL PROTECTED] wrote: 2007/9/22, Douglas A. Tutty [EMAIL PROTECTED]: On Sat, Sep 22, 2007 at 12:20:34PM -0400, Jason Dixon wrote: On Sep 22, 2007, at 12:00 PM, Darrin Chandler wrote: On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote: 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? 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. 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. 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. GPL code, isn't it? Go read it! Go find backdoors! 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. 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 bunch of badly tested code. Thanks for your comments. Doug.
Re: OBSD's perspective on SELinux
On 9/22/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: 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. 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?
Re: OBSD's perspective on SELinux
On 2007/09/22 11:50, Ted Unangst wrote: exercise for the reader: find somebody using SELinux. 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...
Re: OBSD's perspective on SELinux
On Sat, Sep 22, 2007 at 11:50:08AM -0700, Ted Unangst wrote: On 9/22/07, Douglas A. Tutty [EMAIL PROTECTED] wrote: 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. 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? 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.
Re: OBSD's perspective on SELinux
On Sat, Sep 22, 2007 at 07:45:57PM +0300, Ihar Hrachyshka wrote: 2007/9/22, Joachim Schipper [EMAIL PROTECTED]: 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. What part of SELinux is NOT Unix? Remember that all traditional Unix rwx permissions are still there. Insofar as that ls -la shows them, yes. In the sense that files actually work that way, `usually'. Additionally, it's not entirely clear whether it actually helps; 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 itself. 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 of a as a magic bullet, which it certainly is not. 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. Every security feature, every OS improvement IS an additional code. That's the problem of proper kernel and security policies audit, not SELinux as an idea. 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
Re: OBSD's perspective on SELinux
On 22.09-16:21, Douglas A. Tutty wrote: [ ... ] 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? [ ... ] 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. 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.
Re: OBSD's perspective on SELinux
On Sat, 22 Sep 2007, Douglas A. Tutty wrote: 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? 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[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: OBSD's perspective on SELinux
The first thing people do when they run with SELinux is disabling it. You decide how great it is. On Sat, Sep 22, 2007 at 11:34:33AM -0400, Douglas A. Tutty wrote: 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.
