Re: Fwd: Adding poptSecuritySaneFile to popt-1.15?
On Fri, Dec 19, 2008, Ralf S. Engelschall wrote:
> On Fri, Dec 19, 2008, Jeff Johnson wrote:
>
> > (resent, dunno where the 1st message went)
>
> I don't know, never seen on the list...
>
> > I kind of like the idea of using a '@' before a file path as an
> > "attention" marker to increase the file validation checks, and so I'm
> > likely to refactor the functionality out of rpm and into popt-1.15 as
> > part of simplifying rpm configuration/initialization.
> >
> > At the same time, I will probably add a new poptReadConfigFiles()
> > method whose argument will be a colon separated list of configuration
> > file paths to read.
> >
> > Any other opinions?
>
> As long as the particular security check (here rpmSecuritySaneFile
> for RPM_VENDOR_OPENPKG) embedded into POPT can be optionally still
> overridden from within RPM (in case one needs some additional checks or
> a different error message or whatever) I'm happy. Perhaps an optional
> callback does the trick.
BTW, under RPM_VENDOR_OPENPKG the "@" attention marker is not just used
for POPT files. It is also used for RPM macro files and Lua script
files! So, please be careful that instead of a "factoring out" not a
"partial removal" happens to the functionality.
For completeness reasons, here is how OpenPKG 4 configures RPM 5:
| [...]
| # determine POPT option, RPM macros and Lua script file paths
| RPMPOPT="%{l_prefix}/lib/openpkg/rpmpopt"
| RPMPOPT="$RPMPOPT:%{l_prefix}/etc/openpkg/rpmpopt"
| RPMPOPT="$RPMPOPT:%{l_prefix}/etc/openpkg/rpmpopt.d/*"
| RPMPOPT="$RPMPOPT:~/.openpkg/rpmpopt"
| RPMPOPT="$RPMPOPT:@../../.openpkg/rpmpopt"
| RPMPOPT="$RPMPOPT:@../.openpkg/rpmpopt"
| RPMPOPT="$RPMPOPT:@./.openpkg/rpmpopt"
| RPMMACROS="%{l_prefix}/lib/openpkg/rpmmacros"
| RPMMACROS="$RPMMACROS:%{l_prefix}/etc/openpkg/rpmmacros"
| RPMMACROS="$RPMMACROS:%{l_prefix}/etc/openpkg/rpmmacros.d/*"
| RPMMACROS="$RPMMACROS:~/.openpkg/rpmmacros"
| RPMMACROS="$RPMMACROS:@../../.openpkg/rpmmacros"
| RPMMACROS="$RPMMACROS:@../.openpkg/rpmmacros"
| RPMMACROS="$RPMMACROS:@./.openpkg/rpmmacros"
| RPMLUA="%{l_prefix}/lib/openpkg/rpmlua"
| RPMLUA="$RPMLUA:%{l_prefix}/etc/openpkg/rpmlua"
| RPMLUA="$RPMLUA:%{l_prefix}/etc/openpkg/rpmlua.d/*"
| RPMLUA="$RPMLUA:~/.openpkg/rpmlua"
| RPMLUA="$RPMLUA:@../../.openpkg/rpmlua"
| RPMLUA="$RPMLUA:@../.openpkg/rpmlua"
| RPMLUA="$RPMLUA:@./.openpkg/rpmlua"
|
| # configure program
| ./configure \
| --cache-file=./config.cache \
| --prefix=%{l_prefix} \
| --mandir="%{l_prefix}/man" \
| --includedir="%{l_prefix}/include/openpkg" \
| --with-name="OpenPKG RPM" \
| --with-path-cfg="%{l_prefix}/etc/openpkg" \
| --with-path-rpmpopt="$RPMPOPT" \
| --with-path-macros="$RPMMACROS" \
| --with-path-rpmlua="$RPMLUA" \
| [...]
As you can see, the attention markers are especially used on all paths
relative to the current working directory. This allows OpenPKG to use a
very flexible file-system layout with RPM (based on some additional RPM
macro hacking) while at the same time not open a security hole.
Yours,
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
__
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
Re: Fwd: Adding poptSecuritySaneFile to popt-1.15?
On Fri, Dec 19, 2008, Jeff Johnson wrote: > (resent, dunno where the 1st message went) I don't know, never seen on the list... > I kind of like the idea of using a '@' before a file path as an > "attention" marker to increase the file validation checks, and so I'm > likely to refactor the functionality out of rpm and into popt-1.15 as > part of simplifying rpm configuration/initialization. > > At the same time, I will probably add a new poptReadConfigFiles() > method whose argument will be a colon separated list of configuration > file paths to read. > > Any other opinions? As long as the particular security check (here rpmSecuritySaneFile for RPM_VENDOR_OPENPKG) embedded into POPT can be optionally still overridden from within RPM (in case one needs some additional checks or a different error message or whatever) I'm happy. Perhaps an optional callback does the trick. Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
Fwd: Adding poptSecuritySaneFile to popt-1.15?
(resent, dunno where the 1st message went)
I kind of like the idea of using a '@' before
a file path as an "attention" marker to increase
the file validation checks, and so I'm likely to
refactor the functionality out of rpm and into
popt-1.15 as part of simplifying rpm configuration/initialization.
At the same time, I will probably add a new
poptReadConfigFiles() method whose argument
will be a colon separated list of configuration
file paths to read.
Any other opinions?
73 de Jeff
Begin forwarded message:
From: Jeff Johnson
Date: December 18, 2008 3:15:33 PM EST
To: popt-devel@rpm5.org
Subject: Adding poptSecuritySaneFile to popt-1.15?
I'm currently catching up with popt changes, including adding a
--[no]option toggle flag and a precedence group to options, and
perhaps attaching a table to carry named bits in a single option enum.
I see this code in rpm using popt: basically paths can be prefixed
with
an '@' attention marker, which will do stricter sanity checks
on files as in:
int rpmSecuritySaneFile(const char *filename)
{
struct stat sb;
uid_t uid;
if (stat(filename, &sb) == -1)
return 1;
uid = getuid();
if (sb.st_uid != uid)
return 0;
if (!S_ISREG(sb.st_mode))
return 0;
if (sb.st_mode & (S_IWGRP|S_IWOTH))
return 0;
return 1;
}
...
/* work-off each resulting file from the path element */
for (i = 0; i < ac; i++) {
const char *fn = av[i];
#if defined(RPM_VENDOR_OPENPKG) /* security-sanity-check-rpmpopt-and-
rpmmacros */
if (fn[0] == '@' /* attention */) {
fn++;
if (!rpmSecuritySaneFile(fn)) {
rpmlog(RPMLOG_WARNING, "existing POPT
configuration file \"%s\" considered INSECURE -- not loaded\n", fn);
continue;
}
}
#endif
(void)poptReadConfigFile(optCon, fn);
av[i] = _free(av[i]);
}
Should I drop the '@' prefix on file path "attention!" convention
into popt instead?
Its easy enough to do, although perhaps access(2) rather
than stat(2) might be slightly better owner checking.
73 de Jeff
smime.p7s
Description: S/MIME cryptographic signature
