Other Formatting a Hard Disk Drive

It appears that FreeBSD's equivalent to MS Window's 'format' Command is 'gpart', and it appears that I don't need to use the 'geom' Command which is utilized via 'gpart'; is this correct? [BTW, why are there two 'geom' Commands: geom(4) & geom(8)? It seems rather dumb to have two Commands with the same name.]

I need to format a 40GB Hard Disk Drive with two Slices: NTFS & FreeBSD. The NTFS Slice needs to be usable by MS Windows XP. This Hard Disk is not intended to be bootable, but rather just a Slave Drive used for storage. Do the following Commands fulfil my task? Should I erase the Disk before-hand using the Computer's BIOS utility?

gpart create -s MBR ada1 ~ or ~ gpart create -s MBR -n 2 ada1
gpart add -t ntfs -s 30G -i 0 -l WindowsXP ada1
gpart add -t freebsd-ufs -s 10G -i 1 -l FreeBSD ada1
 
It appears that FreeBSD's equivalent to MS Window's 'format' Command is 'gpart',
No, it is not, gpart(8) is more like fdisk.exe or the disk manager. It does NOT format disks. It creates or deletes partitions and/or slices.

[BTW, why are there two 'geom' Commands: geom(4) & geom(8)? It seems rather dumb to have two Commands with the same name.]
They are not the same "command". The different man pages are in two different sections; 4 - kernel interfaces; i.e. geom(4) covers details about the kernel modules, and 8 - System manager's manuals; geom(8) covers the actual command.

I believe Windows XP has a bit of a problem with GPT, normally I would recommend using that instead. But for MBR the commands would be something like:
Code:
gpart create -s MBR ada1
gpart add -t ntfs -l WindowsXP -s 30G ada1
gpart add -t freebsd -s 10G ada1
gpart create -t BSD ada1s2
gpart add -t freebsd-ufs ada1s2

newfs ada1s2a # <- this is the "format" command

But it's probably easier to use the Windows disk manager to create the partition table and the first Windows NTFS partition. Then use gpart(8) to create the additional FreeBSD partition on the remaining space.
 
It is best to resolve this matter within the FreeBSD Operating System, and determine what gpart Attributes will work with Windows XP in order to help future XP users who convert to BSD. It's not good for FreeBSD to be relying on another Operating System for anything. I will do experimenting with GPT to verify whether that works with XP.

Your suggested usage of gpart for MBR is identical to what the BSD Installer and the boot0cfg Command set up on my main Bootable Hard Drive, and so I can safely assume that your suggestion will work. Below is gpart show for my Bootable Drive:
Code:
=> ada0  MBR (19G)
      1  ntfs (12G)
         - free - (3.0K)
      2  freebsd [active] (6.9G)
         - free - (256K)

=> ada0s2  BSD (6.9G)
        1  freebsd-ufs (4.0G)
        2  freebsd-swap (2.9G)
           - free - (512B)
My Windows XP Disk Manager does know that the BSD Partition is there, but it doesn't know what 'File System' it is nor assign it a 'Volume' letter.

Does FreeBSD have a Command to erase the Hard Drive equivalent to the Computer's BIOS utility? The newfs -E Command doesn't appear to be a complete equivalent to the BIOS 'Full Erase' utility.
 
Does FreeBSD have a Command to erase the Hard Drive equivalent to the Computer's BIOS utility?
Not specifically but you can easily do it with dd(1), something like: dd if=/dev/zero of=/dev/ada1 bs=1M. Take extra special care you're using the correct device to write to because this command is extremely destructive.
 
... But for MBR the commands would be something like:
Code:
gpart create -s MBR ada1
gpart add -t ntfs -l WindowsXP -s 30G ada1
gpart add -t freebsd -s 10G ada1
gpart create -t BSD ada1s2
gpart add -t freebsd-ufs ada1s2
I want to correct a small error in line 4 which should be "-s BSD". Here is what I used to set up the Drive:
Code:
dd if=/dev/zero of=/dev/ada1 bs=1M
gpart create -s MBR ada1
gpart add -t ntfs -s 29G ada1
gpart add -t freebsd ada1
gpart create -s BSD ada1s2
gpart add -t freebsd-ufs ada1s2

