Re: Question about permissions used on onconfig and sqlhosts files

Jonathan Leffler wrote: > A question arose in relation to a bug fix: > > Do any of the production systems you know of consciously use world > write permission on either the $ONCONFIG file or the > $INFORMIXSQLHOSTS file? > > What about non-production systems? > > If the answer is yes, is there a good justification? > If the answer is "not consciously, but yes", is there a reason not > to fix it? I've received a number of private email replies (thanks to all who sent them to me), all commenting that public write permissions on critical files like the ONCONFIG file and the sqlhosts file makes no sense from any security viewpoint. Some pointing out that the permissions in the files lists on the dummy versions of those files are 664 (no public write permission), so why would anyone do anything different? Would that the issue could be laid to rest that easily! There is at least one large commercial customer that uses 666 permissions on both files in all their installations - and they have a lot of them. About the only thing to be said in their defence is that their systems are almost embedded - end users are not supposed to login to the machines. I'm far from convinced that excuses them, or the staff who've ever looked at the customer's systems, but that's a separate discussion. Be aware that version 9.50 of IDS will most likely enforce the 'no public write' rule on these files by refusing to start the server if the permissions are wrong (and other utilities will also validate the permissions and refuse to run if the permissions on critical files and directories are wrong). The same will be true of most (all, if I have my way) other configuration files that affect a particular utility. You can save yourself, your company, and your customers grief in the future by ensuring that the configuration files are not publicly writeable now. Interim versions are likely to generate warnings for the files - but won't refuse to operate. OTOH, some directories with incorrect permissions (eg $INFORMIXDIR) will generate errors. Assume public write permission under $INFORMIXDIR is not allowed and you won't go wrong on that score. -- Jonathan Leffler (jleffler@earthlink.net, jleffler@us.ibm.com) #include <disclaimer.h> Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

Jonathan Leffler wrote: > > Do any of the production systems you know of consciously use world > write permission on either the $ONCONFIG file or the > $INFORMIXSQLHOSTS file? Absa-freaken-lootely not. Nor mess with the permissions of anything under $INFORMIXDIR. Can't see any point what-so-ever. > There is at least one large commercial customer that uses 666 > permissions on both files in all their installations - and they have a > lot of them. About the only thing to be said in their defence is that > their systems are almost embedded - end users are not supposed to > login to the machines. I'm far from convinced that excuses them, or > the staff who've ever looked at the customer's systems, but that's a > separate discussion. Well, they'll have to investigate suid scripts or execute under an appropriate user then... > Assume public write permission under $INFORMIXDIR is not > allowed and you won't go wrong on that score. WOO HOOO! I've long whinged bitterly at people who install Informix into the same directory that is the informix account's home. Unfortunately nothing hase been done traditionally to prevent this. My complaint about people who do that is, they do work using the informix account and leave all sorts of crap lying around. Is there any way to enforce that $INFORMIXDIR != ~informix ??? or make $INFORMIXDIR completely unwritable?

Andrew Hamm wrote: > Jonathan Leffler wrote: > >>Do any of the production systems you know of consciously use world >>write permission on either the $ONCONFIG file or the >>$INFORMIXSQLHOSTS file? > > Absa-freaken-lootely not. Nor mess with the permissions of anything under > $INFORMIXDIR. Can't see any point what-so-ever. Well, don't forget that the ibmifmx_security.sh script is there precisely to mess with the permissions of some things under $INFORMIXDIR. If you are not using a program that has to be SUID root when it is in use, one simple way of improving the security of the system is to disable the SUID privileges - which is one of the jobs that script does. If you're on 7.31 and not using ON-Archive, for example (that should be most of those using 7.31), you would do well to eliminate the SUID and SGID permissions from the ON-Archive executables (note to self - must check whether the script deals with ON-Archive). For instance, unless you have SE also installed in the same $INFORMIXDIR (which is itself a bad idea these days), you can disable the mkdbsdir program - 000 permissions - without harming anything. Beware of permissions checking scripts which flag deviations between what is listed in the files lists from $INFORMIXDIR/etc and what is found on the system. >>There is at least one large commercial customer that uses 666 >>permissions on both files in all their installations - and they have a >>lot of them. About the only thing to be said in their defence is that >>their systems are almost embedded - end users are not supposed to >>login to the machines. I'm far from convinced that excuses them, or >>the staff who've ever looked at the customer's systems, but that's a >>separate discussion. > > Well, they'll have to investigate suid scripts or execute under an > appropriate user then... Admins are allowed in - general users are not. >>Assume public write permission under $INFORMIXDIR is not >>allowed and you won't go wrong on that score. > > WOO HOOO! I note in passing that essentially no directories anywhere on a Unix machine should have public write permission - other than the well known /tmp and /usr/tmp directories (or, if they're symlinks, the actual directories those symlinks point to). A few other specialized directories maybe - for controlled uploads perhaps - but very, very few. Similarly, very few files anywhere should have public write permission. Having public write permission on a file is equivalent to saying "the information in this file is never of any importance whatsoever - anybody can destroy (rewrite) it at any time and no damage is done to the system". That might be true if the file is generated from other better protected sources, but it is pretty unusual. > I've long whinged bitterly at people who install Informix into the same > directory that is the informix account's home. Unfortunately nothing hase > been done traditionally to prevent this. My complaint about people who do > that is, they do work using the informix account and leave all sorts of crap > lying around. Is there any way to enforce that $INFORMIXDIR != ~informix ??? > or make $INFORMIXDIR completely unwritable? No. Too many people do too many similar things to make such a move remotely sensible. There are plenty of defaults in things like onconfig.std that are not desirable - such as the online log file in $INFORMIXDIR. That only encourages the mess. We have no plans to prevent people from installing their own software under $INFORMIXDIR - that may be sensible even for some ISVs, as well as for systems deployed inside a company. We will probably insist that no directory created by the Informix install has public write permission, and that most of those directories are owned by user informix and belong to group informix. It's up to you what you do with your own directories, but as noted above, public write permission is seldom a good idea. Similarly, you can expect us to ensure that many files are not writable by others - things like message files should not be changed, in general. It is more debatable whether we will clamp down on public read access. Nominally, for some files (eg program exeutables such as oninit), not allowing public read access gives some extra security. In practice, though, the extra security is so minimal it is not worth the hassle it causes. Reference data points: /usr/bin/su on Solaris 8 and MacOS X 10.2.8 is installed with public read permission. All the intruder has to do is obtain the software from somewhere and copy it onto their own system and do the poking there instead of on the target system. We may juggle the permissions on some other files so that they do not need public read access. We may be able to modify some programs that currently use SUID or SGID privileges so that those elevated privileges are unnecessary. And we may end up recording the actual correct privileges for the current installation in files other than the files lists in $INFORMIXDIR/etc. Beware if you have your own permissions checkers - or mine from the IIUG Software Archive (though I note that my ixchkperm and ixsetperm scripts accept an arbitrary list of files lists on the command line, defaulting to the set of files lists in $INFORMIXDIR/etc if no command line arguments are given). Also note that the ibmifmx_security.sh script referred to previously does not amend the permissions recorded in any files list. -- Jonathan Leffler (jleffler@earthlink.net, jleffler@us.ibm.com) #include <disclaimer.h> Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/