[SECURITY] FDs 0, 1, 2 for SUID/SGID programs
Florian Weimer
Linux, too (if a SUID/SGID program is invoked with FD 2 closed, error
messages might be written to a file opened by the program ).
--
Florian Weimer Wei...@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Chris Wright
> http://www.pine.nl/advisories/pine-cert-20020401.html probably affects
> Linux, too (if a SUID/SGID program is invoked with FD 2 closed, error
> messages might be written to a file opened by the program ).
AFAIK, the standards clearly specify behaviour wrt. open file descriptors
and clone-on-exec file descriptors across execve(). However, there
is nothing specified when it comes to closed file descpriptors across
execve(), notably FD's 0, 1 and 2 are certainly not required to be open
across an execve() of a SUID/SGID applictaion. One could argue that
SUID/SGID apps that trust the file descriptors they inherit across exec()
are buggy.
Having said that, there are a number of implementations of this type
of protection for the linux kernel stemming from the Openwall project.
If you are interested, see:
http://www.openwall.com (CONFIG_SECURE_FD_0_1_2)
http://lsm.immunix.org (CONFIG_OWLSM_FD)
http://grsecurity.net (CONFIG_GRKERNSEC_FD)
cheers,
-chris
Alan Cox
> Linux, too (if a SUID/SGID program is invoked with FD 2 closed, error
> messages might be written to a file opened by the program ).
Unix requires this behaviour. Its an old and common bug to get it
wrong. glibc intentionally provides some cover
Alex Riesen
> * Florian Weimer (Wei...@CERT.Uni-Stuttgart.DE) wrote:
> > Linux, too (if a SUID/SGID program is invoked with FD 2 closed, error
> > messages might be written to a file opened by the program ).
>
> and clone-on-exec file descriptors across execve(). However, there
that is close-on-exec. Different semantics.
F_GETFD Read the close-on-exec flag. If the FD_CLOEXEC
bit is 0, the file will remain open across exec,
otherwise it will be closed.
> is nothing specified when it comes to closed file descpriptors across
> execve(), notably FD's 0, 1 and 2 are certainly not required to be open
> across an execve() of a SUID/SGID applictaion. One could argue that
> SUID/SGID apps that trust the file descriptors they inherit across exec()
> are buggy.
>
> Having said that, there are a number of implementations of this type
> of protection for the linux kernel stemming from the Openwall project.
> If you are interested, see:
>
> http://www.openwall.com (CONFIG_SECURE_FD_0_1_2)
> http://lsm.immunix.org (CONFIG_OWLSM_FD)
> http://grsecurity.net (CONFIG_GRKERNSEC_FD)
Remco Post
having thought about this problem for a day or so, I don't think this is
a kernel issue. One cannot simply solve typical userland problems in the
OS. The only proper way to solve this is for apps to check that fd 0 1 2
are open before they open any file or try to write to any of those fd's.
Maybe the code that is executed before main is called can perform these
checks, but certainly not a kernel...
Guess that from now on app developers will have to do even more checking
on their environment before they use it...
On Tue, 23 Apr 2002 14:02:39 +0200
"Alex Riesen" <Alexande...@synopsys.com> wrote:
> > is nothing specified when it comes to closed file descpriptors
> > across execve(), notably FD's 0, 1 and 2 are certainly not required
> > to be open across an execve() of a SUID/SGID applictaion. One could
> > argue that SUID/SGID apps that trust the file descriptors they
> > inherit across exec() are buggy.
> >
> > Having said that, there are a number of implementations of this type
> > of protection for the linux kernel stemming from the Openwall
> > project. If you are interested, see:
> >
> > http://www.openwall.com (CONFIG_SECURE_FD_0_1_2)
> > http://lsm.immunix.org (CONFIG_OWLSM_FD)
> > http://grsecurity.net (CONFIG_GRKERNSEC_FD)
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majo...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Met vriendelijke groeten,
Remco Post
SARA - Stichting Academisch Rekencentrum Amsterdam http://www.sara.nl
High Performance Computing Tel. +31 20 592 8008 Fax. +31 20 668 3167
"I really didn't foresee the Internet. But then, neither did the
computer industry. Not that that tells us very much of course - the
computer industry didn't even foresee that the century was going to
end." -- Douglas Adams
Chris Wright
> On Mon, Apr 22, 2002 at 12:18:19PM -0700, Chris Wright wrote:
> > and clone-on-exec file descriptors across execve(). However, there
>
> that is close-on-exec. Different semantics.
yes, typo. thanks.
-chris