The gpart create Command does not allow the Microsoft 'ntfs' Type to be used with the GPT Partition Scheme, and it returns an invalid argument error. You have to use the MBR Scheme in order to create the 'ntfs' Type, and you cannot use the '-l LABEL' Argument with the MBR Scheme which also returns an error.

Is gpart supposed to format the Drive when adding Slices / Partitions? My Windows XP recognized the 'ntfs' Partition / Slice as unformatted. It had assigned it a Windows Drive Letter, but did not recognize it as NTFS. I had to format the Partition / Slice with Windows XP. Is FreeBSD able to format for NTFS?

I added the FreeBSD Slice 'ada1s2a' to the '/etc/fstab' File, and it has screwed-up my boot sequence! It causes an unrecognized file system error (Error 3), and I cannot log in under 'root'. I can only enter the system as a 'single user', and I cannot edit the 'fstab' File which is declared read-only. What can I do to fix this problem?
 
I want to correct a small error in line 4 which should be "-s BSD"
Good catch. That was a typo. I typed it all from the top of my head.

I added the FreeBSD Slice 'ada1s2a'
That's a partition. The s2 is the slice (hence the 's'). The 'a' is a partition inside the slice. So ada1s2a is a partition. Utterly confusing I agree. It's difficult to get your head around this but it's important to know the difference between a slice and a partition.
 
The gpart create Command does not allow the Microsoft 'ntfs' Type to be used with the GPT Partition Scheme, and it returns an invalid argument error. You have to use the MBR Scheme in order to create the 'ntfs' Type, and you cannot use the '-l LABEL' Argument with the MBR Scheme which also returns an error.

Is gpart supposed to format the Drive when adding Slices / Partitions? My Windows XP recognized the 'ntfs' Partition / Slice as unformatted. It had assigned it a Windows Drive Letter, but did not recognize it as NTFS. I had to format the Partition / Slice with Windows XP. Is FreeBSD able to format for NTFS?

To create an NTFS partition under GPT you need to specify type ms-basic-data.

gpart is used simply for partioning. Formatting is done using using newfs() (for UFS).

http://www.wonkity.com/~wblock/docs/html/disksetup.html is worth reading...
 
Thanks for that "Disk Setup On FreeBSD" Webpage which will be useful to many others. I was able to create the Slices / Partitions using gpart as indicated in my previous Post #5. I guess newfs was needed to format the BSD Partition 'ada1s2a' before adding it to the 'fstab' File.

How do I fix the 'fstab' File which screwed-up my OS? I was able to login under 'root' from the 'single user' mode, but 'fstab' is still considered read-only. Is it possible to edit it from the Live CD, or am I going to have to reformat my OS? If so, then this is a severe defect in the FreeBSD OS. The 'root' user should never be locked out of the system. It is also a serious defect in the BSD OS that I was able to login as a 'single user' simply by pressing <ENTER> -- with NO Password required! It should NOT be possible to log into the system without a Password!
 
I was able to login under 'root' from the 'single user' mode, but 'fstab' is still considered read-only.
When you boot to single user mode the root filesystem is the only filesystem that's mounted, and it's mounted read-only.

For UFS:
fsck -y
mount -a

For ZFS:
zfs set readonly=off zroot

It is also a serious defect in the BSD OS that I was able to login as a 'single user' simply by pressing <ENTER> -- with NO Password required! It should NOT be possible to log into the system without a Password!
Edit /etc/ttys and change the secure to insecure for the console:
Code:
console none                            unknown off insecure

Note that this doesn't protect anything. Console access requires physical access to the machine, anyone with physical access to the machine can break into your system without a password. As it is quite easy to boot from alternative media, mount the fileystems and reset/remove the root password.
 
Console access requires physical access to the machine, anyone with physical access to the machine can break into your system without a password. As it is quite easy to boot from alternative media, mount the fileystems and reset/remove the root password.
You can say that again.... I like it:):). It is one those explanations that challenged my thoughts about system security/privacy.
 
When you boot to single user mode the root filesystem is the only filesystem that's mounted, and it's mounted read-only. ...
I need to clarify a vital point: I did not select 'Single User' under the Boot Menu -- I selected 'Multi User'. The following error message is what was indicated on the Screen at boot up:
Code:
THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
 ufs: /dev/ada1s2a (/shd)
Warning! Some of the devices might not be available; retrying
Unknown error 3; help!
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
Jun 5 23:36:32 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh:

