Re: Making SELinux standard for etch
Mr Yan writes ("Re: Making SELinux standard for etch"):
> Ian Jackson wrote:
> > if (selinux_enabled > 0)
> > if(setfscreatecon(NULL) < 0)
> > perror("Error restoring default security context:");
> >
> > Error checking ? We don't need no steenking error checking, this is
> > SECURITY software ! Quick, dump your brains and deploy it !
>
> 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.
Having the program carry on after it has failed to restore the default
security context is definitely bad.
Manoj Srivastava writes ("Re: Making SELinux standard for etch"):
> 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?
if (selinux_enabled > 0)
if(setfscreatecon(NULL) < 0)
ohshite(_("Error restoring default security context"));
(I haven't read the manpage for setfscreatecon to check whether the
`< 0' is right; I'll charitably assume it.)
But the answer here isn't to go through all of the selinux patches to
all of our programs and try to fix the bugs in them. If the code is
buggy the concepts are likely to be buggy too.
Indeed, if you're willing to take my word as a computer security
expert[1] for it, I can say with confidence that selinux is not the
right approach to fixing the security problems with our systems.
It probably does more harm than good.
([1] I have a PhD in computer security from Cambridge University,
8 years' practical experience in the computer security industry, and a
similar period of experience as an author of Free security software.)
> 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.
The selinux patch to dpkg contains several calls to setfscreatecon,
and in each case, if setfscreatecon fails, the code uses perror to
print a message to stderr and then carries on anyway.
> 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;
Not at all! The package will be broken and the system unuseable.
Furthermore, the error abort is missing after _both_ the calls to set
file-specific contexts, and the calls to restore the default. If
these calls fail, files in general might be created by dpkg or even by
its callees (postinst scripts, etc.) with inappropriate security
labels.
> 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.
No, it is reasonable to assume that dpkg would fail during the
installation/upgrade so that you can correct the problem.
dpkg (unlike rpm!) doesn't carry on blithely when your disk is full or
when your filesystem is readonly; nor should it carry on blithely if
it can't set the security context in the way intended.
Unless, of course, this whose security context palaver isn't really
important. In which case why are we contorting our code and
introducing dodgy and unstable libraries right at the bottom of our
software stack ?
Ian.
Reply to: