From owner-freebsd-security@FreeBSD.ORG Wed Jul 30 10:58:22 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 30F7D37B401 for ; Wed, 30 Jul 2003 10:58:22 -0700 (PDT) Received: from cicero1.cybercity.dk (cicero1.cybercity.dk [212.242.40.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D924143F85 for ; Wed, 30 Jul 2003 10:58:20 -0700 (PDT) (envelope-from db@traceroute.dk) Received: from user1.cybercity.dk (fxp0.user1.ip.cybercity.dk [212.242.41.34]) by cicero1.cybercity.dk (Postfix) with ESMTP id 05A6FA44D7; Wed, 30 Jul 2003 19:58:14 +0200 (CEST) Received: from main (port132.ds1-arsy.adsl.cybercity.dk [212.242.239.73]) by user1.cybercity.dk (Postfix) with SMTP id 407B868B32; Wed, 30 Jul 2003 19:58:02 +0200 (CEST) Date: Wed, 30 Jul 2003 20:07:35 +0200 From: Socketd To: , security@freebsd.org Message-Id: <20030730200735.37365833.db@traceroute.dk> In-Reply-To: References: <20030730015431.4120c648.db@traceroute.dk> X-Mailer: Sylpheed version 0.8.10claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: suid bit files + securing FreeBSD (new program: LockDown) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2003 17:58:22 -0000 On Wed, 30 Jul 2003 10:39:56 -0500 wrote: >Without some significant hardening, which I don't have the time to > really do,=20 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=BD 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? =20 This is an attempt to make a secure and all around better alternative to NIS.=20 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.=20 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? =20 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 transfers. Before we go into more details, let's look at the design of both the client and server side. =20 The client I have done my very best to make clients as easy to configure as possible, because you=20 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=20 /etc/cfc/timestamp /bin/cfcc /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.=20 At the server we have these files: /etc/cfc/*/cfcd.conf /etc/cfc/*/timestamp /etc/cfc/*/* (files to be updated) /bin/cfc /bin/cfcd 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 Multicast=3D"" Port_number=3D"" Client_Password=3D"" Other_servers=3D"" Server_password=3D"" 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=3D"" 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).=20 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 file. /bin/cfc should be executed when the admin wishes to send out a multicast. /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: Local_file=3D"" Remote_file=3D"" 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: Local_file=3D"/etc/group" Remote_file=3D"/etc/group" The scheme will of course not work in all cases, so I have added some keywords: /ADD /DELETE /COMMENT /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: Local_file=3D"" Remote_file=3D"/etc/newfile" /COMMENT 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=3D"", so they only have affect in the following files: /etc/groups /etc/passwd /etc/ftpusers /etc/ftpchroot More? 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: Local_file=3D"/etc/passwd" Remote_file=3D"/etc/passwd" /DELETE ALL /ADD ::wheel (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 :-) #EOF br socketd