Re: suid bit files + securing FreeBSD (new program: LockDown)

From: D J Hawkey Jr (hawkeyd_at_visi.com)
Date: 07/27/03

  • Next message: Socketd: "Re: suid bit files + securing FreeBSD (new program: LockDown)"
    Date: Sun, 27 Jul 2003 10:29:23 -0500
    To: Socketd <db@traceroute.dk>
    
    

    On Jul 27, at 03:52 PM, Socketd wrote:
    >
    > On Sun, 27 Jul 2003 07:51:36 -0500
    > D J Hawkey Jr <hawkeyd@visi.com> wrote:
    >
    > > It could certainly be installed from the ports collection, but it
    > > would be most useful to me (and p'raps others?) as a boot-time thang.
    > > Think of dedicated firewalls and routers, especially those that boot
    > > from custom CDs [and p'raps read floppies for "volatile"
    > > configuration].
    > >
    > > In my mind, the conf could be installed as /etc/rc.whatever, and the
    > > program could be installed as /usr/local/etc/rc.d/whatever. In this
    > > way, it'd be run on boot, and could be run anytime as
    > > "/usr/local/etc/rc.d/whatever start", and p'raps as a cronjob, too.
    >
    > Ah, good idea!
    >
    > LockDown could search for ALL suid and gid files and set the
    > permissions accordingly to the conf file, the files not listed there
    > would be disabled (or set to a user specified default)...

    Now you're thinking along the lines I'm thinking. Something of a system
    hyper- or super-visor.

    > ...But then again,
    > if an admin installs a port with suid files and forget to add them to
    > the LockDown conf file, they would be disabled the next time LockDown is
    > executed.

    We-ell, the admin ought not forget that, eh? ;-,

    The program could notify the admin in some manner or another when it
    disables something - I've written a few scripts that mail a cell 'phone
    or pager when they do something that should be known of when it happens.
    A log entry via syslogd(8) is mandatory, of course.

    > I have also thought about adding these options:
    > 1. More kernel help, so you quickly can setup a kernel:
    > kern_using_RAID="" YES if you are using raid hardware
    > kern_using_SCSI="" YES if you are using SCSI hardware
    > kern_using_IPv6="" YES if you want to use IPv6
    > kern_using_proc="" YES if you want to use /proc
    > kern_NIC="" The nic's you use.
    >
    > 2. Support for most of the files in /etc (and other?)
    >
    > 3. Give security adwise:
    > 1. Setting up different daemons
    > 2. What ports to install
    > 3. How to setup scripts to be used with cron and what to
    > include in them

    I wouldn't go too far "out of scope" too fast; you might end up re-writing
    Tripwire!

    I do like the idea of checking /etc... maybe... using cksum(1), or
    something like that. I currently use local periodic(8) scripts, similar
    to /etc/periodic/daily/2*, that backs up /etc, /etc/mail, and /etc/namedb.

    Regarding the above comment about forgetful admins, they also have to
    remember to update Tripwire's config file(s), don'tcha know.

    > > Were you to go this way, I could see where Core might consider adding
    > > your work into the base? I'd lobby for it. :-)
    >
    > My code in the base system...oh I don't even dare think the beautiful
    > thought ;-)

    NOTE: I'm not a committer! I only mention the possibility; I can't make
    it so.

    > > > I use C++
    > >
    > > Oh. I was hoping you'd answer "shell script" (my preference, for quick
    > > 'n easy modification), or "C".
    >
    > Well, it could be written as a shell script, but I only know C++. If
    > someone want to join this project and write the shell script, I would be
    > happy to help with the overall design and documentation.

    I've gotten pretty fluent with sh(1), awk(1), and sed(1). I could pro'lly
    write what you envision in a shell script. I wouldn't want to re-write a
    C++ program though; I'm not well versed in C++'s "nuances".

    Dave

    -- 
      ______________________                         ______________________
      \__________________   \    D. J. HAWKEY JR.   /   __________________/
         \________________/\     hawkeyd@visi.com    /\________________/
                          http://www.visi.com/~hawkeyd/
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"
    

  • Next message: Socketd: "Re: suid bit files + securing FreeBSD (new program: LockDown)"

    Relevant Pages

    • Re: Administrative Rights Installation Issue
      ... Admin Local Group upon joining the domain. ... What about the domain user itself ... one machine and I did see the local administrator and Domain Admins group ... As far as an example for software installs with admin rights. ...
      (microsoft.public.windows.server.networking)
    • Re: Permissions on Event Log?
      ... So now I need two installs if I'm not admin, just so I can have an event ... I can create my own log file without admin privileges. ... Build a small app that pre-creates the event sources at deployment time ...
      (microsoft.public.dotnet.security)
    • Re: GNU Common Lisp for FreeBSD
      ... Why not ask your admin for that? ... console with garbage when i use arrow keys to navigate the command ... you get to work out how to use the information in the ports collection ... selected sections of the porter's handbook as well. ...
      (comp.unix.bsd.freebsd.misc)
    • installation woe(s)
      ... my app installs itself then msde with the securitymode=sql...the app ... installs for "everyone" and not "just me". ... user account that has access to the deviceis in the admin group. ...
      (microsoft.public.dotnet.languages.vb)
    • Re: Will Photoshop 7 work with Vita 32?
      ... Right click the setup.exe icon and select run as admin. ... If it installs it should work. ... If it doesn;t and you need a photo editor then there are alternatives ...
      (microsoft.public.windows.vista.music_pictures_video)