Re: Re: perl-Razor-Agent logs to /razor-agent.log by default

[Kurt Seifried <kseifried () redhat com>]

On 12/10/14 03:09 PM, cve-assign () mitre org wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1058772
> > https://bugzilla.redhat.com/show_bug.cgi?id=514979
>
> > I'm inclined to not call this a DoS ... I can see situations where
> > this could be a problem.
>
> Maybe a CVE is needed for Red Hat's SELinux configuration - see below.
>
> As far as we can tell, this may be intentional behavior from the
> perspective of the upstream code. If the razorhome setting has a ""
> value, then the product doesn't use full directory paths and instead
> defaults to the current working directory (the / directory here):
>
>   sub read_conf {
>   ...
>   # add full path to all config values that need them
>   if ($self->{razorhome}) {
>   foreach (qw( logfile ...
>
>
> Here, $self->{razorhome} has a value of "" because /root/.razor
> doesn't exist (SELinux had previously prevented its creation):
>
>   sub find_home {
>   ...
>       my $dotrazor = '.razor';
>   ...
>       $rhome = File::Spec->catdir("$ENV{HOME}", "$dotrazor");
>   ...
>       if (-d $rhome) {
>   ...
>         $self->{razorhome} = $rhome;
>         return 1;
>     }
>   ...
>     $self->{razorhome} = "";
>
> Are you interested in having a CVE assignment because this is a
> vulnerability in the default SELinux policy in various RHEL and Fedora
> versions? This seems to be an unusual situation in which denying write
> access to /root/.razor is what causes the vulnerability to exist.

In that case I would argue SELinux is doing its job as expressed by
policy, and that the flaw still lies in Razor not having a sane fallback
(like syslog, I mean WTF?). I think dropping files into / definitely
violates the principle of least surprise. There's also other reasons the
logging can fail, not just SELinux (apparmour, permissions, etc.).

> In other words, what is Red Hat's position on customer expectations
> for packages that function in an different/vulnerable way in SELinux
> Enforcing mode? Is it something like:
>
>   - when Red Hat created the package, Red Hat was supposed to either
>     ensure that the default SELinux policy was compatible with the
>     filesystem access required by the package, or else develop a Red
>     Hat custom patch to use a different part of the filesystem (e.g.,
>     maybe something under /var instead of /root/.razor in this case)
>
> Or is it something like:
>
>   - every user is on their own to read setroubleshoot reports,
>     determine why SELinux Enforcing mode results in vulnerable
>     behavior for a package shipped by Red Hat, and then use semanage
>     commands to get the behavior that they want
>
> ? Also, if it's undesirable for a mail-handling daemon to write to the
> top-level / directory, shouldn't the default SELinux policy have
> prevented that? Is it possible to construct a policy to express a
> position such as "new top-level files aren't ever allowed; every new
> file must be at least one level below the / level"?

Ah so one note: we (as in RHT corporate) didn't create this package.
It's part of Fedora/EPEL (the community), it's not shipped as part of
RHEL or any of our products. I can assure had this been a corp package
we would have caught this flaw in regular testing (insert sad comment
about people setenforce'ing 0 killing a puppy/etc). Also it's been
static since 2010, everything past that is just mass rebuilds for F15+
and so on.

> > it doesn't appear that the attacker can trigger faster growth
>
> Of course, there can't be a CVE assignment unless an attacker can
> trigger faster growth. (Unexpected resource consumption caused solely
> by the administrator's decision to install perl-Razor-Agent doesn't
> qualify for a CVE; that doesn't cross privilege boundaries.)
>
> It looks like attackers were supposed to be able to trigger faster
> growth simply by sending more mail, e.g.,
>
>     my $defaults = {
>         debuglevel         => "3",
>
>    $self->log (3,"ignoring mail $obj->{id}, whitelisted by rule: $sh: $address");
>
>    $self->log (3,"mail $obj->{id} is ". ($obj->{spam} ? '' : 'not ') ."known spam.");
>
> Is this even possible, or does SELinux Enforcing mode disrupt normal
> operation enough that the code never reaches "$self->log (3" lines?

Dunno, I haven't investigated this, I'm trying to eat turkey
(thanksgiving =).

-- 
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993

Attachment: signature.asc
Description: OpenPGP digital signature