Re: Making SELinux standard for etch
On Wed, 11 Oct 2006 12:20:05 +0100, Yan <email@example.com> said:
> Ian Jackson wrote:
>> Furthermore, the SELinux patches I have seen in various
>> applications have given me an extremely poor impression of the code
>> quality. This will probably extend to other areas of SELinux.
>> I say, ditch SELinux.
>>  Here's just one example, from src/archives.c in dpkg:
>> #ifdef WITH_SELINUX
>> * if selinux is enabled, restore the default security context
>> */ if (selinux_enabled > 0) if(setfscreatecon(NULL) < 0)
>> perror("Error restoring default security context:");
>> #endif /* WITH_SELINUX */
>> Error checking ? We don't need no steenking error checking, this
>> is SECURITY software ! Quick, dump your brains and deploy it !
Assuming for an instant Ian may know what he is talking about,
could an example be given about what the so called missing error
checks are, by him or anyone else who knows what he is referring to?
How would people code this differently?
So far, I think the criticism reflect more of a lack of
understanding of SELinux trhan anything else, but I would be happy if
someone could show me the error of my ways.
> Without checking these functions for what they return its hard to
> say how bad this is, but it does look like its checking the return
> values for an error (albeit not doing anything other than printing a
> message). Without more context its impossible to say whether not
> resetting the default security context is bad or not.
Since the default permissions are to deny all access, all it
means is that any special permissions accorded by policy to the
package being installed would not be set by dpkg. So the package may
not work in enforcing mode until the file system is relabelled; but
that is failing safe; if there are things wrong in the system that
dpkg can't set the initial file contexts for the packages being
installed, it is reasonable to assume that you might have to relable
your file system to recover from the error condition.
Fools ignore complexity. Pragmatists suffer it. Some can avoid it.
Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN
Notices, Sept. 1982
Manoj Srivastava <firstname.lastname@example.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C