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 ; In article , Anonymous wrote: >Why can't we save OpenBSD's securelevels? I have great affinity for the concept of securelevels on OpenBSD. I believe they should continue to be a core feature in OpenBSD. Marc Espie wrote: >I'm afraid you're ...

+ 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?!

    In article ,
    Anonymous wrote:

    >Why can't we save OpenBSD's securelevels? I have great affinity for the concept of securelevels on OpenBSD. I believe they should continue to be a core feature in OpenBSD.


    Marc Espie wrote:

    >I'm afraid you're quite alone there.






    *** That sir , is a mathematical uncertainty.



    *** Perhaps you would wish to put the issue to a vote?
    Set up a page at OpenBSD.org and poll the users?
    I estimate there to be a 100% chance that you will decline
    to accept such a fair offer.



    *** Referendums are interesting things , and non-binding
    referendums even more so.





    >Am I the only one who feels that the concept behind having securelevels
    >is sound and useful? Is there no way that OpenBSD's securelevels can be
    >fixed? Is there no way that OpenBSD's securelevels can be rewritten? Is
    >there no way that OpenBSD's securelevels can be re-designed?


    >>I'm afraid you're the only one. I fail to see any actual uses for securelevels
    >>that make any sense.







    *** There you go again with your math.



    *** I'll give you a hint , it would probably be represented as
    a Gaussian distribution. :P



    *** [http://en.wikipedia.org/wiki/Gaussian_distribution]






    >>I fail to see any actual uses for securelevels
    >>that make any sense.







    *** Let's see , some possible uses...



    *1) Providing some degree of additional protection against new
    and entirely unknown threats.



    *2) Providing additional protection against the loading of
    kernel modules.



    *3) Providing additional protection against writes to /dev/mem and
    /dev/kmem.



    *4) Providing additional protection against changes to PF filter and NAT rules.
    I would think this to be especially useful for a gateway router/firewall.



    *5) Providing additional protection against the use of X on a dedicated server.
    Enforcing machdep.allowaperture=0.



    *6) Providing additional protection against local misuse of ddb.console and
    ddb.panic to gain physical control from a console. Why make physical
    attacks quicker to perform or easier?



    *7) Providing additional protection against writes to raw devices.



    *8) Providing additional protection against misuse of "machdep.kbdreset" ,
    "net.inet.ip.sourceroute" , and "fs.posix.suid".



    *9) Providing additional protection for /bsd by making it immutable with
    chflags schg.



    *** Please pay special attention to my frequent use of "Providing additional
    protection".



    *** All of the above are features listed in the securelevel man page.



    *** I can also provide the following Prima Facie proof as to the "usefulness"
    of securelevels and why they do "make sense":



    *1) Securelevels were once added to OpenBSD kernels , prima facie proof as to usefulness
    and that they make sense.



    *2) Securelevels are still included within OpenBSD kernels , prima facie proof as to usefulness
    and that they make sense.



    *3) Securelevels are enabled by default on default installs , and set to securelevel 1 , "Secure mode" ,
    this is also prima facie proof that securelevels are useful and that they make sense.



    *** If the above three reasons are not prima facie evidence as to the usefulness of securelevels and that
    they "make sense" , then there are some extremely serious problems with the functioning of the OpenBSD project.
    Is the project in the habit of having code in it's kernels that is not "Correct" , "Secure" , "Useful" , or
    that doesn't "Make Sense"?






    >>If you need the kind of security for which securelevels would make sense,
    >>then they will get in the way of any maintenance operation. Basically,






    *** I don't need this kind of security , I want it. In the furtherance of the defense-in-depth
    concept. It is the unauthorized "maintenance operations" of others that I would like to
    prevent.



    *** If they are too inconvenient for you , don't use them. Please don't tell me what I find to be
    inconvenient. I'm not saying that I would always wish to run under securelevel 2 , only
    that I would like the option to do so , when I feel the need to do so. Even if one accepts
    that securelevels will always be imperfect , they will delay. Against the range of possible
    opponents , being able to delay is really the best that can be achieved IMO. I don't think that
    my personal threat-profile would make me a target for the most highly-skilled and well-funded of
    attackers , but if they focused upon me they would probably succeed. I would still try to thwart
    such attackers with all clever means , but I would probably only be delaying their ultimate success.
    There are always sharper tools out there. And nothing is ever perfect enough.





    >>securelevels mean you cannot do, even as root, any patch operation without
    >>being physically present, since you have to reboot to single mode to be
    >>able to do anything useful with your filesystem. That's assuming you're using
    >>securelevels for total lockdown. If you don't, the securelevel concept is
    >>useless, anyways. There will always be `root accessible' holes on your
    >>machine in any case. Forget about changing any disks as well, or even
    >>mounting new stuff. There's a whole lot of useful, sometimes security-critical
    >>things, you no longer will be able to do with securelevels.


    >>Securelevels are not sound. To a vast extent, anything that changes the
    >>security model of basic unix is not sound. This security model works because
    >>it is simple: users, root, rest of the world. As soon as you add intermediate
    >>shades, there will be some issues. See linux capabilities and how they screwed
    >>sendmail. See how far securelevels have gone since they were introduced.







    *** If they are "not sound" then what are they still doing in OpenBSD kernels?
    Surely they should be made as secure as they possibly can be while they are still
    in the kernel? ???



    *** I agree with the importance of the basic unix model and of the importance of simplicity
    generally , but I do believe that some effective ways do need to be added to curtail some
    of root's powers , at least on some occasions and for some purposes. Look at all of the
    various SUID , GUID , and similar threats. Though I have read that the use of systrace
    policies can limit the windows of opportunity that may exist with the use of these files ,
    I am not aware that the threats have been removed entirely.



    *** I am aware of another user who has sequestered all such files and similar within a separate
    partition that is mounted "ro". As far as I am aware all other partitions can then be mounted
    "nosuid". I will probably implement this myself. I'll probably make my say "/suidbin" partition
    only as large as is required. I'm not sure whether it would be better to use a separate path
    for this partition or add soft symlinks where the sequestered files once were. I consider
    files with a number of unusual permissions to be dangerous. I want to be able to clearly see exactly where
    these files are at all times. I want to focus on them with a view to eventually removing all of them ,
    somehow. It would be nice if the project shared a similar goal. Maybe such sequestration could even
    be recommended or facilitated by the project somehow. At least until such time as files bearing these unusual
    permissions can be demoted or removed somehow.






    >>securelevels are a brain-fart. Nice new concept that makes sense on paper.
    >>Try using them for anything real, and cry.







    *** But why can't they be made to work. As you admit it does make sense on paper.
    The templates are there. It's not like i'm seeking to have the project replicate
    some fantasy item from science fiction. I'm not asking for kernel-level phasers
    or photon torpedo launchers. [Please add these too if you can though. ;-) ]






    >>People who need securelevels-like capabilities get them in a smart, physical
    >>way. You want append-only files ? send your log to another machine that can't
    >>be tampered with !







    *** Ah , but why can't a user have both , physical and software-based protection.
    Defense-in-depth.



    Best Regards , An Odd User.

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

    Anonymous wrote:
    > In article
    > ,
    > Anonymous wrote:
    >
    >> Why can't we save OpenBSD's securelevels? I have great affinity
    >> for the concept of securelevels on OpenBSD. I believe they should
    >> continue to be a core feature in OpenBSD.

    >
    > Marc Espie wrote:
    >
    >> I'm afraid you're quite alone there.

    >
    > That sir , is a mathematical uncertainty.
    >

    Will you /please/ learn how to properly respond and inline quote for USENET?

    Can we drop this now?

+ Reply to Thread