For UFS:
fsck -y
mount -a
...
Note that this doesn't protect anything. Console access requires physical access to the machine, anyone with physical access to the machine can break into your system without a password. As it is quite easy to boot from alternative media, mount the fileystems and reset/remove the root password.
Here is the error response from the fsck -y Command:
Code:
SEARCH FOR ALTERNATE SUPER-BLOCK FAILED.  YOU MUST USE THE -b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION;

However, the mount -a Command did work successfully in restoring the 'root' Superuser's ability to edit files, and I was able to delete the BSD Partition from the 'fstab' File. The system then did reboot successfully to the 'Login:' prompt.

Nonetheless, this is a serious defect in the FreeBSD Operating System that I was able to login as the 'root' Superuser simply by pressing <ENTER> with NO Password. As I stated, it should NOT be possible to log into the system without a UserID & Password!
 
Nonetheless, this is a serious defect in the FreeBSD Operating System that I was able to login as the 'root' Superuser simply by pressing <ENTER> with NO Password. As I stated, it should NOT be possible to log into the system without a UserID & Password!
I already showed you how you can enable the password. All UNIX and UNIX-like operating systems behave in exactly the same way. You are putting way too much weight on something that's completely irrelevant. You need physical access to be able to use the console and any user with physical access to the machine will be able to circumvent this password. It's not going to protect your system in any way.
 
I should have checked the '/etc/ttys' File before making my last Post. Your recommended change did work in restoring the Password for Single User mode -- thanks again. In criticizing this Password situation I'm not thinking in terms of my own Computer situation as I live alone. It would be better if the default setting were 'insecure' in order to ensure that BSD users' Computers are secure in households where there are family members sharing a Computer. A shared Computer setting is where a lack of a Password would pose a problem. I do realize that you can read / copy a Hard Disk via Software -- how do you think I recovered my Windows XP Files after suffering the 'Bluescreen horror' last December? I just brought it to a local Computer place. This type of physical security risk for the Hard Drive is not a problem in a regular household setting.

I do also know of other vulnerabilities with UNIX as I had successfully hacked into my High School Computer System which was a UNIX version called "QNX". I have some security ideas to offer to FreeBSD programmers which would make BSD more hack-proof.

For some reason when I load the Single User mode it keeps trying to reconnect my Mouse, and this keeps repeating about every thirty seconds. Below is the error message I keep getting. Do you have any suggestions of what is the problem?
ugen0.2: <Logitech USB Optical Mouse> at usbus0
ugen0.2: <Logitech USB Optical Mouse> at usbus0 (disconnected)
 
You need physical access to be able to use the console and any user with physical access to the machine will be able to circumvent this password. It's not going to protect your system in any way.
That's not entirely true, as I can think of several circumstances where this might actually improve things. For instance:
- A user may have access to a terminal for the machine, but the machine itself may be secured by some physical barrier. Of course the BIOS would also have to be locked in these circumstances as well.
- If the serial console/terminal is enabled, and this is proxied to TCP/IP, you could be anywhere. To be fair though, these are separate TTYs.
- KVM over IP, IPMI, etc.

I consider it more along the lines of securelevel. Will it, by itself, do anything to twart an attack? No. But if properly combined with physical security and other security measures, it's not going to hurt.
 
There's clearly a tradeoff here between security (although there exist a myraid of threat models in which an operating system is deployed) and power to recover a badly-damaged installation. Demanding credentials requires a quite a bit more to be intact, with little scope for selecting alternatives. And I've been in the position of needing to recover a system to which I didn't have the root password. Changing the balance to make it both harder to penetrate or recover a system when console access is a concern (and assuming steps have been taken to secure the chain of components that bootstrap the kernel to get to that point) ought to be possible but not a default - securelevel is another example where we expect a system administrator to enable it only when ready and aware of the potential consequences - which go much further than recoverability.
When security concerns exist, perform hardening tailored to the threat model - but please don't assume/expect that everybody else's circumstances align with yours.
 
In most cases, a person who has access to the physical console (meaning keyboard and screen) also has access to the server itself. That's simply because the keyboard and video cable are typically pretty short. That means that person also has the capability of using a screwdriver, physically removing the boot disk, connecting it to another computer, and reading and modifying all the data.

