OpenBSD Journal

Stephanie for OpenBSD 3.6 released

Contributed by grey on from the spike sharpening dept.

dsantos writes in with news on an updated release of Stephanie first introduced by Mike Schiffman:

Stephanie is an OpenBSD hardening package; Viagra for the blowfish, if you will. It adds several security features not present in OpenBSD that many admins and users would like on their systems. Stephanie contains features both for compromise prevention and post-compromise damage reduction; or, last line of defense.
The site for the updated project is:http://www.ethernet.org/~brian/Stephanie/

(Comments are closed)

Comments

  1. By Anonymous Coward (69.197.92.181) on

    Its always funny when people who don't know what they are doing write bad patches like this to try to add security to openbsd, not even realizing they are actually comprimising openbsd's security.

    Comments

    1. By Anonymous Coward (68.232.139.94) on

      Care to provide examples of problems with these patches?

      Comments

      1. By Anonymous Coward (67.71.79.251) on

        Yeah, I'd like to see some too.

        Comments

        1. By Pete (213.145.178.123) on

          As would I.

      2. By djm@ (61.95.66.134) on

        I haven't bothered to look at the newest one, but the last Stephanie patchset introduced a trivial local root in the first 10 lines of the diff (check for yourself, it is totally obvious). Hopefully this one will be of better quality.

        Anyway, the idea of loading hashes of apps into the kernel is dumb, dumb, dumb. If you really want to play games like that (and I think that there are bigger security fish to fry), then at least do it scalably e.g. using public key crypto and signatures in ELF extensions. The Immunix people had a prototype of something similar to this for Linux 5 or so years back IIRC.

    2. By Anonymous Coward (68.161.210.128) on

      if you ever read the intial docs that came out for this in Phrack, you wouldn't make the comment about people "who don't know what they are doing". Why don't you read http://phrack.org/phrack/54/P54-06 for the initial release (for OpenBSD 2.4...)

      Comments

      1. By Anonymous Coward (195.217.242.33) on

        So ... because it appears in Phrack, it is a good idea ?

        Comments

        1. By Anonymous Cowboy69 (217.148.68.113) on

          M.Shiffman always cool projects...

        2. By Anonymous Coward (68.161.210.128) on

          actually no, but the point was to show that it was well thought out and well planned, by someone with a specific and well directed intent.

      2. By Anonymous Coward (69.197.92.181) on

        If you weren't retarded you would realize not everything in phrack is good, and this shares nothing with the original except the name. Its written by a guy that can't code for shit, and has no idea what he is doing.

        Comments

        1. By br1an (212.143.248.148) on

          yeah, unlike you, an anonymous person on a mini-slashdot. :)

          Comments

          1. By Anonymous Coward (69.197.92.181) on

            And I'm not claiming to make openbsd more secure with sketchy patches. Since you are, maybe your coding ability matters a little more than mine?

    3. By br1an (212.143.248.148) on http://ethernet.org/~brian/Stephanie/

      as others mentioned, you don't have to install if you don't want to.

      however.. it has become a trend here in (un)deadly complaining about tremendous amounts of bugs - both in openbsd, ports, packages, and third-party work, all without providing not even one example.

      it is true that earlier releases of stephanie that went under my hands had bugs in them, but such is all software. you are using an OS that gets enormous amounts of bug fixes every day - look at cvs logs. for this release of stephanie i spend extra time making sure, with several people, in several configurations (and on several architectures) that this is the best i can do. if you wanna give it a shot, go ahead and do it, if you don't, at least provide useful bug reports. (as none have already) i've been here long enough to know that words are just words. ;)

      djm@ - your opinion of saving tables of fingerprints in the kernel is okay, but if others here would like to get the bigger picture, let me give it briefly - openbsd forked off netbsd, and shares huge amounts of code with it. most of the work tedu@ is stolen (as he lurks on tech-kern@ and probably other mailing lists) and a lot of netbsd work ends up in openbsd.

      that said, netbsd had code similar to Vexec - in fact, earlier versions (in stephanie for 3.2 and 3.4) used some of it - in the OS core/base/whatever. seeing how many ideas and code gets nuked by netbsd people on the various mailing lists, and how this code made it in, i leave it up to you to decide what way to take. i'm not trying to get it in openbsd's base, nor trying to make it a de-facto standard for openbsd users; i'm just saying that i trust opinions of people like jason thorpe, david laight, and bill tudenmund a but more than damien miller's. ;)

      Comments

      1. By Matt Van Mater (65.205.28.104) on

        I have some questions that maybe you could clear up. What is the intent of the trusted users group, and how does it differ from using sudo? I haven't looked at your actual code, but I just don't see any major differences between the two based on the documentation. /etc/sudoers allows you to specify people or groups of people and the applications you want to allow them to execute... Which is pretty much what your docs say TU will be used for. I saw that these trusted groups would be used in tandem with TPE, but that alone doesn't seem like a good enough reason for you to have created them (you probably could just use regular groups for TPE).

        TPE looks like a slightly more fine grained control of access control. It looks like it was intended to be somewhere between mounting a partition noexec and simply setting ACLs on a directory. I can imagine there are some people who neither want to be super security nazi and mount drives noexec,ro and also who don't want to have ACLs as their sole means of protection.

        I agree with djm about storing the hashtables inside the kernel. I like linux for certain things, but I don't like some distro's habit of putting everything in the kernel for a performance gain. I'm not saying that's what you're doing, but I feel like a kernel mod should be your last resort, and that it's probably not the best way to store/secure that hash.

        Comments

        1. By br1an (212.143.248.148) on http://ethernet.org/~brian/Stephanie/

          above all, the intent of the trust list is to provide interface for selection of who can bypass stephanie's privacy/tpe restrictions without changing too much code. the code itself can also be modified by shell providers to do other things than trust list - the exact opposite, for example, etc. important to note that the trust list in absolutely NO WAY is aimed at being anything like a real acl and/or a sudo replacement. storing the hash tables in kernel memory has zero performance hit. the reason it's stored in kernel memory is that kernel memory is the only trusted place for data storage. any other combination will either fall back to kernel being a trusted location, or depend on things like network storage etc., where things can go extremely wrong. if you have a better idea i invite you to tell me. this is NOT like putting everything in the kernel. it's like increasing NMBCLUSTERS or whatever - it's using more kernel memory. unless your openbsd machine is very very very short of memory, you can be relaxed. stephanie also doesn't allocate any memory doing runtime. the only allocations it does are when fingerprints are loaded. i'd like to again ask people who suggest my way of doing things is wrong to suggest other ideas at the same time...

      2. By Anonymous Coward (69.197.92.181) on

        No, nobody has to install it. But new users tend to be tricked into believing security claims of patches like these, and installing them thinking they are "hardening" openbsd. As someone who got bit by this as a newb myself, I try to warn newer users to stay away from this kind of crap.

      3. By mirabile (212.185.103.56) on http://mirbsd.de/

        One of our developers (MirOS) is indeed interested in vexec, but
        we would like to get a real name on the licence for inclusion,
        or some photo-copy of an official document which states 'br1an'
        is your pseudonym/artist(ic) name. (It's hard to get them here :(

      4. By Miod (212.234.41.17) on

        Sure, but you could at least write Bill Studenmund's name correctly (-:

        Comments

        1. By br1an (212.143.248.148) on

          i figured i could if grey misspelled Schiffman's... ;)

          Comments

          1. By grey (66.197.133.17) on

            D'oh! Thanks for pointing that out. It has been corrected.

  2. By Anonymous Coward (195.217.242.33) on

    "Viagra for the blowfish, if you will."

    Oh dear

  3. By Anonymous Coward (203.206.244.7) on

    brians a good guy, he's commited to his work, and he's supported openbsd for a long time, by code, $, or answering your newb questions on irc.

    noones got a gun to your head to install this.

    search the archives for what some commiters think. if something really pisses you off, write a patch to fix it. otherwise just shutup, you're not helping.

    its the openbsd way

    or at least it used to be.

    Comments

    1. By Anonymous Coward (67.71.79.251) on

      I personally couldn't agree with you more! I think he deserves a hell of a lot more credit than people trying to shoot him down, for some reason. Judging from his replies, he's asking for 'contructive criticism' not just nagging like my ex gf! It's simple, if you don't like it or don't need it, don't use it. If you like it or see potential to fix it more or better, then help fix it! I think just the idea alone is great and has a lot of potential - it's all about choice!

  4. By Anonymous Coward (211.30.147.144) on

    I'm a relatively newbie to OpenBSD, but what's the point of this, err, third-party enhancement?

    Is it more likely to increase or decrease security compared to a regular OpenBSD setup? (because I'm confused at these statements made by others)

    Does Brian's enhancements end up in the official OpenBSD package?
    Are they audited in the same manner as well?

    Any experienced OpenBSD user input would be appreciated.

    Comments

    1. By Matt Van Mater (65.205.28.104) on

      People are skeptical of this due to problems in previous releases of Stephanie that introduced a local root exploit (see DJM's post above).

      I can't speak to the quality of this particular patch set, but that is why people are badmouthing it. Also, it will almost certainly not end up in the core install of obsd. The dev team thinks it creates more problems than it's worth (see DJM above), and from my limited knowledge of the subject I tend to agree.

  6. Comments

    1. By Anonymous Coward (141.39.2.1) on

      both are shit

      Comments

      1. By CFrankB (63.255.174.162) on

        I've been waiting for an intelligent reply. Thanks, Anal Coward.

  7. By Chas (147.154.235.53) on

    smbclient and Oracle's sqlplus utility both like to take passwords on the command line.

    Oracle has long offered an unsupported utility called hide.c that writes 3000 chars into argv[0], which on most systems is sufficient to prevent the ps command from revealing passwords. I have also written a ksh93 script that accomplishes the same thing.

    However, on OpenBSD, even after adding 10000 extra chars, a ps awwx will still reveal all the argument list.

    I realize that I should answer my own question and dig into the source for the kernel process table, but why is this happening and what can be done on OpenBSD to conceal sensitive argument vectors from ps?

    Right now, Stephanie would be my first recourse in accomplishing this (however flawed/risky some may think that to be).

    Comments

    1. By Anonymous Coward (65.205.204.37) on

      Why not have those utilities fixed os they don't specify passwords on the command line? That is the real problem.

      Comments

      1. By chas (147.154.235.53) on

        If you've got the source to Oracle's sqlplus, you'd better keep quiet about it.

        AFAIK, Oracle uses the same sqlplus codebase to generate binaries for UNIXen, VAX/Alpha VMS, MVS/zOS, and Win32. I guess that they've argued that they don't want too much UNIX influence in the source.

        Comments

        1. By tedu (66.93.171.98) on

          how would adding a password prompt contaminate sqlplus with unix-ness?

          and since it already does prompt for a password if you don't provide one, it looks like they've managed to cope with said contamination.

    2. By Anonymous Coward (69.197.92.181) on

      Don't use incorrect software that requires you to give your password as a command line switch.

      Comments

      1. By Chas (147.154.235.53) on

        Not all software is good, and sometimes critical data requires less than perfect access methods.

        If your customer needs their order status out of an Oracle database, or they need to see some document held on a Win32 file server, you can't tell the business that it is inappropriate to use working technology because of a stance that really resembles a whim.

        Comments

        1. By Anonymous Coward (69.197.92.181) on

          How about providing a real example then? Cause oracle's client doesn't force you to be stupid, you can let it prompt you for the password just like psql and mysql. What's an app that forces you to supply your password on the command line?

          Comments

          1. By Chas (64.109.19.61) on

            Actually, show me how to do it in VMS and I'll give you a dollar.

            Comments

            1. By Anonymous Coward (66.93.171.98) on

              $ DEFINE/user sys$output tmppass
              $ TYPE passwordfile
              $ DEFINE/user sys$input tmppass
              $ sqlplus
              $ DELETE tmppass

              or so.

              Comments

              1. By Chas (147.154.235.51) on

                $ sqlplus

                Notice that I said smbclient. Linked to Multinet. On a VAX.

                I'll keep my dollar, thanks.

                Comments

                1. By tedu (66.93.171.98) on

                  and how will the stephanie patch fix your vax again?

                  don't you have the source for smbclient?

                  so far, your posts have described the following problem:
                  you need to patch the openbsd kernel to run sqlplus because you don't have the source in order to run smbclient on a vms machine.

                  did i get that right? i just want to make sure i understand the problem.

                  Comments

                  1. By Chas (147.154.235.51) on

                    I was asked for "a real example," and smbclient under VMS fits (smbclient is NOT an Oracle product - it is part of the Samba suite).

                    When you have to deploy something like smbclient or Oracle across several different technologies, it becomes tempting to use the simplest methods possible, and this will mean passwords in argv visible in the process list (on UNIX).

                    Stephanie is the only method that I know of on OpenBSD that conceals argv, should I decide that I need the functionality in the future.

                    Comments

                    1. By Michiel van Baak (80.126.97.99) michiel@vanbaak.info on

                      how about not allowing ps access to users ? Or simply make a wrapper that only allows ps without arguments. That way users can still see their own processes but not see the password etc. But what I would do is to mount smb shares with the help of /etc/fstab (and chmod 600 it)

                      Comments

                      1. By tedu (66.93.171.98) on

                        and what prevents me from running my own copy of ps? you could mount all user partitions noexec, but that can be annoying in some situations.

                        Comments

                        1. By mirabile (212.185.103.56) on http://mirbsd.de/

                          $ sudo sysctl -w kern.allowpsa=0

                          Yes, I know, -w is optional...

                          If you're interested, I can pick out that as a diff again.

                          Comments

                          1. By br1an (212.143.248.148) on

                            i personally think that if you're going to implement something like that in openbsd, at least make it ready for the future. what i'd like to see eventually is removing all kvm uses from the source tree for retrieval of 'live' information, and the addition of privacy routine(s) to the kernel/sysctl (pass a proc to all sysctls?) aswell as a sysctl node for controlling these.

                            i believe that moving more code to use sysctls instead of kvm will probably be a far better contribution to the openbsd source tree than the boring 'allowpsa' and 'allowpse'.

    3. By mirabile (212.185.103.56) on http://mirbsd.de/

      MirOS has got two new sysctls, named kern.allowpsa and kern.allowpse
      (mostly because I'm not good at picking names), which accomplish that.

      Some (about a third) of the code, and the whole idea, are from a mail
      (IIRC) Todd Fries sent to me, asking if I could fix that. When I was
      ready, they won't include it because they will be pursuing a different
      approach, that's what I was told.
      In the meanwhile, it works well on my boxen.

  8. By res (64.180.113.251) on

    i've been using these for a while now, i don't plan to use vexec, but the privacy patches are very nice to have on a multiuser system, i find the trusted users group to be a reasonable way of dealing with bypassing these privacy restrictions for certain users, and trusted path execution seems to work very well (i can't seem to break it yet anyway)

    for every project there are people making claims about its poor security, trying to sound like some professional security auditor that has laughed his ass off reading every line.

    well, i think he's done a pretty good job this time (haven't seen his past efforts, and who cares)

    there are many people that talk such smack about openbsd itself in the manner most of you are talking about this project. in fact, i've seen very similar 'what a shitty coder' comments made about theo on more than 100 occasions. i'm sure theo has written software with a security hole or two in his past, but he's moved on to write excellent software.

    why not give it a chance, or if you are so skeptical, why don't you prove it to be a peice of shit by auditing it yourself? it's fun

    just like openbsd and everything else i use, i hope someone finds a serious hole or two in stephanie so it can be fixed (i am certain they both have bugs left), and be that much more secure for it.

    Comments

    1. By EN (81.227.101.233) on

      Nice speaking. I hope this will be the end of stupid flame about "shitty or no".

  9. By Anonymous Coward (211.30.147.144) on

    I see, so one should try these "enhancements" if they're just playing around...Not for production setups.

    Comments

    1. By zerash (24.73.232.98) zerash@metawire.org on http://www.metawire.org/~zerash/

      It would make more sense if you would actually test them out, before making assumptions regarding the use of these patches on production servers?


      -Dan

  10. By zerash (24.73.232.98) zerash@metawire.org on http://www.metawire.org/~zerash/

    Hi,

    Brian implemented Stephanie on metawire.org, practically as soon as he joined our admin team, thus we had a chance to use it/run it for already a couple of months before the official release for 3.6.

    Claims such as the first comment, regarding that using Stephanie would only decrease security and performance are simply outrageous; especially coming from someone who most likely hasn't even tried applying the patches in the first place.

    Metawire currently houses over five thousand users and this whole time has been running with Stephanie hand in hand, without a glitch and barely any increase in performance. I've personally watched brian work on this project day to day, enhancing performance day by day, and although it might not seem as much, I can vouch(sp?) for the excellent quality of these patches without a doubt.

    Our systems are stable, loads are good and all the patches help the security of the system tremendously.

    -Dan


    Comments

    1. By riddler (82.208.148.206) ealex@metawire.org on http://riddler.metawire.org

      I will in first place admit my experience in both OpenBSD and programming is largely limited, thus I can't make any practical judgements as to how well br1an's code involving Stephanie is written. Despite this fact, issueing judgements without proper testing and auditing the code you are openly bashing is a big no-no, and only proves you to be a totally clueless tard. I've run Stephanie for 3.4 on my 3.3 box some time ago, and br1an helped me backport it. He is an excellent develepor and more so as he takes time to talk to people and explain his code out to those who don't have higher coding skills, or to whom parts of the code seem unclear/unsecure/unreliable. I've seen Stephania work on Metawire as well, and as far as performance is involved I can say, that unless you're trying to run this on an old 8086 with 256kb of memory, you won't have anything to worry about.

      And again, with the risk of repeating what has been said, if you claim something is wrong with the code, speak out, point out the holes, make patches, support it. Otherwise you're useless and wasting air.

      Using or not-using this depends merely on the trust you have in the authors skills, if you have none of your own, as is the case with anything out there, from Windows (TM) to Openbsd, to apache, minesweeper or hell knows what else. You trust the source, you run the code. If you don't, audit it if you can, if not, just leave it be, don't go off and bash it with kiddiot posts.

      Anyone can troll and destroy. Not everyone can support and be constructive.

      EOF

    2. By Anonymous Coward (69.197.92.181) on

      The first post didn't say anything about performance, what are you crying about? I said these patches do not add security, and since they are written by someone who has proved in the past not to write secure code, they in fact make the system less secure.

Latest Articles

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.]