IDS Forum

Re: informix not creating files with req permi....

Posted By: Jonathan Leffler
Date: Sunday, 17 August 2008, at 6:47 p.m.

In Response To: Re: informix not creating files with req permi.... (Fernando Nunes)

On Tue, Aug 12, 2008 at 4:19 PM, Fernando Nunes <domusonline@gmail.com> wrote:
> Not sure if I agree (and I always think a lot before disagreeing with
> Jonathan ;) ).

I'm not sure I understand what you're disagreeing with. I'm glad you
think before disagreeing with me, but I'm even gladder that when you
do disagree, you say so. I try to get my statements correct; I doubt
if I always succeed. If you think I'm wrong and can give a cogent
explanation of why (preferably with an example), then always, but
always, say I'm wrong. Accurate information is much more important
than me being right.

> Who owns these files? User and group?

Perfectly good questions - in fact, important questions. And one
reason it has taken me so long to respond is that my machine is
playing silly tricks on me (at least, that's what it feels like),
specifically w.r.t enabling auditing.

> Remember that Informix is fully capable of doing role separation and if you
> think seriously about doing audit logs you should have a special group for
> it.

Correct.

> And user informix should not belong to this group

Ah...this could be a point of disagreement.

The aaodir controls the AAO group - that is, the group that owns
$INFORMIXDIR/aaodir is the group that is the AAO group. The aaodir is
still owned by user informix, so user informix can tinker with the
files under it - specifically, adtcfg -- and can bring IDS up and
down, and hence can reconfigure the audit. In other words, it seems
to me that it doesn't much matter whether user informix is a member of
the AAO group; user informix can still rig things.

That's primarily empirical observation - that is what actually
happens. It is not wholly clear that the behaviour is the best
possible. On the other hand, it is not clearly defined what user can
(should) own $INFORMIXDIR/aaodir if it is not user informix, nor
whether IDS will work properly if user informix does not have access
to aaodir.

> Last time I checked, the files were owned by the group defined as AAO
> (Auditing analysis officer). And the members of these groups should be able
> to delete the files.

And the default AAO group is, of course, group informix.

> We can question why the files are owned by user Informix, but with the right
> directory permissions and assuming you don't put user Informix in the AAO
> group user informix should not be able to access/alter/erase them.

This depends on the directory permissions. If user informix owns the
directory, you can't stop user informix from deleting the files -
possibly after modifying the directory permissions to allow deletions.

> So, 660 informix:aao should be ok.
> The audit logs directory should not be owned by user Informix, should be
> owned by group aao and cshould have permissions like 770.
> The owner of this directory could be root or a member of aao group.

I'd need to check on this - once I find out why my server is playing
silly games with me. I'm not sure whether the log directory (ADTPATH
in the adtcfg file) can be owned other than by user informix; I'm also
not sure whether $INFORMIXDIR/aaodir can be owned other than by user
informix.

> All this only makes sense with role separation, and I believe auditing only
> makes sense with role separation.

In general, yes: auditing is most sensible with role separation.
However, auditing without role separation does also work, but isn't
necessarily as secure as auditing with role separation. OTOH, if
there are only two people administering the machines, maybe role
separation isn't possible meaningfully. Role separation assumes the
staff is big enough to have people with separate roles. IDS systems
not infrequently have one person performing most if not all of the
roles, which then makes role separation less beneficial (though
nonetheless desirable).

> I have some doubts about the directory owner (if it works with another owner
> than Informix), but it should work in recent versions. If it fails to create
> the files you may have to setup an env variable called NONROOT_OFF.

I would be extremely cautious about running CPU VPs with root
privileges if you have any UDTs defined (that use shared libraries).

> I have expressed most of my ideas about this here:
>
> http://informix-technology.blogspot.com/2008/02/compliance-role-separation-and-audit.html
> and
>
> http://informix-technology.blogspot.com/2008/07/compliance-role-separation-and-audit.html

Thanks for the URLs.

> On Tue, Aug 12, 2008 at 6:23 PM, Jonathan Leffler
> <jleffler.iiug@gmail.com>wrote:
>
>> On Tue, Aug 12, 2008 at 7:13 AM, VINU KURIAN <vinu.kurian26@gmail.com>
>> wrote:
>> > We have an executable running with group as database. When an expected event
>> > occurs, onaudit is called to enable auditing and set the level of auditing to
>> > be performed. Through onaudit, we are generating informix audit logs under a
>> > folder called informixauditlogs. The folder has been created with 775
>> > permission. And our assumption is that onaudit would create files having the
>> > same permission as parent folder i.e., informixauditlogs. But to our surprise,
>> > informix is creating those log files with a permission of 660.
>> >
>> > Can any of you please let me know why this happens. Is there a way to come out
>> > of it?
>>
>> Audit logs are not executable, so they should never have the execute bits
>> set.
>>
>> Audit logs are security sensitive. They should not be publicly
>> readable. Otherwise, the general public could find out all sorts of
>> interesting things that they should not be able to find out.

I don't see what you could be disagreeing with in these two paragraphs.

>> I'd have considerable sympathy with a complaint to the effect that the
>> permissions should be just 400 -- 660 is way too permissive.

I'm not sure if you are disagreeing with this, or what you'd be
proposing as an alternative. Also, please note, I said nothing about
which user or group owns the files or directories -- and that wasn't
accidental. I just pointed out that the public should have no access
to the audit log files (and that no-one needs the audit files to be
executable).

So, I don't see a point of disagreement. What you've done is take my
careful statements (which were, perhaps, a bit too economical with the
truth), and expanded them and expounded upon them, bringing out valid
points which I didn't try to make.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/
"Blessed are we who can laugh at ourselves, for we shall never cease
to be amused."
NB: Please do not use this email for correspondence.
I don't necessarily read it every week, even.

Messages In This Thread

• informix not creating files with req permissions
  VINU KURIAN -- Tuesday, 12 August 2008, at 10:13 a.m.
  • Re: informix not creating files with req permissio
    Art Kagel -- Tuesday, 12 August 2008, at 11:21 a.m.
  • Re: informix not creating files with req permissio
    Jonathan Leffler -- Tuesday, 12 August 2008, at 1:23 p.m.
    • Re: informix not creating files with req permi....
      Fernando Nunes -- Tuesday, 12 August 2008, at 7:19 p.m.
      • Re: informix not creating files with req permi....
        VINU KURIAN -- Thursday, 14 August 2008, at 3:30 a.m.
      • Re: informix not creating files with req permi....
        Jonathan Leffler -- Sunday, 17 August 2008, at 6:47 p.m.

IDS Forum is maintained by Administrator with WebBBS 5.12.