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

From: Socketd (
Date: 07/30/03

  • Next message: Socketd: "Re: suid bit files + securing FreeBSD (new program: LockDown)"
    Date: Wed, 30 Jul 2003 20:07:35 +0200
    To: <>,

    On Wed, 30 Jul 2003 10:39:56 -0500
    <> wrote:

    >Without some significant hardening, which I don't have the time to
    > really do,

    Ah, there we have to problem LockDown was designed to solve ;-)

    > If you have
    > some suggestions, I might take them into consideration and look into
    > producing something that might be "port quality." Right now it works
    > on FreeBSD, Linux, HPUX, AIX, and SunOS (all based upon config files).

    LockDown and an IDS solve two different problems. I would like to help
    you build an IDS, but as you said, when it become well known the cracker
    will know how to shut it down.
    I once designed (only designed) something I called CFC (central file
    control), maybe that could be extented to also include some IDS work.
    When you have an central IDS/network monitoring process/file
    control....very handy ;-)

    I found the design (1 years old) maybe LockDown or your IDS could use
    some of the ideas:
    CFC, a secure alternative to NIS?

    What is this new system and why do we need it?
    This is an attempt to make a secure and all around better alternative to
    As not one line of code has been written yet, the design can of course
    be altered.
    Actually the reason you are reading this is because I want to hear your
    opinion of
    the design, so that the coded outcome will be as closed to flawless as
    we can get,
    design-wise that is.
    I am just a 20 years old, self-taught guy and this is my first protocol
    design attempt,
    so I am not a pro at this, not even close, but I hope you like this
    design and agree
    with me regarding the need to replace NIS.

    How does it work?

    I'll call this system CFC (Central File Control), but I think (if this
    design is approved),
    it will be used to distribute/manage user controlling files like
    /etc/passwd, /ect/ftpusers,
    /etc/ftpchroot, /etc/groups and stuff like that to clients of any unix
    type. But as the name
    implies, you can control any file you want.
    CFC must insure the files it control is at all time identical on all the
    clients, so you
    need to have a main CFC server to control the flow of information, as
    the clients can also
    change some files. So you need at least one CFC server, but I also
    recommend a backup server,
    just like a DNS has primary and secondary server. If none of the systems
    is online when
    the client boots, it will just use the files it already have and update
    (if there is an update) later.
    The server contacts the clients regarding update by sending a multicast,
    because using
    multicasts insures a minimum load to the LAN when informing the client
    that they need
    to be updated. Then the clients connect to get the updates, the
    connection between
    the client and server is of course encrypted
    To reduce networking load, CFC relies on time stamps to limit file
    Before we go into more details, let's look at the design of both the
    client and server side.

    The client

    I have done my very best to make clients as easy to configure as
    possible, because you
    will probably have more client than servers.
    So the only info a client needs is:
    The multicast address the client is a member of.
    The server(s) IP and port
    And the password for the server(s)

    Sadly I could not find a secure way for the client to find the server(s)
    by themselves.
    But you can always use hostnames instead of IP's. Maybe someone out
    there can see
    a solution to this small (or at least I think it is small) problem.
    With this information, the client will be able to update the files the
    servers offer
    for update and be able to make local changes global, even though this is
    not a server.
    The reason for the latter this is that, users should not be affected
    (directly) by your
    network running this service. So if changes happens to a users profile
    (name, password, shell),
    the client will then rapport this to the server and the server will
    update the whole network.
    I know this is dangerous, so I have inserted a rule; the clients can
    only change info about
    users whom are not root or a member of wheel.

    The files necessary for at client is:

    /etc/cfc/client.conf is the file where you specify tings like multicast
    and CFC server(s).
    /etc/cfc/timestamp is not a file you need to configure, it is just there
    to store time stamps of shared-files.
    And /bin/cfcc is of course the CFC client daemon,
    When a client boots, the CFC client (also called CFCc) will connect to
    the server and send
    /etc/cfc/timestamp to check if any file need updating. If the timestamp
    file is empty we must
    assume that it is a new client, so it will get all the files the server
    offers for update.
    The client will also connect and search for updates if it gets a
    multicast from the server,
    telling all clients that an update is necessary.
    As mentioned a user can also locally (on the client) change his profile
    so that it affects
    all clients and servers where he has an account. The CFCc will every
    minute or when a multicast
    arrives, check to see if the local passwd file have been changed. If it
    has, the client will check
    if the change has happened to a normal user (not root or wheel member),
    if yes then it will inform
    the server and the server will update the LAN (the server will also
    check to see if the user
    is root or a member of wheel).
    Ok, enough about the client, let's take a look at the server.

    The server

    The server is of course more difficult to configure, but I have tried to
    keep it simple jet flexible.
    With this design you can have many CFC servers on one machine, you just
    have to use different
    multicast for different "netgroups" (as NIS calls them). Maybe it is
    better to have one multicast
    for all clients, but then different group names. Or multicasts for
    different subnets and then
    groups within the subnet multicast group, but then again, if you LAN is
    this big, you probably
    don't want CFC or NIS for security reasons and you would split the
    network and hire admins to
    the different subnets? I don't know jet, but you can help me decide.

    At the server we have these files:
    /etc/cfc/*/* (files to be updated)

    The dir "*" is a dir you create, the admin can create all the dir's he
    wants in /etc/cfc/,
    but he have to include cfcd.conf in everyone then (the timestamp file
    will be created
    by the server). This makes is possible to keep different groups, e.g.
    you may have
    client who need the full password file and some where only wheel members
    are allowed to login.
    Let's see what is in /etc/cfc/*/cfcd.conf

    To be quick about it, Multicast is the multicast the server should use,
    the same
    with the port number and password for the clients. With the
    other_servers="" field
    you specify the other servers IP's and Ports. Server_password is there
    to insure that
    a cracker don't get to much power, by getting the client_password or
    rooting a client (if he tries to set up a CFC server).
    Frankly there is no difference between servers. They will all accept
    clients and
    updates from client, but have the clients first try to update to and
    from the primary server.
    The clients will connect to the server, which is listed first in this
    configuration file. If there
    occurs a multicast from an IP that is not on the client's list it will
    not respond to it. Servers
    also use this which-server-is-listed-first method to determine its place
    in the server hierarchy.
    As and admin you can update you files from any server you want and
    clients can make and get updates
    to and from any server they want, but the servers will know who is in
    charge, so they will forward
    all updates to the first online server on the list and let it update the
    other servers and clients
    on the network. This way if a server goes down the clients and servers
    just use the next one in line,
    and when the primary server comes online again, it will update and take
    over as the primary server.
    A server will not send all it's shared files to another server, if it
    not listed
    in its conf file, so to know the server-password is not enough for a
    cracker to get control of CFC.
    The timestamp file has the same function as with the clients timestamp
    /bin/cfc should be executed when the admin wishes to send out a
    /bin/cfcd is the server daemon program.
    Now it is finally time to look at the files in /etc/cfc/*/, these are
    the files
    the server offer clients (of that multicast address) to download. The
    syntax is as follow:

    This should not be too hard to understand, you tell the system where to
    get the file
    and where the client should put the file. So making a direct copy of,
    let's say, /etc/group is very easy:

    The scheme will of course not work in all cases, so I have added some

    /COMMENT is the most simple one, whatever come after /COMMENT is added
    to the file,
    which also mean the /COMMENT should always be the last keyword to add.
    With this little trick, you can define a whole file just by doing this:
    Hi, this is the context of the "newfile".

    Now a file (/etc/newfile) is created on all clients and the body of the
    file would
    just hold 'Hi, this is the context of the "newfile".'

    /ADD and /DELETE have different meaning after which file is in
    Local_file="", so they
    only have affect in the following files:

    All those files have in common that they are "user control files".
    These functions was added to save the admin from creating and
    maintaining more than one
    (e.g) /etc/group file. With /ADD and /DELETE you can add and delete
    users and groups from
    a file. E.g. if you want to make a /etc/passwd file for a system that
    should only
    allow members of wheel, you just write:

    (Looking back and reading this, I see the syntax could be better ;-))

    You can use one ':' to add or delete users and two ':'s to add or delete
    groups from the file.
    Anyway, I don't know what you think about this new idea; this is just me
    thinking out loud :-)

    _______________________________________________ mailing list
    To unsubscribe, send any mail to ""

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