Slashdot Mirror
OpenBSD 3.2 Readies For Release, pf Matures
An anonymous reader writes "Just over a year ago, OpenBSD creator Theo de Raadt ripped ipfilter out of the OpenBSD code leaving "the world's most secure OS" temporarily without a packet filter. Here's an interesting interview with Daniel Hartmeier, author of pf, the stateful packet filter developed as a replacement. Now just over a year old, it sounds like pf has already become a serious contendor in the world of stateful packet filtering. This interview is of particular relevance with OpenBSD 3.2 to be released on Friday, 11/1."
Codswallop, January 11th is a Saturday!
If you open yourself to the foo, You and foo become one.
Dear Slashdotters,
I decided to save you the effort of replying to this article by summarizing all of the posts you are about to make.
1) BSD is dead poster: BSD is dead! Only 13 people use OpenBSD and they all live in their parent's basements!
2) Dumb Karma Whore: Packet filtering? What's that? Can somebody explain why pf is a better packet filter than the alternatives?
3) De Raadt Hater: Theo sucks! Burn in hell, Theo, you self-righteous prick. FreeBSD 0wnz!
When they took ipfilter out, OpenBSD didn't have a packet filter. In order to address this issue, pf was written. After pf was written, OpenBSD had a packet filter. There was a time, after ipfilter was removed, but before pf was added, that OpenBSD didn't have a packet filter.
I can't say that I don't give a fuck. I've just run out of fuck to give.
Does anyone know if anyone has ported the OpenBSD pf over to Debian?
I had never before done any kernel programming, but I knew C
Great... I'm going to recommend to my boss that we replace all our FreeBSD and Linux servers with OpenBSD! With that kind of kernel programming experience on the team, you know it's gonna be SOLID! Check it.. he didn't say he "heard of" C, or "dabbled in" C, or even "thought there was a language called" C, he KNEW C! Inside and out!
And hey, did you read the interview, the man owns TWO, count 'em, TWO cats! Between the three of them, they should hammer out some sweet packetfilter code.
(hey it's a joke. but I'm still not giving up FreeBSD)
I usually don't feed the trolls, but...
OpenBSD is fucking hype. The only good thing about it is SSH.
Yeah - SSH... and isakmpd, systrace, pf, altq, chrooted apache and whole-of-tree audits.
so basically, you're saying: OpenBSD is the most secure OS out there, as long as you don't install it on a computer?
The reasons for ripping IPF out of OpenBSD are documented elsewhere, but what it basically boils down to is a licensing issue. Darren Reed, author of IPF, changed its license to something incompatible with the stated goals of OpenBSD, so it was removed. Daniel (incredibly) came up with a replacement in record time. The 3.2 release boasts a lot of things, besides improvements to PF. These includes things like a nonexec stack, a chrooted apache, a reduction in the number of setuid binaries, and more 'secure' filesystem mount options by default. Theres no sarcasm implied, I'm sure. OpenBSD truly IS among the most secure operating systems in the world.
Its already out there in the source tree... and has been for a while (beginning of october).
.tgzs from:i 386
/usr
You can grab the main
ftp.usa.openbsd.org/pub/OpenBSD/snapshots/
I'm pretty sure you can do this install by getting the floppys (.fs) files and selecting FTP install.
If you have 3.1 (or any other version) you can upgrade the source tree (this is how I did it)
set your cvsroot:
setenv CVSROOT anoncvs@anoncvs.usa.openbsd.org:/cvs
cd
cvs -q get -rOPENBSD_3_2 -P src
You can then follow along here:
http://www.openbsd.org/faq/upgrade-minifaq.html
Make sure you do all the steps,
Be especially sure you do 1.5, 1.8, 3.1.* before you do a make build..
(note: if you are doing it from something earlier than 3.1 you should do the other changes (3.0.* etc. etc.)
-- C
this information is bad, as the 3.2 snapshots are now further ahead in development than the 3.2 release code. there is no supported method for backtracking from -current to -release.
for the impatient, the best method is to check out the 3.2 sources from cvs (as described) and build from source
OpenBSD truly IS among the most secure operating systems in the world.
....
I think its probably fairer to say something like, "OpenBSD truly IS among the most secure Unixes in the world". There are fundamental security flaws with Unixes that run very deep which prevent it from being really really secure. Look at an OS like Z-OS or Eros to see how much further security can go when you break from Unix security flaws like:
- The existence of a filesystem
- Having any individual have much real authority over the system
I think the one thing that everyone absolutely always neglects to realize is that Open BSD is the absolute perfect firewall/router solution for any network. All serious networks I've ever seen or worked with use Open BSD as their router/firewall solution and for good reason, it's perfect. It's stable, secure, and BSD Free, what more could you possibly want. Open BSD is made for security and it does its job wonderfully.
Ignore the "p2p is theft" trolls, they're just uninformed
What I don't get is why don't these projects realize the kind of coup they could score by releasing a Mandrake/RedHatesque installer that even the average marketting drone could use to setup a fully operational installation. I'd love to use OpenBSD if I thought I could get it working. I'm still just a novice with *NIX though so some of this is a bit too hardcore for people like me right now. But still, getting OpenBSD an installer that **just works** for the average person would take it to a whole new level.
you break from Unix security flaws like: ....
... I can't do anything with my computer; and even if I could there's nothing I could do it to.
- The existence of a filesystem
- Having any individual have much real authority over the system
That sounds really bloody useful
If you don't mind, I'm off to assert my authority over some files now ( TieMeUp.Jpg doesn't know what is has coming!)
Excellent interview and responses, a very educational read for anyone who deals with firewalls and packet filtering. It should become part of the pf docs.
He is very modest, but I like the sounds of some of the things he is doing. Here are some solid, specific things pf is doing that I dont think other packet filters are doing, ask your vendor how they are handling these same types of issues.
This is why pf sounds like it will be very good (direct quotes from the article):
Wax on, wax off baby!
A lot of very high end stuff runs on systems with distributed administration (like most of America's transaction processing, accounting, etc...) Back in the late 70's - early 80's capability systems were a huge percentage of the market.
You don't need a file system to have data -- for an example you are likely familiar with think of palm OS. Data is just stored in internal program specific data structures and "swapped" out of ram to disk. The important thing is that the disk is just a bunch of sectors with a zillion different data formats; but to understand the organization of the date requires running the system which imposes the security model...
only the -current development branch was lacking a packet filter. obviously the stable branch and existing installations still had a functioning packet filter implementation. also note that ipf patches were made against OpenBSD CVS after theo pulled it, provoking a somewhat amusing debate on misc@.
no, there was not. OpenBSD 2.9 included ipf as the packet filter. OpenBSD 3.0 and 3.1 included pf and lacked ipf.
at the other end of this envelope is Bell Labs' Plan 9 which carries the UNIX principle that states "everything is a file" to the logical extreme while distributing privileges sanely, unlike UNIX with its all-powerful root. apparently this system runs a significant portion of the telephone systems in the US, at least. the design principles are sound, anyway; witness Sun's Trusted Solaris and the DARPA-funded TrustedBSD project.
If usability is what you're looking for, try FreeBSD instead. One of OpenBSD's goals is to be Secure by Default. Whereas other BSD variants and most Linux distros take an approach of 'turn everything on and let the admin turn off what he doesn't need', OpenBSD takes the opposite approach. In my experience as an admin, theres no difference in effort between locking down, say, a Redhat install, or enabling what I need after install on OpenBSD. The difference is, the more clueless among us will be more protected by the default install of OpenBSD than by Redhat.
If you actuaky read the interview, pf appeared in the 3.0 release. Which is about a year ago.
psxndc
The emacs religion: to be saved, control excess.
but to understand the organization of the date requires running the system which imposes the security model.
NO, that would simply be security through obscurity which does not work. Any modern capabilities based OS would have strong cryptography at its core so that you could not access those data items that you do not have a key to. In fact a cool way to do it (not sure if this is done in any real system) would be to have 2 keys, one for the runlevel and one your private key which is protected by your login, that way you could not access things outside your runlevel and you could not access other data in your runlevel unless it was explicitly given permission to you by using your public key (think ACL's but the creator of the data would have to add your key to the files encryption)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Cryptography is obvious. The problem is how do the apps get their keys? If you have a file system then the keys are stored in some file and so someone else can get the keys....
OTOH if the app stores the key in memory and is always running (though possibly swapped out) then you don't have any problems with storing keys securely.
Remember capabilities are useful but you also have to secure the system against someone just taking the hard drive out.
As for your ideas with dual keys it is done (hate to mention this) but for example Palladium uses that strategy (though they don't call it run levels)
Wow.. you know you've been doing too much electronics homework when you look at "pF" and read it as "picoFarad" and wonder what that had to do with anything....
You can grab the main .tgzs from:i 386
ftp.usa.openbsd.org/pub/OpenBSD/snapshots/
Those are snapshots of 3.2-current, not of what will be released as 3.2.
I don't know about Z-OS, but I've read a little about EROS. EROS doesn't need a filesystem. That's because everything in EROS is persistent. The system saves a complete snapshot of its virtual memory to disk every couple of minutes. There is no "rebooting" of the OS. If you pull the plug, it comes back up exactly in the state of the last snapshot.
For me, it took a little while for that concept to sink in. They're saying that there's no need to redundantly keep information in permanent storage and volatile storage. Just make it all permanent, and you don't need the filesystem concept at all. In one step, you eliminate whole classes of bugs (parsing, file permissions, sharing files, filesystem namespace problems, etc.)
Their authority model also makes sense. Think of your system as a large building. Normal OSes treat security like doors with electronic badge readers; you're allowed to do things based on who you are. Naturally, a lot of doors must be programmed to let you through if you're going to get around the building to do your work. It's hard to ensure that each person is never able to get into a room that they shouldn't be in.
EROS is more like a building full of unique old-fashioned key locks. You have no automatic authority to go through any door. You must obtain the individual key for each door. You get these keys on an as-needed by the people in various rooms you interact with as you do your work. Each person with keys to hand out individually determines if you are worthy to go through the next door.
Reading up on EROS really expanded my view of how an OS could work. You can check it out at www.eros-os.org.
Yes, VMS had bugs, but they were all very well-documented. Consult manuals B-127J0 through B-141J7 for more information.
The article is one of the best resumes I've ever seen.
Look at an OS like Z-OS or Eros
....
Which sites are run off of these operating systems? Which organizations run these operating systems? Or are they merely theoretically secure, with little use under fire?
Having any individual have much real authority over the system
Back to real life, short of hard cryptography, one individual usually has complete access to everything on the system. If I can run another OS on the system, I can copy or change anything and everything. Without custom hardware or always having to have someone else with the admin in the computer room, sooner or later the admin will get the chance to boot into god mode and do as he wills.
the project is not commercial, and has no dreams of having millions of users. it only seeks to do what it does well - which it has for some time.
most of the users and all of the developers would probably scoff at the idea of upgrading the installer because development resources aren't cheap, and they feel the time would be better spent elsewhere since the installer does work just fine.
the 'rustic' install (complete with MANUAL PARTITIONING!!!) serves as a barrier to entry, keeping the mailing lists more clean of 'how do i mount a floppy?' questions.
The article is one of the best resumes I've ever seen.
Prospective employer: What have you done?
Daniel: I wrote the stateful firewall in OpenBSD. Here's a kerneltrap.org article.
Employer: (Silence while recovering from amazement.) What pay do you expect?
I hit a key accidentally, and Mozilla posted my comment above.
You are missing all the bugs that might be in the code still running as uid 0. Your daemons, the kernel, all of them are vulnerable. I haven't seen many exploits that actually get root by doing "su" to it, so "disabling" that account will not achieve more than, for example, a good password.
A "secure" OS in this context means an OS with well-known "clean", stable code that has been reviewed for flaws etc etc. There isn't much you can do from an administration point of view if the services/daemons you have to use are flawed.
I think sprinkling setuids around is not a great idea at all. Especially custom-written ones. Beautiful things can happen accidentally linking against the wrong library in a chrooted dir :)
Chroot is *not* 100% secure. It is not a sandbox. You can still access ports, memory and processes and kernel functions, you can talk to daemons, starve the system of resources or convince the parent process to do things it will regret.
Plus if you chroot users you'd still have to give them most of the OS somewhere unless they login to not do any work, and that will soon get boring when you'll have to upgrade all of it.
A truly secure machine requires hardware support. A better CPU design. If the 8086 did not mix stack with code and data we would not have had so many problems today.
What's your definition of an easy installer? I would rather have something functional over easy/GUI. When I first installed OpenBSD I had only used Debian since then (only for a year or so). I printed out the entire FAQ and read it back and forth whenever I had some free time. If you read it, you will notice that it walks you through the entire installation procedure. If I was able to install OpenBSD using their excellent text installer just by reading the documentation available on their site then I'm sure anyone (who's willing to do research) can. It also helps to have an old box to install on first, play around, install again.. rinse and repeat as required.
Cool Mac software that I found while looking for info: ssh and sftp for mac with SSH2 support. License? Well, there's a GNU head on the website :)
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes ,
can anyone recommend some sites where there is some intelligent discussion of bsd news and issues
I prefer mailing lists. In fact, after signing up to some interesting OpenBSD lists (mostly just reading) I found I was reading OpenBSD a lot less and reading www.deadly.org a lot more (and wishing it had a lot more articles and discussion).
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
Bugger, sorry. That should read "I found I was reading /. a lot less and reading www.deadly.org a lot more".
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
I didn't think so.
disclaimer for the humor impaired: I don't actually want to root this guy's box. I am not a terrorist, nor a member of al-qaeda.
Life is too short to proofread.
Go to your slashdot preferences, the homepage tab, and on the lower part of the page is "Customize Slashboxes". Enable some of the bsd sites to see their headlines while reading slashdot.
Like Shanep said, OpenBSD Journal (at deadly.org) is a good one.
Got brain?
While it's true that one may not come across a Mainframe-based webserver on the internet, they still rule the datacenters, and are generally considered pretty secure.
RTFFAQ:
http://www.openbsd.org/faq/faq8.html#wwwsolaris
8.18 - Why does www.openbsd.org run on Solaris?
www.openbsd.org and the main OpenBSD ftp site are hosted at a SunSITE at the University of Alberta, Canada. These sites are hosted on a large Sun system, which has access to lots of storage space and Internet bandwidth. The presence of the SunSITE gives the OpenBSD group access to this bandwidth. This is why the main site runs here. Many of the OpenBSD mirror sites run OpenBSD, but since they do not have guaranteed access to this large amount of bandwidth, the group has chosen to run the main site at the University of Alberta SunSITE.
An embedded, dedicated solution?
Don't get me wrong, though I've personally not used a BSD as a firewall, I know people who have, and they're happy with it, completely happy. But I really prefer something which was built from the ground up to be a firewall and ONLY a firewall.
I've worked extensively with the Sonicwall devices, and I've also heard some good things about the WatchGuard Firebox series. Then again, if you want to go gung ho all out and out, you can get a Cisco PIX.
Basically, for me, it boils down to having a specific device for a specific job, as opposed to having a general purpose piece of software running on commodity hardware for a specific job.
And what's up with that "the most secure os" sarcasm? OpenBSD *is* secure.
.. 2 things:
This definition depends on what you call "secure".
Theo calls an OS with a very limited, trusted set of applications "secure" - however, running secure applications with root privileges has nothing to do with OS level security. That's application level security.
I'd call an OS secure, if you can only hack it by exploiting a bug inside the OS kernel. That means, there is no way of gaining 'root' privileges or something like that by hacking into some highly privileged daemon, provided that the system is configured properly.
To achieve this level of security, it is neccessary to have fine grained privilege and compartmentalization controls instead of the superuser/world distinction built into the OS kernel - and that's still missing in OpenBSD.
What means "secure"?
"[...] Put another way, "secure system" means safe enough to protect some real world information from some real world adversary that the information owner and/or user care about. [...]"
- SE Linux FAQ, NSA
-----
There are mainly two types of secure Operating Systems.
a) Everything up to the C2 level of security
b) Everything from B1 up to A1 (never ever reached by any OS)
The difference is information labeling.
You only get a B1 security certificate, if your OS has mandatory access controls. It must be able to automatically prevent users from mixing secret data with public data. This is often called a "Trusted OS".
Most people don't need information labeling/mandatory access control, because all their data has the same level of sensivity.
TCSEC C2 does not say much about how the OS has to handle privileges, so a C2-level OS can still be very insecure, but it can also be very secure - almost impenetrable - and it still can't ever become certified at B1 or above, because it simply can't handle multiple levels of sensivity.
-----
Let's look at NON-Trusted-OSs first, because most people don't need a Trusted OS:
OpenBSD lacks an uninterceptable audit trail and access control lists as required by TCSEC C2. It distinguishes between world and root privileges.
VMS has an audit trail, access control lists, and a privilege model.
AS/400s have an audit trail, access control lists, a privilege model, an object-based security model with type enforcement and hardware-supported pointer-in-memory-protection because of the single level storage address space, but that does not matter much (think about it as something which is similar to protect-mode on an x86, but based on objects and pointer to objects instead of segments and segment descriptors).
VMS is clearly superior to OpenBSD, mainly because of the privilege model. If a process does not have many privileges, then an attacker can't gain many privileges by hacking it. Simple, isn't it?
An AS/400 is (VMS users listen carefully) clearly superior to both, OpenBSD and VMS. It has a superset of the security features of VMS, and additionally it has object-based protection. Therefore, you can't write to a program object, and you can't execute a data file or things like that.
Now let's look at Trusted OSs:
SE-VMS has an audit trail, access control lists, a privilege model, information labeling and compartment mode.
Solaris with Argus Pitbull has an audit trail, access control lists, fine grained privilege controls plus inheritance rules (proxy privilege sets and so on), a trusted computing base, information labeling and compartment mode (mandatory access controls).
Both are clearly superior to the non-trusted OSs mentioned above, because applications can be totally separated from each other by putting them in separate compartments.
If someone hacks into an application in compartment A, then he/she still can't access an application in compartment B, so he/she is locked down into a jail.
Solaris with Pitbull is clearly superior to VMS, because of the much more sophisticated privilege model. It's more fine-grained and it has inheritance controls, so certain applications will only gain their privileges if they can inherit those privileges from another process. By default, executing another application always drops all privileges.
-----
What I'd like to say is
1. What about "OpenBSD is the world's most secure OS"? It has a pretty good verified kernel, but it's security mechanisms are simply not powerful enough. A bug-free kernel does not help alot, when you have to run things as root, because the kernel does not have appropriate security mechanisms like privilege controls or compartment mode...
2. What about "Unix can't be secure"? I get really bored by VMS users comparing Standard-Linux with VMS; maybe compare the most secure setup of either Operating System and then let's talk about security again.
HERE is TCSEC B3 certified Unix (Linux-compatible, too).
regards,
octogen
psxndc
The emacs religion: to be saved, control excess.
How will this Unix installation be less secure than OSes you mentioned?
If you have physical security, nobody will be able to actually login as root
What am I missing? [reordered by editor]
What you are missing is that the OSes I was mentioning assume an administrator might be in on the data theft. That is you don't have physical security; so you need to protect the system against someone simply copying the data directly from the harddrive.
What you list creates an OS which is very secure againt any sort of user attack. BTW openbsd is actually moving towards what you described with lots of the setuid processes chrooted.
Its due to the intended audience/market.
If the installer is too complex/confusing for you, then you are not the intended audience.
Not meant as an insult, just reality.
OBSD isn't intended for the 'average' person, but one slightly above that level.
---- Booth was a patriot ----
People have already commented that pretty much every major organization runs Z-OS :-) As for Eros its based on the ideas of Multics which were used by many organizations as well as the US Army for secure computing. Until recently (late 70's-95) the direction was away from security and this was the period where Unixes thrived. Its only with the pervasive internet and the desire to create systems robust enough to handle constant attack from hostile users that security is making a strong come back.
Anyway as for cryptography; cryptography itself doesn't solve your problem. Where are the keys stored? If they are stored on hardware you can pull the keys off pretty easily by just picking your data; if they are stored in a hardware / software mix then the software component can be taken off by a root user.
That's why no filesystem is important. Sure you can boot into god mode using some other OS but you won't be able to understand the data since the data itself is owned by applications the cryptograhy keys are mixed at multiple levels... In other words to get to the data you need to boot the OS and then you get the OS's security. The box in a raw form can't extract the application specific data, so god mode doesn't do you any good.
Where are the keys stored?
In the only safe place: the users' head.
In other words to get to the data you need to boot the OS
You could have said that about NTFS, before the Linux NTFS filesystem. If software took it apart, then software can put it back together - if necessary, take the OS, remove all security code, and boot that.
Is what you are describing really true? Your talking got a little bit fast in the last paragraph. If I can boot in another operating system I can see all the data on the disk (Having no filesystem is just a red herring - the data is still there). The machine will bootstrap through normal BIOS procedures (at least in EROS which is i386 based). So I can follow all the code through.
The question then arises as to whether when the code wants to check for its first key, whether I can get that key or not. I'd wager that if booting EROS normally, someone has that key then I'd be able to get the same key when shadowing from a separate operating system
In other words what you say smacks of security through obscurity, though feel free to show me otherwise.
Special Relativity: The person in the other queue thinks yours is moving faster.
I live in my girlfriend's parents basement
and my openbsd server is humming along right beside me, can i be lucky #13?
In the only safe place: the users' head.
.45 semi-auto that can remove even those keys, one way or the other. They can either come out of their mouth or fingers, or then theres the other option, splattering those keys all over a wall. ;)
I have a
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
Maybe your analagy is just bad, but I'm not sure how a central key authority is inherently any more secure than a distributed one. If I get this right, you "knock" on the door and see if the person inside lets you in. This sounds very much to me like object level security permissions, which isn't really any different than file-level permissions. One of the reasons why we invented things like group level permissions was because of the administrative nightmare associate with individually coding security into every object, so I don't see how this is really a gain...
OpenBSD is dying, because Theo has a cold.
Heh...just kidding. But really, we're too dependant on him, and his whims. We need a less ego in the BSD world. Theo DeRaadt, Darren Reed, Dan Bernstein et al can be fine programmers but what's the damn point if they can't get along. OpenBSD's development has too much power concentrated in the hands of too few people. This leads to all sorts of boo-boos and the inability to maintain older code (3.0 just died...ugh!).
I think that licenses are important. They need to be unconfusing. Project developers should find an existing, popular, and well understood license that most closely suit their needs and put their work under that license, rather than create their own. Here is where I fault DJB and Reed for their licensing quirks.
What license is irritating me the most right now is PINE's.
Daniel has a mirror of the interview at his site.
Here is an example
1 - Every program keeps its data in memory
2 - the virtual memory system uses encryption
3 - programs use a private encryption key when passing live ram to the virtual memory system
(so in effect data on the drive is double encrypted).
4 - there is no true "shutdown" just something that acts like NT hibernate
You shut the system down / hibernate. Remember there is no file system and the allocation blocks table in ram (like for a virtual memory system) so without restarting the OS all you have is double encrypted sectors of harddrive in no reasonable order without a clear key.
Think more like the virtual memory system then the NTFS filesystem. The data to interpret the filesystem isn't stored in a truly fixed place in a regular manner.
As for encryption stored away from the system; any data that the system itself can't access might as well be public you don't need security for that kind of data.
I'll grant you can rip the disk out and copy and image. I'm not trying to argue you can't get to the disk. Its the "red herring" I'm arguing is helpful. Because once you get the disk image what does that get you? You have disconnected blotches of data encrypted in a range of ways and stored in applications specific ways. Pretty nasty stuff.
I agree there is some obscurity involved but essentially this amounts to the computer equivelent of encryption + shredding. That's pretty yucky to deal with. Yes with infinite time and money you can beat it but...
Legalize the constitution. Think for yourself question authority.
Bull. OpenBSD is a blank slate, it is as secure as you choose to make it.
/dev/null is exploitable, you really can't use a blanket statement that Unix systems are flawed.
If you want to set all your programs to run as root, you can do that, though it will not be secure.
If you want to run your services as non-privlidged users and seriouly limit it's permissions, you can do that as well.
If a service needs root pormissions, you can go the way of OpenSSH, and give it privlidge seperation.
You can have any system in place that you want. The only common denominator in 'Unix' is it's method of most everything being a file or a system call. So, unless you believe that something like printf() or
Root's privlidges can be shared, and then you can make it so no one can login as root. And I fail to see how having a filesystem leads to insecurity.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
That's completely false. By no means do you need to run anything with blanket root permissions. systrace works great, chroot does fairly well, and you can run many services as a normal user.
Most services I've seen don't just chroot themselves... the almost always drop their root permissions, meaning it's running as a normal user, inside a chroot. There's very little an attacker can do with that.
Why would you want to chroot users? That doesn't make much sense to me.
That would only make overflows more difficult (OpenBSD has a non-exec stack), and even then, it wouldn't address any of your concerns.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Think more like the virtual memory system then the NTFS filesystem.
And you dump the virtual memory, I can piece it together. First you find the kernel, then the page and process tables, and then you can put the rest together without much trouble.
Agreed. If you go to that much trouble (i.e. multiple application specific file systems / data systems) you can get the data out. Any security can be broken given a large enough quantity of the product of:
:-)
inside knowledge * time * money
the goal is just to boost that figure
Any security can be broken given a large enough quantity of the product of: inside knowledge * time * money
:-)
the goal is just to boost that figure
But standard cryptography, given a secure password, achieves more security, without changing all the base rules.
All you are saying is given code and data that people can't reverse engineer. This is blatantly not true. Now because EROS is not mainstream there won't necessarily be any script kiddie tools to help you out, but we aren't talking the kind of infinite time and money scenario here, we're not even talking the long time that encryption gives you, unless there is some reason why its not just (albeit hard) reverse engineering.
Now whether EROS and a physical security policy is more secure, or easier to secure than another OS and a physical security policy is a different argument.
Special Relativity: The person in the other queue thinks yours is moving faster.