OpenBSD Journal

Extra Security in BSD

Contributed by jose on from the onlamp-and-devworks dept.

While cruising the O'Reilly OnLamp and IBM DeveloperWorks sites recently, I came across a set of articles which may be of interest to the OpenBSD Journal readers.

The first two are from the Big Scary Daemon column on BSD. These articles discuss the use of groups to achieve security. By using this approach, multiple read and write groups can be created, allowing for controlled access to files. The second is a sudo tutorial . The sudo tool allows for controlled escalated priviledge use for multiple users.

Lastly, the IBM DeveloperWorks site has a nice article on web server security . Noting the number of httpd and SSL security issues lately, this one is worth a good read.

(Comments are closed)

Comments

  1. By RC () on

    I've been thinking of writing an "Advanced Permissions Howto" for some time now... One of the things that I've thought of in the process:

    Since it would take a small ammount of work to allow files to belong to multiple (~3) groups, and have different permissions for each group (RW, R), what is the TrustedBSD project doing with their piles of funding?

    Comments

    1. By schubert () on

      MACs or Mandatory Access Controls are hard to do "right". That said, its also complex for the end user (admin) to implement properly because a single screwup can hose the whole protection scheme. They are also implementing various other tidbits (auditing etc). Hence... what is TrustedBSD doing with their pile of DARPA money? Coding, which is more than what you're doing by dismissing their work with one snide comment.

      Comments

      1. By RC () on

        Let me guess... and if I critcize Bush I must be anti-American too???

        I've seen far too much of this 'rather than address the issue, let's start name-calling' tactic.

        Comments

        1. By Anonymous Coward () on

          There's basically far too much namecalling on deadly.org as it is.

          TrustedBSD is a very cool project. The all-or-nothing model of root and user perms is a very bad idea and we can't get a higher level of security until we get rid of it. Just to possibly head off some name calling, me saying that TrustedBSD is on the right path does not equate to saying that OpenBSD isn't on the right path, of course, because there are several variants of the right path in this case, I think.

          Comments

          1. By Anonymous Coward () on

            The problem I - as an not _that_ experienced user - is that there are too many "secure BSD" projects out there. well, too many might be exaggerated. But there's MicroBSD and TrustedBSD - what are the (dis-)advantages and differences of each..?

            Comments

            1. By Sam () on

              Why not go and read their webpages?
              If it does what you want and you can understand it, why not use it? If you can't understand it, maybe that says something.

              It is quite clear what Micro and Trusted BSD do
              by reading their websites. Which is what they're there for.

              Comments

              1. By SKULL () on


                Well, reading a website is just as good or honest
                as the designer or pr or sales people want to be. If we just read certain websites whose name begins with an M and ends with ICROSOFT you might conclude that their products are secure. Their ads say so, and so does their website, right?

                A website only tells you what they want to tell you, and simply calling themselves "secure" is a difficult or impossible to evaluate statement for most people, or perhaps anyone.Where are the security standards?

                I have yet to even see a really solid explanation of a neutral method of evaluating OS security that presumably OpenBSD would do well on(?).

                The statement about exploitable defaults is too easy to win by simply turning everything off - does that mean redhat 6.2 is secure if I repackage it with everything turned off and then send it to you? It's still problematic.

                The source code audit is something that sounds like a good thing, but the audits suffer from problems too - they miss things. And how to you measure two different audited products? By the number of auditors, or number of hours? And presumably a well coded but unaudited piece of software is better than bad audited code. Do we prefer the bad code /because/ it's audited?

                Which brings us back to /good/ code? Who evaluates it? And what standards?

                One of the things which brings insecurity is bad administration and bad configuration, something which is wholly unaddressed in many discussions. By burying good administrative practices in complex (but arguably good) docs, much good administration goes unimplemented. Who cares if it's well written, perfectly audited, but then badly configured-and-thus-insecure software? That people declaim responsibility after the initial release doesn't mean that that is a logical break in the chain of a claim for security. If I make something that is easy made into something I don't intend (i.e. insecure) is it really secure?



                Comments

                1. By francisco () on http://www.blackant.net/

                  One of the things which brings insecurity is bad administration and bad configuration, something which is wholly unaddressed in many discussions.

                  definitely bad administration is OS independant.
                  this points to one benefit of running nothing by default and having good docs. everything you need, you must turn on and hence you know what you did. even if you are new and dont understand it, you are forced into responsibility, forced into at least knowing one source of information on the functionality in question.

          2. By RC () on

            > The all-or-nothing model of root and user
            > perms is a very bad idea and we can't get
            > a higher level of security until we get rid of it.

            You're right it is a bad idea... POOF! It's already gone. It's quite trivial make a user account, then selectively give them permissions to certain programs and files. The only time it's a Root-or-nothing sdituation is if you don't know how to use the Unix permissions effectively to delegate privlidges to certian users.

            Throw in TCP/UDP port ACLs and Unix's permsissions are suffeciently powerful... And by that I mean you can do practically everything that you could with ACLs, without the needless added complexity.

            You can say TrustedBSD is on the right path, but at least give some example of what features it has added that other BSDs/Unixes don't have.

        2. By zil0g () on

          but he looks like a chimp! hahahaha

          (now really guys... let's all have a chill-pill)

    2. By Anonymous Coward () on

      Some of us would really appreciate a how-to like this if you were serious about possibly writing one. :)

      Comments

      1. By RC () on

        The very-very-very rough-draft(s) is/are already written. The boring part of rewriting it, is something I've been putting off for quite some time now, and haven't had much reason to do it.

        Unlike writers for certain websites (*Ahem*), I don't get paid for spewing out crappy articles on incredibly easy subjects. Nor do I get anything from writing a great and wonderful article that might help a great many people, so the motivation just isn't there.

        Conversly, Unix pros get paid based on what they know, that the competition doesn't. So the more I give away, the less valuable I am in the job market.

        Comments welcome.

  2. By Anonymous Coward () on

    Sure there have been a number of httpd and SSL issues recently. But whoever said sudo was anything near a mature, secure code base? It has had more problems than httpd and SSL combined in recent times.

    Comments

    1. By Jeff Flowers () on

      Shouldn't the version of sudo included with OpenBSD be fairly secure? I was under the impression that a code audit of OpenBSD's sudo had taken place.

      Comments

      1. By mra () on

        I personally like the sudo that is included with OpenBSD, that said, it had an issue just a few months back where I believe an enviroment variable was the delivery mechanism for an overflow that gained root.

      2. By Anonymous Coward () on

        I believe Todd Miller has been working on a sudo overhaul - not sure what the status is (might be done already). Check CVS?

  3. By AP () a_prades@yahoo.com on mailto:a_prades@yahoo.com

    How about changing the default rights for " other" in the logs directory? Most of them have 644 rights, why ?

    Comments

    1. By Anonymous Coward () on

      AP, What are u talking about ?

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