Yes, it is possible to put in physical measures that prevent access to the disk drive. For anything other than crazy military systems, that's impractical. If you want security of the data at rest on the disk drive, you really need to go to encryption (for example with self-encrypting drives). That is, however, a huge hassle, and key management for such systems is very very difficult. Such systems also tend to be very gnarly to administer: if something goes wrong, where do you get the key from? And how do you store the key so it is more secure than the system itself? In high-end installations, that's done by having key managers (like Kerberos servers) in physically secure places, typically welded steel cages around racks. Not something for a household.

Having a password for single-user mode is "doorknob security": It makes it look more secure, but anyone who knows can just turn the door knob. On the other hand, as Orum said above: A whole series of doorknobs, when taken together, might make an attacker waste so much time that they decide to go elsewhere. While not really secure, that's mostly good enough.
 
Also very important in my opinion is to understand the underlying philosophy here. For example: it's not the operating systems job to secure the environment, that task is the sole responsibility of the administrator.

And this is for very good reasons. Because in this way you won't risk setting up the well known trap that some people start to rely on the OS or its features to keep their data secure. Features such as default settings, which is basically the dumbest thing you can do if you truly want to achieve a secure environment. After all: those defaults are usually also very well documented, thus giving a potential attacker all the information they need up front to quickly asses their target.

So instead of applying some pseudo security FreeBSD opts to provide you with all the tools you need to set this up on your own. Preferably also in your own custom way thus avoiding predictability. Which, in my opinion, is key within this field.
 
For example: it's not the operating systems job to secure the environment, that task is the sole responsibility of the administrator.
...
You have to remember that newbies to FreeBSD will take some time to figure out how it works. Password protection should be the default state for BSD's Single User mode to accommodate newbies both in household settings and small businesses. When you install FreeBSD you have to enter your own Password for the Root Superuser, and it makes sense for this to apply by default to the Single User mode -- which I simply assumed that it did. I never use the Single User mode, and it took me three months -- by accident -- before I discovered that it isn't Password protected. While it is 'read only', this is circumvented by using mount -a. I would not have even discovered this problem at this point had it not been for a problem mounting my Slave Hard Drive. Had it not been for this mounting problem I may not have discovered this Password problem for years.

I'm familiar with UNIX -- unlike the average newbie coming to BSD. The lack of 'default' Password protection for Single User mode is a problem in the household setting, but it is a severe security breach in a business setting! A severe security breach should not be the default setting for an Operating System for a business.
 
You have to remember that newbies to FreeBSD will take some time to figure out how it works. Password protection should be the default state for BSD's Single User mode to accommodate newbies both in household settings and small businesses.
Well, and that's where we obviously disagree. Because security isn't merely a tool or a setting you turn on or off; security is an ever ongoing process and it can only start with the understanding of the environment by the operator(s). This idea would only result in an inexperienced operator falsely assuming that they are at least "somewhat safe" because of the password while in reality this password doesn't stop anything, as already showcased by others above.

Quite frankly this is a major difference between Unix and Unix-like operating systems. I'm aware that this behavior is a default on Linux for example, but it was not on Sun Solaris nor (if I remember correctly, it's been a while) IBM's AIX.

And of course FreeBSD, which is one of the reasons why I think FreeBSD sits so much closer to Unix and the well known Unix philosophy than Linux will ever be. Even though technically speaking FreeBSD is also a Unix-like environment.

Now, to keep this into more ontopic BSD perspective... Are you familiar with OpenBSD? It's a very impressive platform in my opinion: a BSD environment which is solely focused on security. They take this to such extremes that OpenBSD often even sacrifices user friendliness over improved security measures. I'm not just saying: in their FAQ they even openly state that:
  • OpenBSD is thought of as the most secure UNIX-like operating system by many security professionals, as a result of the never-ending comprehensive source code audit.
... and I honestly believe that they are right.

So guess what? Even they deem the console secure; they don't use password protection for single user mode by default. Even OpenBSD obviously doesn't see any extra value in password protecting this, simply because there isn't any.

Physical access is the end of the line when it comes to security, it's as simple as that.

I guess we'll have to agree to disagree, but even so I'd seriously advice you to re-evaluate this whole setup. I honestly believe that you're putting way too much value into a setting which can be bypassed with hardly any extra effort.
 
... This idea would only result in an inexperienced operator falsely assuming that they are at least "somewhat safe" because of the password while in reality this password doesn't stop anything, as already showcased by others above.
...
And of course FreeBSD, which is one of the reasons why I think FreeBSD sits so much closer to Unix and the well known Unix philosophy than Linux will ever be. Even though technically speaking FreeBSD is also a Unix-like environment.

