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

[Socketd]

On Wed, 30 Jul 2003 10:39:56 -0500
<freebsd at critesclan.com> 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
NIS. 
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
transfers.
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 
/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. 

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=""
Port_number=""
Client_Password=""
Other_servers=""
Server_password=""

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
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=""
Remote_file=""

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="/etc/group"
Remote_file="/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=""
Remote_file="/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="", 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="/etc/passwd"
Remote_file="/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