Slashdot Mirror

For example, file system snapshots and rollbacks

NetBSD does this in a filesystem-agnostic way with its Filesystem snapshot device

Why build the functionality into one particular filesystem? Oh yes, poor design.

I think any OS will do it once the attacking program can gain root access

Nope, I don't think so. (see securelevel 2)
(and nope, you can't defeat it *that* way. (see RB_HALT)).
It's kind of notable that neither Free- nor OpenBSD seem to support an equivalent to the latter (all three do have the securelevel mechanism, though).

unless MBR protection is enabled in the BIOS

Are you living in a distant past where disk i/o still goes via BIOS?

I think any OS will do it once the attacking program can gain root access

Nope, I don't think so. (see securelevel 2)
(and nope, you can't defeat it *that* way. (see RB_HALT)).
It's kind of notable that neither Free- nor OpenBSD seem to support an equivalent to the latter (all three do have the securelevel mechanism, though).

unless MBR protection is enabled in the BIOS

Are you living in a distant past where disk i/o still goes via BIOS?

If they have root there are plenty of other things they could do which would be far simpler.

Yep, but ironically loading kernel modules is not one of those things, as root cannot just load a kernel module without taking the machine single-user.
(Yes, the link is about NetBSD's securelevel, but all the BSDs have this/an equivalent 'securelevel' mechanism)

NetBSD's rc-system über alles!
http://netbsd.gw.com/cgi-bin/man-cgi?rc.d++NetBSD-current

When I have learned unix, man pages were complete, concise, accurate and uptodate documentation of all the system. I feel that because of this textinfo mess, man pages on Linux are incomplete and vague and that the documentation dislayed by info is not very clear.

Have you tried to continue using unix?

Putting an @reboot entry in the user's crontab would start anything you want when the machine boots, without the user even logging in.

...and would do so not only on OS X, but on many Linux distributions and FreeBSD and NetBSD and OpenBSD and....

It's been a long time since I had time to browse any of the code repositories out there, but last time I looked, the BSD people (Free, Net, Open, ...) all had their own BSD-licensed unixy command-line tools.

Speaking as a NetBSD user (and developer) we do have something that looks similar to busybox under /rescue, a statically linked binary which acts differently depending on how you call it. See the "list" file at cvsweb for common utilities included and the build seems easy enough to configure your own utilities as required. rescue(8)

FreeBSD at least has a simlar tool, not sure about OpenBSD..

From the ipsec(4) manpage for Mac OS X 10.6, history section:

The implementation described herein appeared in WIDE/KAME IPv6/IPsec stack.

The KAME stack is the same stack used in NetBSD and FreeBSD.

Even though NeXTSTEP was forked earlier from the BSD codebase than the other BSD flavors there has still been considerable sharing between it, Mac OS X, and the other BSD flavors. OpenBSD is one exception to this since it tends to be a more closed ecosystem than the other BSD variants.

There have been various projects using L4 to isolate Linux or Linux drivers in VMs, so it's a logical thing for them to do too.

Cool. FWIW, the situation is much worse with Hyper-V than it is Xen. :-)

I was hopeful about their use of L4, as its known to be (capable of being) very fast. I'm really not sure where (if anywhere) they're going now; they do seem to lack a strong lead / direction, which like everything has both benefits and costs.

Yeah, IIRC, they ran into a major show-stopper with L4 and the current design that put things on hold. Some of the developers were working with Jonathan Shapiro on the Coyotos project at CMU; I'm not sure anything concrete came of that. Might be a moot point, anyway, since Shap's off to Redmond.

I didn't know NetBSD had Mach compatibility - do you mean it can run on top of Mach? That's cool. I don't, to be honest, know a whole lot about Mach - and to make things more complicated I have the impression there are several versions floating around out there.

COMPAT_DARWIN

Not sure how close this is to being production-ready with the ongoing enhancements in OS X, but they'd made pretty good progress around the 10.3 stage. Much of the NeXTstep model used Mach IPC for message passing (think about how ObjC works!). NetBSD had to emulate the Mach facilities in-kernel to build this in. If someone cared, they could probably do a COMPAT_NEXT for m68k, etc. Not sure how many of the features would need to be added to support the Hurd daemons.

There's not been enough that's different about DragonflyBSD to get me running it just yet but that may change.

I played around with some of the early versions, but haven't touched it much lately to try out the nifty new features. Most of the things I used BSD for I converted from FreeBSD to NetBSD around the time that Matt stood up DF. Probably would have been easier in hindsight, especially the community machine I help maintain, but I didn't think it was quite ready for primetime back then. Been very, very pleased with NetBSD, however. Certainly much better quality in my experience than FreeBSD later than version 4.

Surprisingly perhaps, the NetBSD uvideo driver might get out first, whenever NetBSD-5 solidifies.

OK, found out that the tool is called crunchgen, [....]

Yes. I found this old-ish article handy for actually using it. But there are also articles that discuss how to reduce the libc size as well.

OK, found out that the tool is called crunchgen, and that its main purpose is efficiently combining multiple binaries into one (although I've read it could be used for building efficient libs, too), so it is more like an alternative to BusyBox multi-app binaries.

In a sense NetBSD event ran Linux before the Xen support - well, Linux applications at least. There's Linux emulation built into the kernel that allows it to trap system calls from Linux binaries and translate them to NetBSD equivalents. Before the availability of a native Sun JDK, this was the way to run Java on NetBSD.

I find NetBSD's RAIDframe to be very reliable and hassle-free. I'm using RAID-5 with 5 disks and get 110MB/s reads and 70MB/s writes. It also never gave me _any_ headache whatsoever. It just works.

I think software RAIDs are better than hardware RAIDs (for home use) due to their flexibility. You can mix different disk interfaces (IDE, SATA, SCSI, ...) and sizes. If one of my 320G disks were to fail and a new disk was more expensive than the next bigger size, I could just use the bigger disk. It's a stupid example to show that you don't need components that are identical down to the number of blocks. I could also just pop in an external USB disk and use that while I get a replacement.

Or I could gradually upgrade to a new tech. Say I'm using IDE disks now. I could pop in SATA disks and duplicate all components and be running a SATA RAID from now on.

Also, you are not dependent on a $$$ piece of hardware that's incompatible in its RAID implementation details to other vendors' products. If your vendor goes out of business and your shiny hardware controller is not available anymore, what do you do? Contrast that to finding any box that can talk to your disks and downloading a copy of NetBSD.

Of course I'm totally ignoring backups. I'm talking about home use in the order of 1TB or more. Where do you backup such amounts of data cheaply, anyway? Thus for me, RAID _is_ the backup, unfortunately. That's why I favor flexibility and accessibility over speed or being able to hotswap a component to get 99.999% uptimes.

What do I get by installing this that I can't get in a 2 year-old Gentoo Linux installation? The BSD's have always been a bit of an enigma to me. Could someone enlighten me?

firs of all, nobody is trying to make you switch. the BSDs aren't out to conquer the world (AFAIK), they just try to make proper operating systems.

second, you get:

• totally sweet firewalling, with ipf and pf
• proper package management with pkgsrc (your beloved portage? that's where it gets its roots)
• the ability to run the same configuration on dozens of different archs (that might not sound like much, if you only run i386, but there's people with lots of different gear out there)
• a clean, small, stable base system which includes everything you need to get your server going in a few minutes (literally, NetBSD installs in 2 minutes, even on old hardware) -- you can build on top of that, with pkgsrc or prebuilt binary packages
• run your favorite proprietary applications through the emulation layer (compat Linux, compat WIN32, etc)

and many more. you can read in detail on the project's feature page. that being said:

10:49:47 (1.15 MB/s) - `i386cd-3.0.2.iso' saved [209747968]

What do I get by installing this that I can't get in a 2 year-old Gentoo Linux installation? The BSD's have always been a bit of an enigma to me. Could someone enlighten me?

firs of all, nobody is trying to make you switch. the BSDs aren't out to conquer the world (AFAIK), they just try to make proper operating systems.

second, you get:

• totally sweet firewalling, with ipf and pf
• proper package management with pkgsrc (your beloved portage? that's where it gets its roots)
• the ability to run the same configuration on dozens of different archs (that might not sound like much, if you only run i386, but there's people with lots of different gear out there)
• a clean, small, stable base system which includes everything you need to get your server going in a few minutes (literally, NetBSD installs in 2 minutes, even on old hardware) -- you can build on top of that, with pkgsrc or prebuilt binary packages
• run your favorite proprietary applications through the emulation layer (compat Linux, compat WIN32, etc)

and many more. you can read in detail on the project's feature page. that being said:

10:49:47 (1.15 MB/s) - `i386cd-3.0.2.iso' saved [209747968]

One disadvantage is that it deals with whole file systems

NetBSD's dump supports files too, not just filesystems.

sure they do.

The future is now systrace does everything you say and more, and been around for a while now. It's NetBSD only, but will most likely spread in its availability.

There are many similarities between FreeBSD and NetBSD thanks to their mutual heritage, but FreeBSD's documentation doesn't usually apply equally to NetBSD. The differences are well covered in NetBSD's own online documentation, though.

• nsswitch.conf(5)
• rc.d(8) (which FreeBSD incorrectly refers to as "rcNG"). I have a paper about this.
• dynamically linked world
• /rescue
• the enhanced ftp(1)

• dynamic module support in nsswitch
• PAM ("soon")

There are many similarities between FreeBSD and NetBSD thanks to their mutual heritage, but FreeBSD's documentation doesn't usually apply equally to NetBSD. The differences are well covered in NetBSD's own online documentation, though.

• nsswitch.conf(5)
• rc.d(8) (which FreeBSD incorrectly refers to as "rcNG"). I have a paper about this.
• dynamically linked world
• /rescue
• the enhanced ftp(1)

• dynamic module support in nsswitch
• PAM ("soon")

There are many similarities between FreeBSD and NetBSD thanks to their mutual heritage, but FreeBSD's documentation doesn't usually apply equally to NetBSD. The differences are well covered in NetBSD's own online documentation, though.

• nsswitch.conf(5)
• rc.d(8) (which FreeBSD incorrectly refers to as "rcNG"). I have a paper about this.
• dynamically linked world
• /rescue
• the enhanced ftp(1)

• dynamic module support in nsswitch
• PAM ("soon")

NetBSD Nightly Trouble Ticket Report

Subject: NetBSD Nightly Trouble Ticket
Date: Nov 03 2004 20:00:18
There are 3509 non-confidential bugs in 59 categories.

Category - critical - serious - non-crit - TOTAL
admin 0 1 3 4
bin 22 222 362 606
install 12 38 57 107
kern 201 585 405 1191
lib 4 62 73 139
misc 1 20 96 117
pending 2 0 0 2
pkg 44 247 353 643
...
port-amd64 4 4 0 8
...
port-i386 30 95 56 181
...
security 0 7 11 18
standards 1 6 24 31
toolchain 2 28 29 59
xsrc 3 13 13 29
TOTAL 401 1523 1585 3509

open4free © :^(

Except that NetBSD is slower in basic operations than Linux, like network packet tx/rx overhead, syscall overhead, context switching, fork, page fault, page allocation, etc.

Really? Show us. No, I'm not saying you're wrong (I saw an *old* bench showing that Scheduler Activations had pretty slow context switching compared to Linux, and a note saying it would be worked on), but I just haven't heard of this, let alone seen conclusive and objective figures to back it up.

On a related note, I don't think anyone is arguing that Linux has a very fine grained and high performing core, it's everything around it. In much the same way, FreeBSD 5.x now has a very tight core, but the locking design and the number of things still Giant-Locked make the system run fiendishly slow anyway. You only notice these things in practice, and I have in fact noticed similar behavior with Linux (compiling two things at the same time - no, not using -j - can be a real exercise in patience)

On a related note, http://news.gw.com/netbsd.ports.i386/%3C2004072610 2903.GA21256@antioche.lip6.fr%3E
Linux gets slower using SMP on HTT (2.6.6, as I recall, the first mainline kernel to gain hyperthreading - please correct me), NetBSD gets faster. I think that, considering this, NetBSD'S SMP/SMT support is quite alright, and would be even better when hyperthreading scheduling policies are developed. Unless anyone shows figures that disprove this, of course... (invitation)

Solaris has a poor threading implementation, even Sun's own engineers admit that. However, that shouldn't be taken as proof that all M:N implementations are poor. In a demonstration at BSDCon Japan 2003, NetBSD's scheduler activations outperformed FreeBSD 5 and Linux NPTL. See the tech-misc mailing list thread that starts from here: http://news.gw.com/netbsd.tech.misc/701.

-n Do not flush the file system cache. This option should be used with extreme caution. It can be used if a disk or the processor is on fire.

lol.

You might want to give NetBSD a shot at it. It's not quite emulation (NetBSD actually supports foreign binary compatibility as if it were a native application), and when it works, it works great.

From the compat_svr4(8) man page:

NetBSD supports running SVR4/iBCS2 binaries. This code has been tested on
i386 (with binaries from SCO OpenServer and XENIX), m68k (with binaries
from AMIX) and sparc (with binaries from Solaris) systems. Most programs
should work, but not ones that use or depend on:

kernel internal data structures
the /proc filesystem
the ticotsord loopback RPC mechanism (NIS uses this)
sound and video interfaces
threads (ttsession uses threads)
the streams administrative driver

SEE ALSO
termios(4)

In NetBSD kloader(4) does a similar job. It is used on HPC and game console ports.

Add to that the fact that a BSD system will not automatically upgrade your /etc, then you have the best reasons that say, a Debian box is easier to maintain.

Your BSD is clearly not my BSD, or else you'd know about etcupdate. Having discovered first hand the "joy" of Debian's installer and lack of backwards compatability between releases, I think I'll steer clear of it.

Chris

I'm not sure with Open and Net haven't imported it [mergemaster] yet

NetBSD has etcupdate, although I've never used it myself, as upgrades rarely touch the files in /etc that I modify. That's the beauty of NetBSD upgrades, the developers are very careful about backwards compatability. I could even run 4.3BSD binaries if I wanted to (not that I would), by enabling the correct system call compatability in the kernel.

Chris

That project certainly deserve the "coolest name" award. Basicly it's the freebsd equivalent of ndiswrapper to get wireless chips to work.
It's remarkable how applicable this name is :)
Here is a more detailed description.

portalfs

Plenty of people
have gotten it to work

http://news.gw.com/netbsd.advocacy/3435
SCO update: "Issues with BSD" ?

[netbsd.advocacy]

Subject: SCO update: "Issues with BSD" ?
From: mac@Wireless.Com (Mike Cheponis)
Newsgroups: netbsd.advocacy
Organization: TAC News Gateway
Date: Jun 16 2003 23:47:18

Hmmm.... SCO is certainly making life unpleasant for many. -Mike

From BYTE.COM newsletter:

________
1. Special Feature: SCO Owns Your Computer
________

Fittingly, it was Friday the 13th. A sunny San Francisco morning.
But my discussion with Chris Sontag, SCO's Senior Vice President,
Operating Systems Division, was driving the sunshine from our
room, creating an atmosphere appropriate for the 13th. Let me
summarize in a parable...

In the beginning was AT&T Bell Labs, staffed by a benevolent team
of PhDs and research scientists. AT&T produced this really neat
operating system--System V--which computer manufacturers wanted to
license and use. Everybody was happy to sign tough contracts with
these benevolent scientists--licenses which deeded all derivative
works back to AT&T, licenses that covered all "methods" and
"concepts" of operating systems. But now those licenses are owned
by SCO and its team of lawyers who are certain that AIX and all
the other IXs belong to SCO. And the company now wants royalties
from users of all these operating systems--especially Linux.

Specifically, Sontag believes the "SCO technologies" which were
misappropriated into AIX, IRIX, and the derivative UNIX-alikes
(including Linux) are:

* JFS (Journalling File System).
* NUMA (Non Uniform Memory Access), a SGI/Stanford collaboration.
* RCU (Read-Copy-Update).
* SMP (Symmetrical Multi-Processing).

"But what about BSD?" I asked. Sontag responded that there
"could be issues with the [BSD] settlement agreement," adding that
Berkeley may not have lived up to all of its commitments under the
settlement.

"So you want royalties from FreeBSD as well?" I asked. Sontag
responded that "there may or may not be issues. We believe that
UNIX System V provided the basic building blocks for all subsequent
computer operating systems, and that they all tend to be derived
from UNIX System V (and therefore are claimed as SCO's intellectual
property)."

"So is anybody clean? What about Apple and Microsoft?" I wondered.
"Sun is clean," he said--but he gave no answer in regards to Apple
and Microsoft.

"But I thought that Microsoft had signed a license agreement?" "No,"
Sontag said. Microsoft merely licensed an "applications interface layer."

*** Read more at http://click.byte.email-publisher.com/maabaREaaYDX Da9Irx5b/
This article is freely available to all readers. ***

www@gw.com

But in general if you are just keeping a collection of pornography or some accounting information, then I think that the likelihood of you rotting in jail until you give up the key is pretty low. And in most civilised countries [excluding Great Britain] the judicial system would require that other evidence be sufficient to put you in jail in the first place.

Someone else pointed this out in another thread, but essentially encrypting something might make you appear

more suspicious.

Sure, but a suspicious appearance would only make your actions come under higher scrutiny. Presumably, you would discover that they [whoever they are] examined your encrypted hard drive and so would refrain from additional illegal activity. Problem solved.

Seems the best answer for storing sensitive data might be to store it on a computer in another country, and transfer it back and forth with SSH.

This has the same problems as not giving up the key; making you appear more suspicious. Either way the attacker can not get the information but will know what you're doing and hence they are roughly equivalent. There is a fair degree of co-operation between world governments on many levels of crime as well. It is likely that transfering data back and forth in this manner would end up being in total less secure than encrypting your hard drive because you do not have physical control over the machine from which you are retrieving the data. Without such physical control, you are much more likely to be compromised without your knowledge and be caught in the act of tranfering the data which is now a much more serious crime than the original [that is trafficking illegal data across international borders is much more serious that just storing it locally].

And you also need to take steps to protect the other machine. You probably want to encrypt its disks as well. But now you have either unattended boot issues, or you are using a distributed cryptographic file system such as CFS[1], TCFS[2] or NCryptfs[5] not storing keys on the other machine. But again, now any man-in-the-middle can most probably tell that you are accessing a cryptographic file system outside the country which of course exposes you to much higher risk because of both the suspicion and the higher level of the crime.

Also, just encrypting the data access says nothing about what is stored locally on your disk or in your swap space. You still need to be very careful about that, because temporary files or anonymous pages that are written to disk must be encrypted each and every time. If they are not then there is proof positive that you were both committing a crime and traversing international borders to do so. Not a good situation to be in. (Actually a lot of the same discussion applies to having a Samba box in the attic. It does absolutely nothing to protect you from swapping out and/or caching the data on the local machine and so is an incomplete solution which gives a dangerous sense of protection.)

The only real solution to the swap and temporary file problem is to encrypt it using something like either NetBSD's cgd(4)[3], or OpenBSD's encrypted swap[4]. But now again, you are stuck with being suspicious so you've done the international dance or the Samba in the attic dance for no reason. You have reduced the overall security of you systems for no reason. And in the international dance case, you have increased the number of crimes that you are committing for abso

Hiding the hard drive in the attic will hide the data for a few minutes against anyone with half a clue. Also the performance hit of using WiFi for file sharing will be enormous. cgd(4) only costs a tiny amount of performance.

Hiding the hard drive in the attic will hide the data for a few minutes against anyone with half a clue. Also the performance hit of using WiFi for file sharing will be enormous. cgd(4) only costs a tiny amount of performance.

Hiding the hard drive in the attic will hide the data for a few minutes against anyone with half a clue. Also the performance hit of using WiFi for file sharing will be enormous. cgd(4) only costs a tiny amount of performance.

If this FreeBSD patch (misc/47576: [PATCH] factor(6)ing of negative numbers) gets in, then yes.

In a critical measure of secure Web serving performance, a 4-way eServer p630 set an industry record for entry level (4-way) systems supporting 1,988 simultaneous connections, far outpacing the 568 simultaneous connections achieved by the 4-way Sun Fire V480 on the SPECweb99_SSL performance measure.[2]

The eServer p630 set an additional 4-way Web serving record when the system processed 6,895 simultaneous connections, offering greater than 50 percent more performance than a 4-way Sun Fire V480 with 4,500 simultaneous connections.[3]

http://netbsd.gw.com/cgi-bin/man-cgi/man?cgd+4+Net BSD-current.

and the config utility:

http://netbsd.gw.com/cgi-bin/man-cgi?cgdconfig+8+N etBSD-current

http://netbsd.gw.com/cgi-bin/man-cgi/man?cgd+4+Net BSD-current.

and the config utility:

http://netbsd.gw.com/cgi-bin/man-cgi?cgdconfig+8+N etBSD-current

.. and they could have halt -n'd with a legitimate reason..

Still from what I can see with my nonexistent Dutch nobody was hurt and backups were fairly solid, which is about all you can ask for at a time like this.. Still, you know what this means.. NEW TOYS!!!!

like somehow reading the actual memory pages of the PGP process, or trojaning the PGP binary itself

And, again in the case of PGP, you aren't trojanning the binary if it is your own binary. It is trivial to modify PGP in this way, or just run it in script(1).

IIRC, the pgp documentation explicitly states that that mode is only useful as a hint to the receiver of the document that it is more confidential and should be treated with greater care but provides exactly no guarantee that the contents will not be saved in plain text.

Please read a dd(1) manpage somewhere.

rwd0d is the raw device (r) of the first IDE disk (wd0), using a special partition (d) that spans the disk from the very first to the very last byte.
I *think* it's the same as hda under Linux, but I'm not sure there.

- Hubert

Hack on NetBSD, and your code runs on over 20 architectures!

cross-compilers: i386-linux i386-linuxglibc1 i386-netbsdelf, powerpc-netbsd sparc-netbsdelf sparc64-netbsd. If you would, do make install in a subdir. Get cross compilers from anoncvs, modules available with 'cvs co CVSROOT'.

http://netbsd.fi.gw.com/

Hack on NetBSD, and your code runs on over 20 architectures!

cross-compilers: i386-linux i386-linuxglibc1 i386-netbsdelf, powerpc-netbsd sparc-netbsdelf sparc64-netbsd. If you would, do make install in a subdir. Get cross compilers from anoncvs, modules available with 'cvs co CVSROOT'.

http://netbsd.fi.gw.com/