Now, to keep this into more ontopic BSD perspective... Are you familiar with OpenBSD? It's a very impressive platform in my opinion: a BSD environment which is solely focused on security. They take this to such extremes that OpenBSD often even sacrifices user friendliness over improved security measures.
...
Physical access is the end of the line when it comes to security, it's as simple as that.

I guess we'll have to agree to disagree, but even so I'd seriously advice you to re-evaluate this whole setup. I honestly believe that you're putting way too much value into a setting which can be bypassed with hardly any extra effort.
We can agree to disagree on whether Password security for the Single User mode should be the default setting, but nonetheless your vehement opposition to it makes no sense. Password protection should be the default state for BSD's Single User mode as a logical courtesy to accommodate new users both in household settings and small businesses. It is simple common sense for the OS to provide basic Password protection until a new BSD user becomes familiar with the OS. It's then as easy as pie for advanced BSD users to disable Password protection if they wished, but that wouldn't make any sense either. The current default deliberately places new FreeBSD users at risk, and you aren't taking into consideration how long it takes for a newbie to become familiar with the UNIX-style OS. The Password does provide full protection in the regular household / business setting where it is not possible for someone to just remove the Hard Drive without being detected. It would require a LOT of extra effort for someone in a business setting to just steal the Hard Drive after the business is closed, and then return the Drive in time without being caught! Stealing the Hard Drive is much easier said than done! In High School I had to go after hours to the Computer Lab in order to be able to use the Lab freely as a Superuser. It took a lot of effort on my part. With BSD's Single User mode, not only can you read everyone's private Files, but by simply executing mount -a you can then change any Files such as secretly adding a new Superuser to the Password File! Why do you not think that this is a serious security breach?

I do agree that FreeBSD is more authentic to UNIX than Linux -- which is why I migrated from Linux to BSD. I had vaguely heard of OpenBSD, but quite frankly I don't think that it should even exist. I don't comprehend any reason for there to be more than two UNIX-based freeware Operating Systems: FreeBSD and Linux, and Linux also has WAY TOO MANY Distributions. If OpenBSD is like Linux and Mozilla in using an open group of programmers -- rather than a closed group like FreeBSD, then this is not good because it leads to all kinds of Bugs from well-intentioned but inadequately qualified programmers. As far as I'm aware there are three BSD versions: Free, Open & Net; and there is no reason why the 'BSD' community should be in schism. This causes software manufacturers to be averse to producing software for 'BSD' since it doesn't appear to be a stable community. The FreeBSD model of a select closed group of programmers is the best approach to administering an Operating System, and OpenBSD would be wise to just contribute to improving FreeBSD.
 
I presume you'll also be taking the writers and distributors of BIOS firmware to task for allowing users to boot from any media other than the internal HDD out of the box, and not requiring a master BIOS password to be set on first boot. And then we'll work along the various bits of boot code that allow user interaction to influence this process, and remove this facility unless the admin explicitly enables it. A single-user password prompt is child's play to circumvent until all this is nailed down. And I don't personally see the security gains outweighing the loss in usability - as inexperienced users will find it hard to get themselves out of trouble if any link in the boot chain is no longer functioning as it should.
Other BSD flavours are available too, BTW, with different priorities. There's plenty of cross-pollination and we would all be much poorer without them.
 
Password protection should be the default for ... Single User mode
Consider what happens if the root password has been lost, or if the passwd.* file which stores the passwords has been damaged. Now you have a bricked machine. It can still be recovered (just take the root disk physically out, and move it as a non-root disk into a different machine), but that's much harder. In particular for a newbie (who doesn't know how to do this) or a household (which is less likely to have a spare computer or disk around), this is a particularly tall order.

I also object to it on philosophical grounds. It gives the user a false sense of security. They will think that even though an intruder has been able to get physical access to the console, the data on the machine is still safe, when in reality, it isn't (because the intruder can now physically pull the disk out and take it). Your talk about "difficult without being detected" is nonsense. It is perfectly easy to detect when someone becomes the super-user, or when someone reboots the machine (which is required to go into single user mode). And the most serious of the attacks you describe (become super-user, do "mount -a", then modify files) is perfectly easy to execute, if one carries a USB stick with a bootable OS around: just plug it in, hit the reset button, and go to town.

