Ann Harrison wrote:

>
> Reed Mideke wrote:
>

[...]

>
> 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.
>

Exactly! Although I suppose I could add
Modify data in the database without being noticed.

An optional audit trail for sysdba (at least) might not be a bad idea.
I can remember several instances where someone with sysdba rights
made changes that they shouldn't have (not malliciously). Tracking down
the offender would be much easier if there was even something like
the logging done for su on unix systems. For example
[ip address] succesfully connected as sysdba
[ip address] gave an invalid password for sysdba
etc.

> >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.
>

I wasn't so much refering to those with direct (ie console + admin)
access to the server, but others familiar with the environment and
inside the firewall. I pretty much agree that if you're sysadmin

>really< wants to get at your data, s/he probably already can, and

by definiton s/he alread has control of your machine. It's your own
d*** fault if you hire a crooked sysadin ;-0


[snip]

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

I agree. BTW, what I ment by plugins was some fairly flexable way
of letting some other service do/verify the authentication. Giving
sites the option of using their whatever their single sign on
system might be. Of course, you then have to worry about the security
of your plug-in mechanism. I have no idea what the practicalities
of the situation are. How do Oracle, MS etc do it ?

BTW: Both NT an many unixes have a system like this. On solaris and
linux (at least) it's called pam, and lets the sysadmin choose whether
your login goes through /etc/passwd, NIS or some
other system (or rather nswitch.conf does the choosing and
pam makes sure it happens).
On nt, you can use the microsoft native method,
or replace it like the netware client does.

[...]

>
> 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.

Many services (samba, apache, for example) let you limit who can
connect by network address/range. While this can in some situations
be defeated by address spoofing, it might be a good idea for IB.
For classic on linux (and presumably other unix you should already)
be able to do this with tcpd.

[....]

> 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.
>

Yup.

> Ann
>

On the topic of security enhancments, if you run IB as a web backend,
and run the ibserver on the same machine as the web server, it would
seem to be a good idea to use IPC and disable tcp/ip (both for security
and efficiency). Previously, this could be done with by using a local
interbase license.
Now that the licensing code is removed, there should be a configuration
option to enable or disable specific protocols.
--
Reed Mideke
rfm(at)collectivecomputing.com