Subject | RE: [Firebird-Architect] Firebird init script |
---|---|
Author | Rick Debay |
Post date | 2006-03-28T17:27:58Z |
It is not for testing purposes, and it's not for convenience.
NO ONE should have to su to root, after installation is complete. Ever.
The database admin shouldn't be able to su to root. They should have
enough permissions to be dangerous to the database application. They
should not have any permissions that would permit them to be even
slightly dangerous to anything else on the system.
I was at an insurance company that had a whole floor just for Oracle
admins and the like. They could do whatever they wanted to the Oracle
configuration and stop/start it whenever they wanted. The group that
ran the hardware was in another building, and writing outside the Oracle
directories or beyond their quotas required BOFH intervention.
Firebird is NOT a desktop application, so we must make sure we don't
fall in to the trap of requiring super-user rights to fully administer
it.
This is my last post on the subject, everyone is probably getting tired
of this thread.
Rick DeBay
-----Original Message-----
From: Firebird-Architect@yahoogroups.com
[mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Jason Dodson
Sent: Tuesday, March 28, 2006 10:48 AM
To: Firebird-Architect@yahoogroups.com
Subject: Re: [Firebird-Architect] Firebird init script
Ok, Firebird is NOT a desktop application. People shouldn't be
"screwing" with it, like they would their locally installed version of
Microsoft Office or Yahoo Instant Massager. At WORST, you should have
ONE server administrator, and possibly ONE firebird admin. In a lot of
cases, these just may be the same person. In either case, said admins
will have proper rights to su root... or at least have explicit rights
otherwise to do their job.
If you argue this is for "testing purposes", grab an piece of VM
software like Bochs, install Loonix, and test on your own virtual
machine, where YOU ARE THE ADMIN.
Relaxing security, EVEN FOR THE SAKE OF CONVENIENCE, is an absurd
notion, especially on something like database server software.
Jason
Rick Debay wrote:
The information transmitted herewith is sensitive information intended
only for use to the individual or entity to which it is addressed. If
the reader of this message is not the intended recipient, you are hereby
notified that any review, retransmission, dissemination, distribution,
copying or other use of, or taking of any action in reliance upon, this
information is strictly prohibited. If you have received this
communication in error, please contact the sender and delete the
material from your computer.
Yahoo! Groups Links
NO ONE should have to su to root, after installation is complete. Ever.
The database admin shouldn't be able to su to root. They should have
enough permissions to be dangerous to the database application. They
should not have any permissions that would permit them to be even
slightly dangerous to anything else on the system.
I was at an insurance company that had a whole floor just for Oracle
admins and the like. They could do whatever they wanted to the Oracle
configuration and stop/start it whenever they wanted. The group that
ran the hardware was in another building, and writing outside the Oracle
directories or beyond their quotas required BOFH intervention.
Firebird is NOT a desktop application, so we must make sure we don't
fall in to the trap of requiring super-user rights to fully administer
it.
This is my last post on the subject, everyone is probably getting tired
of this thread.
Rick DeBay
-----Original Message-----
From: Firebird-Architect@yahoogroups.com
[mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Jason Dodson
Sent: Tuesday, March 28, 2006 10:48 AM
To: Firebird-Architect@yahoogroups.com
Subject: Re: [Firebird-Architect] Firebird init script
Ok, Firebird is NOT a desktop application. People shouldn't be
"screwing" with it, like they would their locally installed version of
Microsoft Office or Yahoo Instant Massager. At WORST, you should have
ONE server administrator, and possibly ONE firebird admin. In a lot of
cases, these just may be the same person. In either case, said admins
will have proper rights to su root... or at least have explicit rights
otherwise to do their job.
If you argue this is for "testing purposes", grab an piece of VM
software like Bochs, install Loonix, and test on your own virtual
machine, where YOU ARE THE ADMIN.
Relaxing security, EVEN FOR THE SAKE OF CONVENIENCE, is an absurd
notion, especially on something like database server software.
Jason
Rick Debay wrote:
>> Why? Usre 'firebird' is a pseudo-user, in which context fbserverruns.
>> Suppose someone (bad guy) found a way to run his code in context ofto.
>> firebird server (due to some BOF, bad firebird.conf - or something
>> else). If some programs, scripts belong to user 'firebird', he can
>> modify it. With current root ownership - he can't. Why do you want to
>> make production system less protected?
>
> If the server process is compromised, I think the ability to modify
> server scripts is not what anyone has to worry about. It's a fallacy
> that making everything root access only is secure. And I'm not saying
> the script has to be writable by the firebird group, but it needs to
> be executable by them.
>
>> Please agree, that access to the server and ability to start-stop it
> are
>> a bit different things. For today, two users can stop server - root
> and
>> firebird. And for me, this is absolutely correct.
>
> The problem is that by making root the only account that can maintain
> the system, everyone is required to have root access and that security
> hole is by far the worst.
> This problem is greatly reduced by blocking remote root access,
> requiring wheel membership to su to root, and seperating root
> permissions out to those who need it in the sudoers file. However,
> sudoer files can become very complex very quickly, and it's easy to
> accidentally lock someone out or grant unwanted permissions. I'd be
> prone to give Joe Database Operator and Jane Database Operator
> permissions (by group membership) to run all scripts and programs
> belonging to the firebird group. That way they can backup, sweep,
> bounce the server, etc. But root (or a System Operator alias in
> sudoers) would be required to upgrade the server code or change the
> server's runlevel.
>
> Perhaps part of the review would be to create a sudoer alias, and
> permissions for the various actions, and placed in a sample file.
> Then it could be appended to the sudoer file if the installer wanted
>server.
> Rick DeBay
>
> -----Original Message-----
> From: Firebird-Architect@yahoogroups.com
> [mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Alex Peshkov
> Sent: Tuesday, March 28, 2006 3:57 AM
> To: Firebird-Architect@yahoogroups.com
> Subject: Re: [Firebird-Architect] Firebird init script
>
> Rick Debay wrote:
>> You are correct, I just checked our rpm install of the beta and while
>> the comment is still there, the code is not. I will have to check
>> the
>
>> tarball install, I could swear it contained the old script. Or
>> perhaps we installed the wrong tarball on the test system.
>>
>
> post-install script in rpm and tar is exactly the same - it's simply
> the same file. But as far as I remember you were initially talking
> about 1.5? In it there IS the sysdba password, and for security
> reasons file must be 0600.
>
>>> For production system suggested feature is a bad thing.
>> I don't understand. Anyone who can run kill as root can of course
> stop
>> the server. But the comment in the script suggested that only root
>> should be able to stop the server.
>
> I plan to review whole linux setup soon, including comments fixing.
>
>> I wanted to make sure that any
>> shutdown scripts, programs, etc belong to the firebird group, and not
>> root.
>>
>
> Why? Usre 'firebird' is a pseudo-user, in which context fbserver runs.
> Suppose someone (bad guy) found a way to run his code in context of
> firebird server (due to some BOF, bad firebird.conf - or something
> else). If some programs, scripts belong to user 'firebird', he can
> modify it. With current root ownership - he can't. Why do you want to
> make production system less protected?
>
>> On our test system they're all owned by root (We log on as root to
>> the test systems. In production that's not done, of course).
>
> Normally all services on production system are controlled by root. Did
> you try, for example, to restart named beeing a member of named group?
>
> Group firebird was primarily designed for embedded access to the
>--
> Please agree, that access to the server and ability to start-stop it
> are
>
> a bit different things. For today, two users can stop server - root
> and firebird. And for me, this is absolutely correct.
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
The information transmitted herewith is sensitive information intended
only for use to the individual or entity to which it is addressed. If
the reader of this message is not the intended recipient, you are hereby
notified that any review, retransmission, dissemination, distribution,
copying or other use of, or taking of any action in reliance upon, this
information is strictly prohibited. If you have received this
communication in error, please contact the sender and delete the
material from your computer.
Yahoo! Groups Links