Why do you not think that this is a serious security breach?
It is a serious security breach. If you want to protect against it, do so. The correct way to protect against it is not to put a meaningless doorknob on single-user mode, but top protect the hardware. There are many ways to do that: physical security, encrypted disks, and so on. Most people chose to not protect against it; I think in most cases that is a sensible and rational choice.

I do agree that FreeBSD is more authentic to UNIX than Linux ...
The whole discussion of what you consider to be "Unix" is silly. There are many ways to define "Unix", for example: Posix compliance, contains Ken and Dennis' AT&T source code, or contains Kirk's Berkeley source code, and so on and so on. For most purposes, Linux is Unix (the by far most popular one), followed by the various *BSDs. Microsoft Windows and IBM's mainframe operating system (today I think called zOS, formerly known as MVS) both can claim to be Unix too, as they are Posix compliant. If you want to know what the "Unix philosophy" is, that term is more often abused than used.

One of these days, I'll ask Ken what computer he carries around with him, if I happen to see him; unfortunately, we can't ask Dennis any more.

I had vaguely heard of OpenBSD, but quite frankly I don't think that it should even exist. I don't comprehend any reason for there to be more than two UNIX-based freeware Operating Systems ...
There are lots of good reasons for OpenBSD to exist. It is a very fine operating system (even though I admit to not having used it in about 6 or 8 years now). It has its strengths, and also its weaknesses. So does FreeBSD, so does Linux, and many of its distributions.
 
Last edited:
I presume you'll also be taking the writers and distributors of BIOS firmware to task for allowing users to boot from any media other than the internal HDD out of the box, and not requiring a master BIOS password to be set on first boot. ...
And I don't personally see the security gains outweighing the loss in usability - as inexperienced users will find it hard to get themselves out of trouble if any link in the boot chain is no longer functioning as it should.
Other BSD flavours are available too, BTW, with different priorities. There's plenty of cross-pollination and we would all be much poorer without them.
The fact that there is a potential vulnerability in the Computer's BIOS does not mean that FreeBSD should not be installed with the security settings set to MAXIMUM protection. The Computer's BIOS can be changed to block booting from any Drive. The BIOS setting isn't relevant to the issue of FreeBSD's installation default security settings. It is the minority of users who don't worry about security, and they can weaken it for themselves. FreeBSD's Installer forces you to set the 'root' Password -- you cannot leave it blank, but then it leaves the Password for Single User mode blank. This is just as idiotic as locking all the doors and windows to your house except the back door which you deliberately left open. I do however think that you should be able to leave the 'root' Password blank, and then this would automatically apply to Single User mode.

Please note that the Password requirement for Single User mode does not affect your ability to log in if there is a problem. I had a mounting problem that prevented Multi-User Login, but even after changing the Password requirement, the OS simply asked me for the Root Superuser Password to login under Single User mode. It worked perfectly fine.

We'll have to agree to disagree on your view that there is benefit to having different versions of BSD. Division amongst the 'BSD' community does not help in convincing software manufacturers to offer software for FreeBSD. FreeBSD is administered by a stable Foundation. You can be confident that the FreeBSD Foundation will still be around in thirty years, but you cannot be confident in the other BSDs. The other schismatic BSDs defile the credibility of FreeBSD with software manufacturers who just decide that there are so many BSD versions that it's not worth their time. The other BSD versions should not use the 'BSD' acronym.

Consider what happens if the root password has been lost, or if the passwd.* file which stores the passwords has been damaged. Now you have a bricked machine. It can still be recovered (just take the root disk physically out, and move it as a non-root disk into a different machine), but that's much harder. In particular for a newbie (who doesn't know how to do this) or a household (which is less likely to have a spare computer or disk around), this is a particularly tall order.
Going through this is exactly what security is about. I'm not a fan of idiot-proofing the OS to try to protect someone who forgets their Password. Someone who forgets to write down their Root Password should expect to go through some difficulty to regain entry to the system.

...Your talk about "difficult without being detected" is nonsense. It is perfectly easy to detect when someone becomes the super-user, or when someone reboots the machine (which is required to go into single user mode).
Nobody is so stupid as to not be aware that the Hard Drive can be stolen by an intruder. The average family member or employee of a business is not going to do such a thing. Having no Password is an invitation to unwelcome snooping. I stated that "the regular household / business setting where it is not possible for someone to just remove the Hard Drive without being detected. It would require a LOT of extra effort for someone in a business setting to just steal the Hard Drive after the business is closed, and then return the Drive in time without being caught".

