Reed Mideke wrote:

> > 8.- Minor security enhancements:
>
>Although I subscribe to the idea that open source has the >potential<
>to be more secure than closed source, that will take time. If IB becomes
>popular, especially in situations where it is exposed over the internet,
>there will be a lot of people looking at it as a way of breaking into
>systems.

Yes, and I worry about that. We closed a couple of small holes
I won't mention at the moment, but there are still larger issues.
One that's been mentioned recently is the length of passwords.

>These attackers may want the data from the IB databases, or they may
>just want to use IB as a way of gaining access to the system (and they
>might attack you system just so thay can use it to attack someone else.)

I think there are (at least) five types of attackers.

read information from the database.
destroy data in the database.
crash the IBServer.
crash the server system.
use IB to penetrate and subvert the server system.

>It's also important to remember that many (some say the majority) of
>attacks originate within the victims organization. So just blocking e
>3050 in the firewall is not a real solution.

My own belief is that we can not protect the database from those
who have physical access to it. Nor can we keep a disgruntled
system administrator from causing damage. However, we should
be able to keep unauthorized people out and limit people to their
authorized areas.

> > - Check possible buffer overruns in the API.
>I'm not sure how vulnerable IB is. I'm hoping that the remote protocol
>was reasonably designed so that this isn't a huge problem. With client
>source available, it will be very easy to send invalid packets to
>the server.

Right.

> > - At least detect (and warn about wrong) security permissions on
> > the target directories at installation time, if possible.
>Indeed, there should be guidelines as to what files are owned
>by who, and what permissions they should have, and these should
>be checked or installed by default.

Right.

>There is also a wider problem here. Any user can create a database
>(making them the DB owner), and any database owner can create an
>external table. This gives them the ability to create and read files
>anywhere the server can. Even if you run as non root (on unix) this
>make all kinds of potential mischief possible. The situation is much
>worse on NT, since IB runs as LocalSystem. I would wager that any
>motiviated person with a valid interbase logon could become admin
>on your NT box.

That certainly argues for limiting the ability to create databases.

>Of course you have to do a lot of work to make NT reasonably secure to
>begin with (see ntbugtraq.com, for example for some hints on getting
>there). I'm not sure if there is any problem running IB service as
>another user on NT. Anyone tried ?


>BTW, running the server as interbase refers to Super server. Classic
> >sometimes< runs with the unix uid of the user, but (ISTR) it runs as
>root if the user comes in from a PC.

Classic has some terrible security holes.

>Anyway, it seems like there should be some user security above the
>database level, meaning that the server could be set up so
>that only some users can create databases. I believe there was
>some research into this for post 6.0.


>It also seems that there should be some consideration given
>to the hosts_equiv, and ISC4.GDB methods of user authentication.
>Should the set of 'users who can log into the db server' always
>be included in 'users who can connect to databases'. How hard
>would it be to make interbase have plugable authentication mechinisms ?

I'm not sure plug-ins are the right answer. Nor am I comfortable
with the "one login for all databases" philosophy.

> > - Probably most of you know that really the pw for SYSDBA is masterke,
> > because it uses only the first 8 characters... Since the algorithm is known
> > (and a good cracker will be able to know it even if it's not published
> as it
> > happened with Netscape encryption) and the salt is fixed, at least the pw
> > must be allowed to be 16 or 32 characters; I don't imagine a terrible
> impact
> > on the server's code.
>Password length isn't that important right now, since anyone who can
>sniff your network can inject the encrypted passwords into their
>own packets. When the client source is available this will be much
>easier, since they could just make the client use some previously
>sniffed encrypeted password. But even now, a motivated individual
>could a) disassemble and modify the client or b) put something between
>the client and the network interface that rewrites the (encrypeted)
>password. (btw, the NT CIFS filesytem suffers from a similar
>problem, although under ideal conditions it's not quite as bad)

Password security on the wire is an important issue.

>Secure user authentication is a tricky thing (witness how may times
>microsoft has buggered it up). It would be neat if
>IB could leverage some existing infrastructure, rather than
>rolling our own.

Yes. Here are some comments from another discussion:

> > Add these three keywords to be handled like USER, and
> > available generally.
> > ROLE
> > TRANSACTION NUMBER
> > CLIENT ADDRESS (IP/NETBIOS etc)
> >
> > The ROLE, and CLIENT ADDRESS, would be used in extended security
> > Very often, I have triggers that say 'if user = XXX then ....'
> > but it would be nice to say 'if ROLE = backup then....' The
> > ADDRESS would allows me to restrict a user from getting certain
> > information or running certain processes unless they are at
> > known locations.

>As for password strength, current method is fairly suceptable to brute
>force, but as soon as the source it availabe, it should be easy to
>create something like the linux interantional patch to use
>a bigger key anyway (while still staying withing the US's idiotic
>crypto laws)

>Also remember that if the password is coded into the client app
>or stored in the registry somewhere, no strength of crypto will
>help.

That was the reason for using hosts and accepting incoming
connections verified by their host system. Needless to say,
PC's put an end to that.

> > - Predefined SYSTEM-ROLES. One thing that I appreciate of MickeySoft's
> > SqlServer is the predefined roles. In IB, the power tasks are either
> > achieved by SYSDBA or not achieved at all. Only sysdba can shutdown and
> > restart a db. Only sysdba can connect to a db after the shutdown command.
> > Only sysdba can traverse happily the whole database, above normal SQL
> > rights. Only sysdba or the owner of the db can validate a db. In the
> > statistics option, a simple user can see header page and db log. Again,
> only
> > the owner and sysdba can get all the statistics. A predefined AUX-ADMIN or
> > POWER-USER would help a bit, so you can grant these roles to common users.
>
>This fits in with my comments on server level security.

It has certainly been mentioned before that the ability to shutdown the
database should not go hand-in-hand with the ability to read every bit
of data.

Ann