Joachim Schipper wrote:

>Securelevel 1 is useful and works correctly (i.e., adds a few basic
>protections without troubling general system use), and it is this which
>is used 'on default installs'. I do not believe this will be removed at
>any point in the foreseeable future. However, neither securelevel 1 nor
>securelevel 2 is a complete system lockdown, which seems to be what some
>people intend it to be.







*** People probably intend it to be as it appears in the respective
man pages. Man pages should explicitly list all serious problems
that are known.


*** Man pages should not be designed to mislead their readers.
The contents of man pages should be clear and unambiguous.


*** As i've mentioned , I seek only to use securelevels to
achieve some [Additional Level of Protection]. I do not
seek exclusive protection. I do not seek complete
protection.







>The securelevel(7) man page, is quite precise in enumerating the
>protections afforded, and does quite clearly not mention disallowing








*** "does quite clearly not mention"? How does one "clearly" not
mention something? ;-) Serious known security problems relevant to
a particular man page SHOULD BE CLEARLY PRINTED AND LISTED
within the respective man pages. That should be their primary
purpose on a security-focused OS.








>mounts. Really, I read it about 6 months before the whole affair, and
>immediately understood this limitation. Which is where the "failed to
>RTFM" comment, above, comes from.








*** The securelevel man page is incomplete. Ordinary users should not
have to spend inordinate amounts of time scrutinizing each
individual letter or word within a man page , looking for
hidden meaning. Or are hypocrisy and "security through obscurity"
the guiding principles when writing or maintaining OpenBSD man pages
these days? I expected more.







>Surely, 'securelevels don't work for what you want them to do, anyway'
>is a much more clear response.









*** It is not clear exactly what they do and do not do at present.



*** I have overtly written of my affinity for the concept of securelevels.








>On a side note, would it be asking too much to
>1. Use only one account





*** I don't have the option , all accounts are not available and
accessible at all times. I will see if there is anything I
can do.