And the most serious of the attacks you describe (become super-user, do "mount -a", then modify files) is perfectly easy to execute, if one carries a USB stick with a bootable OS around: ...
This potential security problem can be averted by eliminating such bootability in the BIOS. This security measure is not the responsibility of an Operating System.

The whole discussion of what you consider to be "Unix" is silly. There are many ways to define "Unix", for example: Posix compliance, contains Ken and Dennis' AT&T source code, or contains Kirk's Berkeley source code, and so on and so on. For most purposes, Linux is Unix (the by far most popular one), followed by the various *BSDs. ...
If you want to know what the "Unix philosophy" is, that term is more often abused than used. ...
There are lots of good reasons for OpenBSD to exist. It is a very fine operating system ...It has its strengths, and also its weaknesses. So does FreeBSD, so does Linux, and many of its distributions.
When I refer to UNIX I mean 'authentic' UNIX -- not UNIX hybrids such as BSD & Linux. I'm fully aware that Linux is much more common than FreeBSD which is why Linux gets a lot of dedicated software -- unlike FreeBSD. I read some horror stories about Bugs in Linux which made me glad that I had quickly migrated away from their Debian to BSD. Allow me to clarify that I think OpenBSD has every right to exist, but they should not use the 'BSD' acronym which should be reserved to FreeBSD in order to avoid confusion. The purpose of an Operating System is to be a platform for software programmes. I'll assume that OpenBSD has significantly fewer users than FreeBSD, and also fewer software programmes. If this is the case, then what's the logic to OpenBSD existing rather than contributing to FreeBSD? OpenBSD programmers' time would be better spent contributing to FreeBSD.
 
What does "authentic" mean? If you mean that it contains the original Dennis and Ken source code: As far as I know, that is today only available in the form of AIX and HP-UX, which are the last remaining AT&T licensed versions. But I fail to see why "authentic" matters.

You say that that division among the BSDs prevents software manufacturer from offering software for BSD. What software manufacturers? The amount of commercial software that is produced for any BSD is minuscule to begin with. Furthermore, the three or four *BSDs (Free-, Open- Net-, Dragon-) are so similar to each other in their API that software produced for one would usually compile and work on the other three, with mostly a recompile and perhaps minor changes in packaging. This argument just doesn't make any sense.

Your comment about OpenBSD is nonsense. Yes, it's community is smaller than FreeBSD. But it has a wholly different source tree, with completely different goals. OpenBSD is all about auditing every line of code, reducing the amount of code, and maintaining very high quality, at the expense of features. The people who are interested in that could not work on FreeBSD, as the philosophy of that OS is different. So let them work on their favorite project; they are making a very good (but very different) product too. Before you make incendiary and nonsensical statements telling OpenBSD programmers what they should do, you really need to educate yourself on the existing goals and cultures of the projects.

Your statements on single user mode and security contain some grains of truth, and a lot of gibberish. Like everything in engineering, this is a tradeoff. Yes, checking the password on single-user login would increase security in some situations. But in many other situations, it would not increase security at all, because other gaps (such as physical disconnect of drive or booting from another drive) remain wide open. Simply claiming that this is "some other person's problem" (namely the BIOS manufacturer) is unrealistic. Disconnecting and reading/writing a disk in a case is not difficult; all it takes is bringing a small laptop, android phone or Raspberry Pi with a USB to SATA adapter and a cable. And what is your exact proposal for how to help the person whose single user mode password doesn't work (either because they forgot it or the passwd file has become unreadable)? Before making single used mode password mandatory, you have to come up with a reasonable solution for that, and I haven't seen any.
 
I'm slowly starting to wonder if this is actually a serious discussion going on or if someone isn't merely spouting off some gibberish (sometimes even contradicting) opinions for the sole reason to draw in arguments by other people. There's a word for that you know...

Just my 2 cents but I think it might be best to stop this discussion because I don't see this going anywhere.

As to the OP: if you're really serious about those ideas then you might want to take them to the mailinglist or submit a bug report together with a patch and additional reasoning why you think the base should be changed in this way. Seems mostly focused on /etc/ttys so that should be relatively easy.
 
Back
Top