Re: Why can't OpenBSD's securelevels be saved?! - BSD

This is a discussion on Re: Why can't OpenBSD's securelevels be saved?! - BSD ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Why can't OpenBSD's securelevels be saved?!

  1. Re: Why can't OpenBSD's securelevels be saved?!

    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.


  2. Re: [long][diffs] Why can't OpenBSD's securelevels be saved?!

    Borked Pseudo Mailed 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

+ Reply to Thread