informix not creating files with req permissions

Hi, 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? Thanks in advance Regards, Vinu

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'd have considerable sympathy with a complaint to the effect that the permissions should be just 400 -- 660 is way too permissive. -- 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.

Not sure if I agree (and I always think a lot before disagreeing with Jonathan ;) ). Who owns these files? User and group? 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. And user informix should not belong to this group 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. 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. 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. All this only makes sense with role separation, and I believe auditing only makes sense with role separation. 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 have expressed most of my ideas about this here: http://informix-technology.blogspot.com/2008/02/compliance-role-separation-and-a udit.html and http://informix-technology.blogspot.com/2008/07/compliance-role-separation-and-a udit.html Regards. 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'd have considerable sympathy with a complaint to the effect that the > permissions should be just 400 -- 660 is way too permissive. > > -- > 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. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

Thanks Fernando, Art and Jonathan for your valuable inputs. Shall come back to you for more...:)

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-a udit.html > and > > http://informix-technology.blogspot.com/2008/07/compliance-role-separation-and-a udit.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.