OpenBSD Journal

pflogd privsep committed

Contributed by jose on from the safer-PF-logging dept.

Chad Loder writes: "canacar@ has committed privsep for pflogd to CVS:


http://marc.theaimsgroup.com/?l=openbsd-cvs&m=106684950032748&w=2


Log message:
privilege seperated pflogd

_pflogd user and group must be created for proper operation.

Note that you'll have to add a _pflogd user to use this right, but other than that you're all set. Thanks, guys.

(Comments are closed)


Comments
  1. By gwyllion () on

    http://marc.theaimsgroup.com/?l=openbsd-cvs&m=106684834031056&w=2 looks nice as well. Will other programs (like dhcpd) use this security feature as well?

  2. By FenderQ () on

    Has anyone tried using dhclient after these code changes? The send_packet() function in /usr/src/usr.sbin/dhcp/common/bpf.c
    The kernel changes to bpf.h and bpf.c?

    Cool feature though..... Nice work. :-)

    Comments
    1. By Can Erkin Acar () on

      fixed. It was a last minute change gone bad. :(

      Comments
      1. By FenderQ () on

        Awesome! Dhclient is working for me now ;-)
        Thanks again for resolving that so quick.

  3. By Anonymous Coward () on

    why add code on syslog, sshd and now pflogd, to do privsep when systrace could restrict previlege on the process and result in a process secure as well?

    Comments
    1. By Anonymous Coward () on

      Just because systrace unfortunally adds some overhead... Btw you can still use systrace with privsep'ed pflogd ``... permit, if user = blah''
      Shipping a base system systraced isnt that easy.

    2. By schubert () on http://schubert.cx/

      The usual problem is that what systrace policy works for you, might not work for me; might not work for the other guy using some esoteric feature of the program that most of us don't use.

    3. By Petr R. () pruzicka@openbsd.cz on http://www.openbsd.cz

      And services are not systraced by default, but they have privsep by default.

    4. By tedu () on

      and how is your systrace policy going to tell the difference between sshd calling exec("/bin/sh") because you authenticated successfully, and sshd calling exec("/bin/sh") because it was exploited?

      Comments
      1. By djm () on

        user predicates: if user = "_sshd" then deny

        It won't stop an exploit in the monitor though. While the privsep child itsn't likely to be calling exec in /ver/empty, it might try to create and bind sockets to scan or attack one's network. systrace could help here.

        IIRC the folks at monkey.org have a good sshd systrace policy. I have never used it though, but I do use systrace for things like rsync - which I don't fully trust.

        Comments
        1. By Anil () avsm@ on mailto:avsm@

          It's generally a _lot_ easier to systrace the unpriv child in a privsep program than it is to systrace a normal app. You don't have file ops to worry about as much. I've got a few patches to syslogd that do this; I'll clean it up next week.

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