Re: file effective and process inheritable mask
Y2K (y2k@y2ker.com)
Sat, 24 Apr 1999 10:20:57 -0700 (PDT)
On Sat, 24 Apr 1999, David L. Parsley (lkml account) wrote:
> > 2. If an attacker has gained full control via a buffer overflow,
> > the attacker can load arbitrary code without an exec().
> Yes, in which case they are constrained to pP. If pI is full, though,
> they are much better exec'ing something that will inherit a lot of power,
> like 'cp /etc/shadow /home/ftp/pub/ua412'. Note I'm not referring to the
> uid fs rights, but the capability to read any file which a 'root shell'
> would have in pI, and cp might have in fI (so admin can do admin things).
> If pI is constrained with a mask, this sort of thing can be mostly
> prevented.
Just reread that and understand why I think allowing pI and fI collude and
raise caps the parent never had is broken. You either make 'cp' unusable
for admining perpurses or you make it a potential security hole under your
"pure" cap scheme.
> > In other words, an attacker that can do an exec() has other ways to
> > get the job done. You might as well not worry about the exec.
>
> But I am, because with pI mostly full, that's where the attacker can gain
> priviledge! I'm trying to say that, if pI is _full_ and a script kiddie
> downloads a standard /bin/sh exec'ing buffer overflow exploit, then the
> shell they get will be the current equivalent of a root shell! I'm trying
> to avoid that, as well as provide the sysadmin a general means of
> constricting the passage of pI.
Then weaken pI, don't let it raise caps. I'm providing to
constrict the passage of pI via pP and fI. How do you like that, and bonus
points it makes things better fit with compatibility situations.
> > Huh? Unless you enable some sort of backward compatibility hack, there
> > is no way that 'more' will get CAP_SETFCAP without it being listed as
> > something that 'more' should have. Remember that pP does not survive
> > across an exec() in any way. Only pI lives on.
> Read again. pI is what I was referring to.
It should be restrained by fI at the very least. And again I'd argue pP.
> > I don't want to find out if this is a corner case, do you? We'd know
> > it is not a corner case if we see a security alert go out.
We had best test things out very carefully before we release anything for
reals. This is very definately a 2.3 issue. As we test it out on
non-production machines we can better see the types of problems we will
run across better. I think it might be a little early to speculate how
much it is needed and what extend the user-space will need to be updated.
--
Warning when I mention capabilites I mean "soiled" capabilities not "pure".
Any caps I mention are *derived* from a withdrawn draft posix document.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/