From: Pawel J. D. <ni...@ga...> - 2003-08-03 21:07:31
|
On Sun, Aug 03, 2003 at 01:23:41PM -0700, Dariusz Kulinski wrote: +> I saw that there was no difference in seteuid code, so concentrated +> on setegid, and noticed that there was call instead of a sucall. +> I attached a patch (I doubt it's needed, but it'll probably save you +> some time to search for that line :P) Yes, thanks. I've found it also while I was tracking bug with 'w'/'who' that you've reported. +> > Are you sure that you have loaded <cerb-directory>/test/optests/optest= s.cb +> > rules before you've run those tests? +> > File INSTALL was out of date. Look at docs/HOWTO.html. +>=20 +> Yes, I followed the old INSTALL (I actually readed it only once while +> I was installing cerb first time) +> But shouldn't test be more automatic? I mean they could load just +> compiled cerb mod, and rules for testing? No, because some rules could be loaded already. I want to be sure, that user know exactly what he is doing. +> > This is because one of test suite if checking illegal behaviour. +> > It is giving wrong addresses to cerb, it is trying to loaded rules +> > as an unprivileged user, etc. And informations of those illegal tries +> > are send to console. Is this is really annoying? Maybe it should goes +> > only to logs... +>=20 +> For me realy anoying is that some rules give too much informations. +> Especially openssh.cb, I moddified some rules to make my logs more +> cleaner. I think I'll add some sysctl: cerb.user.verbose and modify CB_LOG() macro to output logs only when it is set to 1. +> +>> - crontab - didn't work for users which aren't member of wheel group, +> > I'll look at this. +>=20 +> It's a matter to set euid to 0 while doing realpath. And also allow +> chdir. There was problem with chdir() and stat(), but adding wheel group instead of euid 0 is enough. There was problems with realpath() as well, but I've change it to 'cdir' + argument. +> I used: +> 3) allow cron to modiffy /var/cron/tabs/*. This is less secure, so I +> understand that this could be reason for rejecting the patch. Yes. Here we got one of the most importnat topics related with cerb or other syscall wrappers. Cerb exists, because I decide that this is stupid to give some applications euid 0 just because it want to open raw socket or open /etc/spwd.db for reading. But sometimes we need to give more privileges. For example, there is su.cb policy, but it doesn't protect su(1) application, because if process is permited to change its uid to 0 there is nothing that we can do. If some process want to open /etc/spwd.db for writing there is noting that we can do. su.cb policy exists only because of degrade-unknown-sugids.cb policy. In crontab.cb case we are able to limit crontab(1) operations to only "safe" operations. We could control everythings there. And now if you allow crontab(1) to write just to /var/cron/tabs/ we're loosing all security. If process is permited to write only to its own file in /var/cron/tabs/ it is secure. --=20 Pawel Jakub Dawidek pa...@da... UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net |