>2. Use proper formatting (what's with all the *** lately?)





*** It marks the beginning of my replies?


*** What is "proper formatting" , I was under the impression that
differing clients provide differing outputs? Have you any
specific requests?





>3. Actually limit yourself to 72 columns






*** I will try to , sometimes things are mangled after they are
sent. How many columns have you been seeing?






>4. Produce some diffs (adding a sys.allow_mounts sysctl shouldn't be
>that difficult, even if it's not particularly useful), or shut up?

>Joachim






*** I'm not a programmer. My shell scripts generally work well , but
are primitive , repetitive , and uninspiring.


*** If you or someone else could add that feature to OpenBSD , it would be
useful and appreciated. NetBSD should not have security
advantages over OpenBSD , IMO. Also bear in mind that additional
protection for process 1 from root may be required.


Best Regards , An Odd User.

Borked Pseudo Mailed <nobody@pseudo.borked.net> wrote:
> Joachim Schipper wrote:
>>Securelevel 1 is useful and works correctly (i.e., adds a few basic
>>protections without troubling general system use), and it is this which
>>is used 'on default installs'. I do not believe this will be removed at
>>any point in the foreseeable future. However, neither securelevel 1 nor
>>securelevel 2 is a complete system lockdown, which seems to be what some
>>people intend it to be.
>
> People probably intend it to be as it appears in the respective man
> pages. Man pages should explicitly list all serious problems that are
> known.
>
> Man pages should not be designed to mislead their readers. The
> contents of man pages should be clear and unambiguous.
>
> As i've mentioned , I seek only to use securelevels to achieve some
> [Additional Level of Protection]. I do not seek exclusive protection.
> I do not seek complete protection.

Certainly, and securelevels afford additional protection. However, they
do not afford the precise additional protection you seem to desire (for
instance, they do disallow modifying inode 7623 on wd0d; they don't
disallow modifying /usr/bin/vi, as you can mount something else on
/usr).

>>The securelevel(7) man page, is quite precise in enumerating the
>>protections afforded, and does quite clearly not mention disallowing
>
> "does quite clearly not mention"? How does one "clearly" not mention
> something? ;-) Serious known security problems relevant to a
> particular man page SHOULD BE CLEARLY PRINTED AND LISTED within the
> respective man pages. That should be their primary purpose on a
> security-focused OS.

Okay, that 'clearly' is nonsense.

>>mounts. Really, I read it about 6 months before the whole affair, and
>>immediately understood this limitation. Which is where the "failed to
>>RTFM" comment, above, comes from.
>
> The securelevel man page is incomplete. Ordinary users should not
> have to spend inordinate amounts of time scrutinizing each individual
> letter or word within a man page , looking for hidden meaning. Or are
> hypocrisy and "security through obscurity" the guiding principles when
> writing or maintaining OpenBSD man pages these days? I expected more.

Ordinary users don't need to use securelevels in the fashion you seem to
want to use them. Those who do need that level of security most likely
are able to understand the limitations of securelevels.

Still, an update to the man page may be in order, as this seems to be a
frequent topic.

>>Surely, 'securelevels don't work for what you want them to do, anyway'
>>is a much more clear response.
>
> It is not clear exactly what they do and do not do at present.
>
> I have overtly written of my affinity for the concept of securelevels.

It should be reasonably clear that they do everything that is described
in securelevel(7), and don't do anything not described in
securelevel(7); it might be a good idea to document everything else and
delete the notice that the man page may not be comprehensive, but that's
all.

And, sorry to say, what one person thinks of the concept really isn't
that relevant.

>>On a side note, would it be asking too much to
>>1. Use only one account
>
> I don't have the option , all accounts are not available and
> accessible at all times. I will see if there is anything I can do.

It's not that big an issue, just annoying.

>>2. Use proper formatting (what's with all the *** lately?)
>
> It marks the beginning of my replies?
>
> What is "proper formatting" , I was under the impression that
> differing clients provide differing outputs? Have you any specific
> requests?

Generally, proper formatting looks like this message: text starts at the
left and ends at or before column 72. Additionally, commas are formatted
like this, not like this , which is obviously incorrect.

Differing clients do produce different output; those that produce
anything else than this are broken, though.

(FWIW, I currently maintain and am posting using news/tin. It works for
me.)

>>3. Actually limit yourself to 72 columns
>
> I will try to , sometimes things are mangled after they are sent. How
> many columns have you been seeing?

Well over 80.

>>4. Produce some diffs (adding a sys.allow_mounts sysctl shouldn't be
>>that difficult, even if it's not particularly useful), or shut up?
>
> I'm not a programmer. My shell scripts generally work well , but are
> primitive , repetitive , and uninspiring.
>
> If you or someone else could add that feature to OpenBSD , it would be
> useful and appreciated. NetBSD should not have security advantages
> over OpenBSD , IMO. Also bear in mind that additional protection for
> process 1 from root may be required.

NetBSD, and particularly TrustedBSD, has a different approach to
security than OpenBSD. OpenBSD is very much a UNIX-like OS with all
sorts of additional protections; something like TrustedBSD doesn't
resemble a UNIX all that much, and may not even be that much more
secure, but it's a lot more auditable.

Which is not necessarily a bad thing - some things cannot readily be
expressed in the classical UNIX access controls (notably, the concept
that the owner of a file is not free to do as (s)he wants with it).
However, it's not clear that those knobs actually add security.

In a properly/paranoidly configured OpenBSD system, any and all
network-attached daemons are either OpenSSH or running as a non-root
account in a chroot() and possibly systrace jail. (And no, I am not sure
I would add sendmail to a list of exceptions.) Additionally, one would
ideally choose only the most secure alternatives (in practice,
concessions to usability usually play an important role).

Of course, once those barriers are broken, it's game over for OpenBSD.
But breaking all of them is decidedly nontrivial.

On the topic of producing diffs, here are some for some manual pages,
produced in five minutes. Feel free to do whatever you want, public
domain if so desired, but please keep in mind that I don't claim that
these changes are the best possible way to execute this idea, or even
that the idea is good:

Index: chflags.1
================================================== =================
RCS file: /var/nfs/cvsync/src/bin/chmod/chflags.1,v
retrieving revision 1.7
diff -u -b -B -u -r1.7 chflags.1
--- chflags.1 15 Oct 2005 08:42:14 -0000 1.7
+++ chflags.1 26 Feb 2007 17:10:01 -0000
@@ -93,6 +93,7 @@
.Ed
.Pp
An immutable file may not be changed, moved, or deleted.
+(But note that mounting a filesystem in the proper place may cause the filename to point to a different file.)
An append-only file is immutable except that data may be appended to it.
.Pp
Putting the letters

Index: securelevel.7
================================================== =================
RCS file: /var/nfs/cvsync/src/share/man/man7/securelevel.7,v
retrieving revision 1.19
diff -u -b -B -u -r1.19 securelevel.7
--- securelevel.7 19 Aug 2006 07:51:25 -0000 1.19
+++ securelevel.7 26 Feb 2007 17:11:33 -0000
@@ -179,3 +179,4 @@
.Ox 2.6 .
.Sh BUGS
The list of securelevel's effects may not be comprehensive.
+Note that setting a higher securelevel does not disallow mounts; thus, setting the proper file flags does ensure that a file cannot be modified on disk, but does not mean that the filename always points to the same file.

Would something like this be what you want? OpenBSD is certainly not
going the TrustedBSD route, so hoping for that is not a good use of your
time. And securelevels certainly aren't going to be remove any time
soon, so railing against that is also a waste of your time.

Joachim