Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.
On 07/29/2018 09:16 PM, Ulrich Mueller wrote: > > Staying with the man:man example, how would anybody become the "man" > user, in the first place? That user has /bin/false as a shell and no > valid password. One way would be to exploit a process that's running as the "man" user. Ostensibly such a thing is possible; otherwise we wouldn't be dropping privileges in the first place. The shell/password settings for that user are also in no way guaranteed. But on principle: who cares, non-root users shouldn't be able to gain root =) > Setgid executables shouldn't be group writable Why not? I'm happy to pull that part back out.
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
On Sun, Jul 29, 2018 at 12:40:18AM +0300, Mikle Kolyada wrote: > (e.g make major changes to the widely used eclasses without prior > discussion on the mailing list or What's the metric to say if a given eclass is widely used? -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.
> On Sun, 29 Jul 2018, Michael Orlitzky wrote: > After thinking about this for a while, I think we should ignore setgid > but not setuid executables. The problem with setuid and a non-root owner > is that the owner can always exploit the situation: > Suppose /bin/foo is owned by "foo" and setuid. If root (or any other > privileged user) is about to run /bin/foo, then the "foo" user can > simply strip away the setuid bit and fill /bin/foo with malicious code. Staying with the man:man example, how would anybody become the "man" user, in the first place? That user has /bin/false as a shell and no valid password. > The same situation with setgid is safe because (as far as I know) > members of the group can't strip off the setgid bit. Setgid executables shouldn't be group writable, so I believe that part of the test is fine as-is in v1 of your patch. Ulrich pgppMBCz_RDB1.pgp Description: PGP signature
[gentoo-portage-dev] [PATCH v2 0/2] Two insecure ownership and group-writability QA checks.
Changes in v2: * Also check executables in /opt/bin (mgorny). * Don't report group-writable executables that are setgid (ulm). * Add a comment on why we don't do the same for setuid. * Wrap long lines with backslashes. * Fix nesting of output loop; output should happen after all checks. Michael Orlitzky (2): bin/install-qa-check.d: add new 90bad-bin-owner QA check. bin/install-qa-check.d: add new 90bad-bin-group-write QA check. bin/install-qa-check.d/90bad-bin-group-write | 49 bin/install-qa-check.d/90bad-bin-owner | 47 ++ 2 files changed, 96 insertions(+) create mode 100644 bin/install-qa-check.d/90bad-bin-group-write create mode 100644 bin/install-qa-check.d/90bad-bin-owner -- 2.16.4
[gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.
System executables that are not owned by root pose a security
risk. The owner of the executable is free to modify it at any time;
so, for example, he can change a daemon's behavior to make it
malicious before the next time the service is started (usually by
root).
On a "normal" system, there is no good reason why the superuser should
not own every system executable. This commit adds a new install-time
check that reports any such binaries with a QA warning. To avoid false
positives, non-"normal" systems (like prefix) are skipped at the moment.
Bug: https://bugs.gentoo.org/629398
---
bin/install-qa-check.d/90bad-bin-owner | 47 ++
1 file changed, 47 insertions(+)
create mode 100644 bin/install-qa-check.d/90bad-bin-owner
diff --git a/bin/install-qa-check.d/90bad-bin-owner
b/bin/install-qa-check.d/90bad-bin-owner
new file mode 100644
index 0..748e1dc99
--- /dev/null
+++ b/bin/install-qa-check.d/90bad-bin-owner
@@ -0,0 +1,47 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+bad_bin_owner_check() {
+ # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
+ # /usr/sbin, or /opt/bin) that are owned by a nonzero UID.
+
+ # This check doesn't work on non-root prefix installations at
+ # the moment, because every executable therein is owned by a
+ # nonzero UID.
+ [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
+
+ local d f found=()
+
+ for d in "${ED%/}/opt/bin" "${ED%/}/bin" "${ED%/}/usr/bin" \
+ "${ED%/}/sbin"
"${ED%/}/usr/sbin"; do
+ [[ -d "${d}" ]] || continue
+
+ # Read the results of the "find" command into the "found" bash
array.
+ # Use -L to catch symlinks whose targets are owned by a
non-root user,
+ # even though it won't catch ABSOLUTE symlinks until the package
+ # is RE-installed (the first time around, the target won't
exist).
+ # We do want to list non-superuser setuid executables, because
+ # they can be exploited. The owner can simply wipe the setuid
+ # bit, and then alter the contents of the file. The superuser
+ # will then have a time bomb in his $PATH.
+ while read -r -d '' f; do
+ found+=( "${f}" )
+ done < <(find -L "${d}" \
+ -maxdepth 1 \
+ -type f \
+ ! -uid 0 \
+ -print0)
+ done
+
+ if [[ ${found[@]} ]]; then
+ eqawarn "system executables owned by nonzero uid:"
+ for f in "${found[@]}"; do
+ # Strip off the leading destdir before outputting the
path,
+ # but leave the prefix if there is one.
+ eqawarn " ${f#${D%/}/}"
+ done
+ fi
+}
+
+bad_bin_owner_check
+:
--
2.16.4
[gentoo-portage-dev] [PATCH 2/2] bin/install-qa-check.d: add new 90bad-bin-group-write QA check.
System executables that are writable by a non-root user pose a
security risk. Anyone who can write to an executable can change its
behavior. If that executable is later run with elevated privileges
(say, by root, when the machine starts), then the non-root user can
escalate his own privileges to those of the person running the
modified executable.
The 90bad-bin-owner check already addresses one cause for a non-root
user to be able to modify an executable: because he owns it. This
commit adds another check, to ensure that no non-root *groups* have
write access to any system executables. On a "normal" system, all
system executables should belong to the super-user's group. To avoid
false-positives, non-"normal" systems (like prefix) are skipped.
Closes: https://bugs.gentoo.org/629398
---
bin/install-qa-check.d/90bad-bin-group-write | 49
1 file changed, 49 insertions(+)
create mode 100644 bin/install-qa-check.d/90bad-bin-group-write
diff --git a/bin/install-qa-check.d/90bad-bin-group-write
b/bin/install-qa-check.d/90bad-bin-group-write
new file mode 100644
index 0..3c5021e0d
--- /dev/null
+++ b/bin/install-qa-check.d/90bad-bin-group-write
@@ -0,0 +1,49 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+bad_bin_group_write_check() {
+ # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
+ # /usr/sbin, or /opt/bin) that are group-writable by a nonzero GID.
+
+ # This check doesn't work on non-root prefix installations at
+ # the moment, because every executable therein is owned by a
+ # nonzero GID.
+ [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
+
+ local d f found=()
+
+ for d in "${ED%/}/opt/bin" "${ED%/}/bin" "${ED%/}/usr/bin" \
+ "${ED%/}/sbin"
"${ED%/}/usr/sbin"; do
+ [[ -d "${d}" ]] || continue
+
+ # Read the results of the "find" command into the "found" bash
+ # array. Use -L to catch symlinks whose targets are vulnerable,
+ # even though it won't catch ABSOLUTE symlinks until the package
+ # is RE-installed (the first time around, the target won't
exist).
+ # We match the GID and not the name "root" here because (for
+ # example) on FreeBSD, the superuser group is "wheel".
+ # We avoid listing setgid executables because -- even though
they're
+ # super sketchy -- their non-root group is intentional.
+ while read -r -d '' f; do
+ found+=( "${f}" )
+ done < <(find -L "${d}" \
+ -maxdepth 1 \
+ -type f \
+ -perm /g+w\
+ ! -gid 0 \
+ ! -perm -2000 \
+ -print0)
+ done
+
+ if [[ ${found[@]} ]]; then
+ eqawarn "system executables group-writable by nonzero gid:"
+ for f in "${found[@]}"; do
+ # Strip off the leading destdir before outputting the
path,
+ # but leave the prefix if there is one.
+ eqawarn " ${f#${D%/}/}"
+ done
+ fi
+}
+
+bad_bin_group_write_check
+:
--
2.16.4
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2018-07-29 23:59 UTC
3d84bb9c9cd x11-misc/winswitch20180725-22:50 zlogene cddcf9838ac x11-plugins/wmlaptop 20180724-22:52 zlogene 44f2894b6ee Additions: app-metrics/burrow_exporter 20180726-17:56 mrueg 9a307cfc150 dev-libs/libfstrcmp 20180725-14:04 candrews 2c222f7234d dev-python/kaitaistruct 20180605-14:45 chainsaw 2cff6b95aaa dev-python/python-consul 20180725-17:56 mrueg c986848dce2 dev-python/python-netlink 20180725-01:28 zmedico f8814383738 dev-python/tappy 20180724-10:26 mgorny 0c866a5083f dev-util/tup 20180728-00:09 andrey_utkin 87056724896 games-emulation/jrommanager 20180711-10:05 mgorny a94b03d7740 gnome-extra/gnome-shell-extension-gsconnect 20180724-16:06 pacho 4485d26059f media-plugins/kodi-peripheral-steamcontroller 20180723-17:37 candrews 19a303ca833 sys-apps/sensei-raw-ctl 20180729-09:41 thev00d00 c17ecff78b0 sys-fs/fatresize 20180727-17:22 jer c095a8110e5 -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: media-plugins/gst-plugins-schroedinger,removed,leio,20180728-13:51,707b5731b0d net-misc/whatportis,removed,mgorny,20180728-13:02,aea591630ff app-misc/jira-cli,removed,mgorny,20180728-13:01,235ef6a607e games-arcade/xevil,removed,mgorny,20180728-12:14,fc9559077a1 dev-java/sun-jacc-api,removed,mgorny,20180728-12:14,7a95cab7a6e dev-java/servletapi,removed,mgorny,20180728-12:13,612ef9d514f dev-java/jdom-jaxen,removed,mgorny,20180728-12:12,fe8f1aa8e61 dev-libs/DirectFB,removed,mgorny,20180728-12:07,50a4c86ddd4 games-arcade/snake3d,removed,mgorny,20180728-12:05,30e541dda46 dev-python/django-two-factor-auth,removed,mgorny,20180728-12:04,cd2c0c5a89d sci-physics/hoomd-blue,removed,mgorny,20180728-12:03,87a357c9870 media-sound/gnac,removed,mgorny,20180728-12:03,d502a07b9ae games-simulation/dangerdeep,removed,mgorny,20180728-12:02,abf18fe077c media-gfx/postr,removed,mgorny,20180728-12:01,0cabbb0a90a games-strategy/gorky17-demo,removed,mgorny,20180728-12:01,b111ae4b626 app-misc/wyrd,removed,mgorny,20180728-11:57,df9d497e52a app-doc/mkdoxy,removed,mgorny,20180728-11:56,862948f6e19 net-libs/libwhisker,removed,mgorny,20180728-11:56,b7b9c071e5f sys-boot/getdvhoff,removed,mgorny,20180728-11:55,3452d636e3b games-arcade/marbleblastgold-demo,removed,mgorny,20180728-11:55,51c695a2f91 games-arcade/marbleblast-demo,removed,mgorny,20180728-11:54,f07aeb25cc1 games-arcade/skystreets,removed,mgorny,20180728-11:54,a09208f09ea games-emulation/gfceux,removed,mgorny,20180728-11:52,1d34e586d70 games-emulation/hugo,removed,mgorny,20180728-11:51,1934c92d159 games-emulation/kigb,removed,mgorny,20180728-11:51,ff27fc46b73 games-emulation/raine,removed,mgorny,20180728-11:50,c406c020a2b games-fps/aaquake2,removed,mgorny,20180728-11:50,77dfd2da408 games-fps/doomsday-resources,removed,mgorny,20180728-11:49,bd6a6b19610 games-fps/duke3d,removed,mgorny,20180728-11:48,1d08d5fec85 games-fps/lsdldoom,removed,mgorny,20180728-11:46,75a1bc93301 games-fps/soldieroffortune-demo,removed,mgorny,20180728-11:45,089380dae1b games-puzzle/ensemblist,removed,mgorny,20180728-11:45,136425af8df games-puzzle/hoh-bin,removed,mgorny,20180728-11:44,1ed8caecbd7 games-strategy/heroes3-demo,removed,mgorny,20180728-11:42,d257e92ba64 games-sports/miniracer,removed,mgorny,20180728-11:41,8c8204c585a app-crypt/openpgp-keys-gentoo-mirror,removed,mgorny,20180728-11:39,578d7b15842 app-i18n/ibus-tutcode,removed,mgorny,20180728-11:39,ae8130e2e42 sys-fs/aufs4,removed,mgorny,20180728-11:37,33e9b1ddbff sys-fs/aufs3,removed,mgorny,20180728-11:37,a95a109ee37 dev-python/pyxml,removed,zlogene,20180725-23:19,8b6ccd70a89 app-text/rhyme,removed,zlogene,20180725-23:14,06794555a43 dev-python/pyrtf,removed,zlogene,20180725-23:10,f4cb5da2bd2 dev-java/easyneurons,removed,zlogene,20180725-23:02,5b4fc0adce8 net-misc/openvpn-auth-ldap,removed,zlogene,20180725-22:58,6ba685b8d0b x11-misc/winswitch,removed,zlogene,20180725-22:50,cddcf9838ac games-emulation/advancemenu,removed,zlogene,20180724-23:12,2cd73c7da92 app-text/gentoo-guide-xml-dtd,removed,zlogene,20180724-23:07,21e07e157fb dev-python/eliot,removed,zlogene,20180724-22:59,cecdd7aa897 x11-libs/libiterm-mbt,removed,zlogene,20180724-22:55,3d84bb9c9cd x11-plugins/wmlaptop,removed,zlogene,20180724-22:52,44f2894b6ee games-fps/postal2mp-demo,removed,zlogene,20180724-22:48,81550bf8371 net-irc/ircservices,removed,zlogene,20180724-22:39,4b137236165 www-apps/phprojekt,removed,grknight,20180723-14:08,8811e877bda www-apps/polarblog,removed,grknight,20180723-14:05,f87a95a87a2 www-apps/phpmp,removed,grknight,20180723-14:03,3324eee670b www-apps/mypictures,removed,grknight,20180723-13
Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.
On 07/29/2018 03:43 PM, Ulrich Mueller wrote: > >> On a "normal" system, there is no good reason why the superuser should >> not own every system executable. This commit adds a new install-time >> check that reports any such binaries with a QA warning. To avoid false >> positives, non-"normal" systems (like prefix) are skipped at the moment. > > Shouldn't this check for setuid binaries like /usr/bin/mandb (which is > owned by man:man)? I think these are legitimate usage case. > After thinking about this for a while, I think we should ignore setgid but not setuid executables. The problem with setuid and a non-root owner is that the owner can always exploit the situation: Suppose /bin/foo is owned by "foo" and setuid. If root (or any other privileged user) is about to run /bin/foo, then the "foo" user can simply strip away the setuid bit and fill /bin/foo with malicious code. The same situation with setgid is safe because (as far as I know) members of the group can't strip off the setgid bit.
Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.
On 07/29/2018 03:43 PM, Ulrich Mueller wrote: > > Shouldn't this check for setuid binaries like /usr/bin/mandb (which is > owned by man:man)? I think these are legitimate usage case. > In general, yeah. I think we should be skeptical of setuid/gid executables, but this isn't the right place to make that stand. In this specific case, though, I don't see why that program is setuid. In fact, I'm pretty sure it lets the "man" user gain root privileges.
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Sun, Jul 29, 2018 at 1:01 PM, Rich Freeman wrote:
> On Sun, Jul 29, 2018 at 3:56 PM Matt Turner wrote:
>>
>> On Fri, Jul 27, 2018 at 1:32 AM, Ulrich Mueller wrote:
>> >
>> > So, considering all the feedback from mailing list and IRC:
>> >
>> >/usr/portage -> /var/db/repos/gentoo
>> >/usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
>> >/usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
>> >
>> > Open question: Should we have the additional "gentoo" path component
>> > for the ones in /var/cache? The tradeoff is between a path that is
>> > easier to type, or slightly easier usage if someone wants to NFS mount
>> > distfiles and binpkgs.
>>
>> That proposal has by vote of support. No strong preference on whether
>> to include gentoo/ or not. It's one NFS mount vs two so not a big deal
>> either way.
>>
>
> Why not stick the repos in /var/repos and not /var/db/repos? If we're
> just making up paths, why not make up a shorter one? I don't think
> any other linux distros use /var/db...
That would be fine with me as well :)
Re: [gentoo-dev] rfc: moving default location of portage tree
> On Fri, 27 Jul 2018, Brian Dolbec wrote:
> On Fri, 27 Jul 2018 16:31:15 +0200
> Ulrich Mueller wrote:
>> > On Fri, 27 Jul 2018, Corentin “Nado” Pazdera wrote:
>>
>> > From the same source
>> > "No other requirements are made on the data format of the cache
>> > directories."
>> > And as you have quoted it, everything under /var/cache is
>> > optional.
>>
>> > So anything which doesn't conflict with another package seems
>> > fine according to FHS.
>>
>> That's how I would read it, too. We could of course invent a
>> package name (like "package-manager" for virtual/package-manager)
>> but it seems cumbersome, and I don't see any benefit of it.
>>
>> There also is /var/cache/fonts, so the FHS itself lists an example
>> of a directory that's not named after a specific package.
> /var/db/repos/gentoo
> /var/cache/distfiles
> /var/cache/binpkgs
For the record, these three paths have been approved in today's
Council meeting.
> Works for me, just please keep "portage" out of it, after all
> distfiles are not restricted to portage use only, and neither are
> binpkgs. There is alternate binpkg installers.
By another Council vote, snapshot names should be changed from
portage-MMDD.tar.{bz2,xz} to gentoo-MMDD.tar.{bz2,xz}.
So, no "portage" any more. ;)
Ulrich
pgpabZ6TuTvWB.pgp
Description: PGP signature
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On 29/07/18 21:01, Rich Freeman wrote: > > > Why not stick the repos in /var/repos and not /var/db/repos? If we're > just making up paths, why not make up a shorter one? I don't think > any other linux distros use /var/db... > *BSD I believe .. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Sun, Jul 29, 2018 at 3:56 PM Matt Turner wrote:
>
> On Fri, Jul 27, 2018 at 1:32 AM, Ulrich Mueller wrote:
> >
> > So, considering all the feedback from mailing list and IRC:
> >
> >/usr/portage -> /var/db/repos/gentoo
> >/usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
> >/usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
> >
> > Open question: Should we have the additional "gentoo" path component
> > for the ones in /var/cache? The tradeoff is between a path that is
> > easier to type, or slightly easier usage if someone wants to NFS mount
> > distfiles and binpkgs.
>
> That proposal has by vote of support. No strong preference on whether
> to include gentoo/ or not. It's one NFS mount vs two so not a big deal
> either way.
>
Why not stick the repos in /var/repos and not /var/db/repos? If we're
just making up paths, why not make up a shorter one? I don't think
any other linux distros use /var/db...
--
Rich
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Fri, Jul 27, 2018 at 1:32 AM, Ulrich Mueller wrote:
>> On Thu, 19 Jul 2018, Chí-Thanh Christopher Nguyễn wrote:
>
>>> Users must never need to modify files in /var/lib to configure a
>>> package's operation, and _the_specific_file_hierarchy_ used to
>>> store the data _must_not_be_ _exposed_ to regular users."
>
>> One small note, while it is never needed to modify, skel.ebuild
>> would then be a file that is meant to be accessed by users in
>> /var/lib if your proposal is realized.
>
> That's one of the reasons why the proposal prefers /var/db. The other
> reason is existing usage in eselect-repository.
>
>> On Thu, 19 Jul 2018, Ulrich Mueller wrote:
>
>> In my understanding, a cache is typically an open collection of items.
>> Some subset of them can be deleted without much negative consequence,
>> and there may also be surplus items that are no longer necessary and
>> will be expired at some later time in order to reclaim disk space.
>
>> Nothing of this is true for an ebuild repository, which is a closed
>> collection of files: A single file cannot be discarded without
>> invalidating the whole repository. Also there cannot be any stray
>> files which would be expired later. Same as above, a single stray file
>> will invalidate all.
>
>> (A collection of binary packages may qualify as a cache though, by
>> this definition.)
>
> So, considering all the feedback from mailing list and IRC:
>
>/usr/portage -> /var/db/repos/gentoo
>/usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
>/usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
>
> Open question: Should we have the additional "gentoo" path component
> for the ones in /var/cache? The tradeoff is between a path that is
> easier to type, or slightly easier usage if someone wants to NFS mount
> distfiles and binpkgs.
That proposal has by vote of support. No strong preference on whether
to include gentoo/ or not. It's one NFS mount vs two so not a big deal
either way.
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Fri, Jul 27, 2018 at 1:40 AM, Michał Górny wrote:
> Dnia 27 lipca 2018 10:32:17 CEST, Ulrich Mueller napisał(a):
>>> On Thu, 19 Jul 2018, Chí-Thanh Christopher Nguyễn wrote:
>>
Users must never need to modify files in /var/lib to configure a
package's operation, and _the_specific_file_hierarchy_ used to
store the data _must_not_be_ _exposed_ to regular users."
>>
>>> One small note, while it is never needed to modify, skel.ebuild
>>> would then be a file that is meant to be accessed by users in
>>> /var/lib if your proposal is realized.
>>
>>That's one of the reasons why the proposal prefers /var/db. The other
>>reason is existing usage in eselect-repository.
>>
>>> On Thu, 19 Jul 2018, Ulrich Mueller wrote:
>>
>>> In my understanding, a cache is typically an open collection of
>>items.
>>> Some subset of them can be deleted without much negative consequence,
>>> and there may also be surplus items that are no longer necessary and
>>> will be expired at some later time in order to reclaim disk space.
>>
>>> Nothing of this is true for an ebuild repository, which is a closed
>>> collection of files: A single file cannot be discarded without
>>> invalidating the whole repository. Also there cannot be any stray
>>> files which would be expired later. Same as above, a single stray
>>file
>>> will invalidate all.
>>
>>> (A collection of binary packages may qualify as a cache though, by
>>> this definition.)
>>
>>So, considering all the feedback from mailing list and IRC:
>>
>> /usr/portage -> /var/db/repos/gentoo
>> /usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
>> /usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
>>
>>Open question: Should we have the additional "gentoo" path component
>>for the ones in /var/cache? The tradeoff is between a path that is
>>easier to type, or slightly easier usage if someone wants to NFS mount
>>distfiles and binpkgs.
>
> Note that NFS is not exactly clear cut here since binpkgs are not portable to
> different hosts, so you can have multiple variants of it.
True, but trivially solvable by configuring like-hosts to share
packages. Skylake packages go here, Sandybridge packages go here, etc.
This is what I do.
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
[Proxying a message from Anders Thomson ] Hi Ulrich, As non-devs aren't allowed to post to gentoo-dev, I was hoping that you would proxy this question/comment for me. While on the subject of changing defaults, could we consider changing the (default) location of the pkg db? Roughly everything in /usr (and /(s)bin) is managed by the package manager, and it would be handy if the db of installed bits is close to the bits themselves . Keeping it in /var/ makes /var opinionated on the current set of installed packages and thus another thing to backup etc of you want "just the os/system stuff, not the applications' databases". along the same vein, if you want /var to be on another storage device (NAS/SAN for large databases), you get the OS's pkg db with it. If for any reason a boot fails to get /var mounted, you're without the pkg db. Something along the lines of /usr/lib/pkg ? Best, /Anders On Fri, Jul 27, 2018 at 4:31 PM, Ulrich Mueller wrote: > On Fri, 27 Jul 2018, Corentin “Nado” Pazdera wrote: > July 27, 2018 4:07 PM, "William Hubbs" wrote: >> Section 5.5.2 describes the directory structure of /var/cache. >> These paths are all optional [1]. >> >> /var/cache/fonts >> /var/cache/man >> /var/cache/www >> /var/cache/ >> >> Gentoo isn't a package, so I don't think /var/cache/gentoo/* is >> appropriate. Here is my proposal: >> >> /usr/portage -> /var/db/repos/gentoo >> /usr/portage/distfiles -> /var/cache/portage/distfiles >> /usr/portage/packages -> /var/cache/portage/binpkgs >> >> I'm not 100% comfortable with /var/db, but I don't have any better >> suggestion either. >> >> [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varcacheApplicationCacheData > From the same source > "No other requirements are made on the data format of the cache > directories." > And as you have quoted it, everything under /var/cache is optional. > So anything which doesn't conflict with another package seems fine > according to FHS. That's how I would read it, too. We could of course invent a package name (like "package-manager" for virtual/package-manager) but it seems cumbersome, and I don't see any benefit of it. There also is /var/cache/fonts, so the FHS itself lists an example of a directory that's not named after a specific package. Ulrich pgpvkqkV7URia.pgp Description: PGP signature
Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.
> On Sun, 29 Jul 2018, Michael Orlitzky wrote: > System executables that are not owned by root pose a security > risk. The owner of the executable is free to modify it at any time; > so, for example, he can change a daemon's behavior to make it > malicious before the next time the service is started (usually by > root). > On a "normal" system, there is no good reason why the superuser should > not own every system executable. This commit adds a new install-time > check that reports any such binaries with a QA warning. To avoid false > positives, non-"normal" systems (like prefix) are skipped at the moment. Shouldn't this check for setuid binaries like /usr/bin/mandb (which is owned by man:man)? I think these are legitimate usage case. Ulrich pgptqtrJo8E1U.pgp Description: PGP signature
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
W dniu pią, 27.07.2018 o godzinie 08∶06 -0700, użytkownik Brian Dolbec napisał: > On Fri, 27 Jul 2018 16:31:15 +0200 > Ulrich Mueller wrote: > > > > > > > > On Fri, 27 Jul 2018, Corentin “Nado” Pazdera wrote: > > > July 27, 2018 4:07 PM, "William Hubbs" > > > wrote: > > > > Section 5.5.2 describes the directory structure of /var/cache. > > > > These paths are all optional [1]. > > > > > > > > /var/cache/fonts > > > > /var/cache/man > > > > /var/cache/www > > > > /var/cache/ > > > > > > > > Gentoo isn't a package, so I don't think /var/cache/gentoo/* is > > > > appropriate. Here is my proposal: > > > > > > > > /usr/portage -> /var/db/repos/gentoo > > > > /usr/portage/distfiles -> /var/cache/portage/distfiles > > > > /usr/portage/packages -> /var/cache/portage/binpkgs > > > > > > > > I'm not 100% comfortable with /var/db, but I don't have any better > > > > suggestion either. > > > > > > > > [1] > > > > http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#varcacheApplicationCacheData > > > > > > > From the same source > > > "No other requirements are made on the data format of the cache > > > directories." > > > And as you have quoted it, everything under /var/cache is > > > optional. > > > So anything which doesn't conflict with another package seems fine > > > according to FHS. > > > > That's how I would read it, too. We could of course invent a package > > name (like "package-manager" for virtual/package-manager) but it seems > > cumbersome, and I don't see any benefit of it. > > > > There also is /var/cache/fonts, so the FHS itself lists an example of > > a directory that's not named after a specific package. > > > > Ulrich > > /var/db/repos/gentoo > /var/cache/distfiles > /var/cache/binpkgs > > Works for me, just please keep "portage" out of it, after all distfiles > are not restricted to portage use only, and neither are binpkgs. There > is alternate binpkg installers. Well, technically speaking this specific binary package format is Portage-specific. But I don't think we need to go into that kind of nuances. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.
W dniu nie, 29.07.2018 o godzinie 13∶37 -0400, użytkownik Michael
Orlitzky napisał:
> System executables that are not owned by root pose a security
> risk. The owner of the executable is free to modify it at any time;
> so, for example, he can change a daemon's behavior to make it
> malicious before the next time the service is started (usually by
> root).
>
> On a "normal" system, there is no good reason why the superuser should
> not own every system executable. This commit adds a new install-time
> check that reports any such binaries with a QA warning. To avoid false
> positives, non-"normal" systems (like prefix) are skipped at the moment.
>
> Bug: https://bugs.gentoo.org/629398
> ---
> bin/install-qa-check.d/90bad-bin-owner | 38
> ++
> 1 file changed, 38 insertions(+)
> create mode 100644 bin/install-qa-check.d/90bad-bin-owner
>
> diff --git a/bin/install-qa-check.d/90bad-bin-owner
> b/bin/install-qa-check.d/90bad-bin-owner
> new file mode 100644
> index 0..188d67a51
> --- /dev/null
> +++ b/bin/install-qa-check.d/90bad-bin-owner
> @@ -0,0 +1,38 @@
> +# Copyright 1999-2018 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +
> +bad_bin_owner_check() {
> + # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
> + # or /usr/sbin) that are owned by a nonzero UID.
> +
> + # This check doesn't work on non-root prefix installations at
> + # the moment, because every executable therein is owned by a
> + # nonzero UID.
> + [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
> +
> + local d f found=()
> +
> + for d in "${ED%/}/bin" "${ED%/}/usr/bin" "${ED%/}/sbin"
> "${ED%/}/usr/sbin"; do
I think you should include /opt/bin as well. Or maybe simply all
locations on ${PATH}.
> + [[ -d "${d}" ]] || continue
> +
> + # Read the results of the "find" command into the "found" bash
> array.
> + # Use -L to catch symlinks whose targets are owned by a
> non-root user,
> + # even though it won't catch ABSOLUTE symlinks until the package
> + # is RE-installed (the first time around, the target won't
> exist).
> + while read -r -d '' f; do
> + found+=( "${f}" )
> + done < <(find -L "${d}" -maxdepth 1 -type f ! -uid 0 -print0)
> +
> + if [[ ${found[@]} ]]; then
> + eqawarn "system executables owned by nonzero uid:"
> + for f in "${found[@]}"; do
> + # Strip off the leading destdir before
> outputting the path,
> + # but leave the prefix if there is one.
> + eqawarn " ${f#${D%/}/}"
> + done
> + fi
> + done
> +}
> +
> +bad_bin_owner_check
> +:
--
Best regards,
Michał Górny
signature.asc
Description: This is a digitally signed message part
[gentoo-portage-dev] [PATCH 2/2] bin/install-qa-check.d: add new 90bad-bin-group-write QA check.
System executables that are writable by a non-root user pose a
security risk. Anyone who can write to an executable can change its
behavior. If that executable is later run with elevated privileges
(say, by root, when the machine starts), then the non-root user can
escalate his own privileges to those of the person running the
modified executable.
The 90bad-bin-owner check already addresses one cause for a non-root
user to be able to modify an executable: because he owns it. This
commit adds another check, to ensure that no non-root *groups* have
write access to any system executables. On a "normal" system, all
system executables should belong to the super-user's group. To avoid
false-positives, non-"normal" systems (like prefix) are skipped.
Closes: https://bugs.gentoo.org/629398
---
bin/install-qa-check.d/90bad-bin-group-write | 40
1 file changed, 40 insertions(+)
create mode 100644 bin/install-qa-check.d/90bad-bin-group-write
diff --git a/bin/install-qa-check.d/90bad-bin-group-write
b/bin/install-qa-check.d/90bad-bin-group-write
new file mode 100644
index 0..f8a0259e5
--- /dev/null
+++ b/bin/install-qa-check.d/90bad-bin-group-write
@@ -0,0 +1,40 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+bad_bin_group_write_check() {
+ # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
+ # or /usr/sbin) that are group-writable by a nonzero GID.
+
+ # This check doesn't work on non-root prefix installations at
+ # the moment, because every executable therein is owned by a
+ # nonzero GID.
+ [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
+
+ local d f found=()
+
+ for d in "${ED%/}/bin" "${ED%/}/usr/bin" "${ED%/}/sbin"
"${ED%/}/usr/sbin"; do
+ test -d "${d}" || continue
+
+ # Read the results of the "find" command into the "found" bash
+ # array. Use -L to catch symlinks whose targets are vulnerable,
+ # even though it won't catch ABSOLUTE symlinks until the package
+ # is RE-installed (the first time around, the target won't
exist).
+ # We match the GID and not the name "root" here because (for
+ # example) on FreeBSD, the superuser group is "wheel".
+ while read -r -d '' f; do
+ found+=( "${f}" )
+ done < <(find -L "${d}" -maxdepth 1 -type f -perm /g+w ! -gid 0
-print0)
+
+ if [[ ${found[@]} ]]; then
+ eqawarn "system executables group-writable by nonzero
gid:"
+ for f in "${found[@]}"; do
+ # Strip off the leading destdir before
outputting the path,
+ # but leave the prefix if there is one.
+ eqawarn " ${f#${D%/}/}"
+ done
+ fi
+ done
+}
+
+bad_bin_group_write_check
+:
--
2.16.4
[gentoo-portage-dev] [PATCH 0/2] Two insecure ownership and group-writability QA checks.
Discussed and implemented in, https://bugs.gentoo.org/629398 Michael Orlitzky (2): bin/install-qa-check.d: add new 90bad-bin-owner QA check. bin/install-qa-check.d: add new 90bad-bin-group-write QA check. bin/install-qa-check.d/90bad-bin-group-write | 40 bin/install-qa-check.d/90bad-bin-owner | 38 ++ 2 files changed, 78 insertions(+) create mode 100644 bin/install-qa-check.d/90bad-bin-group-write create mode 100644 bin/install-qa-check.d/90bad-bin-owner -- 2.16.4
[gentoo-portage-dev] [PATCH 1/2] bin/install-qa-check.d: add new 90bad-bin-owner QA check.
System executables that are not owned by root pose a security
risk. The owner of the executable is free to modify it at any time;
so, for example, he can change a daemon's behavior to make it
malicious before the next time the service is started (usually by
root).
On a "normal" system, there is no good reason why the superuser should
not own every system executable. This commit adds a new install-time
check that reports any such binaries with a QA warning. To avoid false
positives, non-"normal" systems (like prefix) are skipped at the moment.
Bug: https://bugs.gentoo.org/629398
---
bin/install-qa-check.d/90bad-bin-owner | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 bin/install-qa-check.d/90bad-bin-owner
diff --git a/bin/install-qa-check.d/90bad-bin-owner
b/bin/install-qa-check.d/90bad-bin-owner
new file mode 100644
index 0..188d67a51
--- /dev/null
+++ b/bin/install-qa-check.d/90bad-bin-owner
@@ -0,0 +1,38 @@
+# Copyright 1999-2018 Gentoo Foundation
+# Distributed under the terms of the GNU General Public License v2
+
+bad_bin_owner_check() {
+ # Warn about globally-installed executables (in /bin, /usr/bin, /sbin,
+ # or /usr/sbin) that are owned by a nonzero UID.
+
+ # This check doesn't work on non-root prefix installations at
+ # the moment, because every executable therein is owned by a
+ # nonzero UID.
+ [[ "${EUID}" -ne "0" || "${PORTAGE_INST_UID}" -ne "0" ]] && return
+
+ local d f found=()
+
+ for d in "${ED%/}/bin" "${ED%/}/usr/bin" "${ED%/}/sbin"
"${ED%/}/usr/sbin"; do
+ [[ -d "${d}" ]] || continue
+
+ # Read the results of the "find" command into the "found" bash
array.
+ # Use -L to catch symlinks whose targets are owned by a
non-root user,
+ # even though it won't catch ABSOLUTE symlinks until the package
+ # is RE-installed (the first time around, the target won't
exist).
+ while read -r -d '' f; do
+ found+=( "${f}" )
+ done < <(find -L "${d}" -maxdepth 1 -type f ! -uid 0 -print0)
+
+ if [[ ${found[@]} ]]; then
+ eqawarn "system executables owned by nonzero uid:"
+ for f in "${found[@]}"; do
+ # Strip off the leading destdir before
outputting the path,
+ # but leave the prefix if there is one.
+ eqawarn " ${f#${D%/}/}"
+ done
+ fi
+ done
+}
+
+bad_bin_owner_check
+:
--
2.16.4
[gentoo-dev] Re: rfc: [QA] Ban policy introduction
On 29.07.2018 00:40, Mikle Kolyada wrote: > Hello, > > The Gentoo QA team would like to introduce the following policy that > would be applied to individuals breaking the state and quality of the > main gentoo.git tree > > ( as we do not have this strictly documented yet): > > > > If recommended Gentoo workflow policies are not followed by an > individual developer > (e.g make major changes to the widely used eclasses without prior > discussion on the mailing list or > commit changes that lead to multiple CI checks failure), the standard QA > procedure is: > > 1.) Two warnings granted by QA team, after two independent breakages > 2.) Revoking the commit access for 14 days > > These violations will be evaluated individually by all QA team members. > Warnings can be revoked, if during 6 months period a developer makes at > least 20 non trivial changes not producing more breakages. > > > > > > Meh, I sent this one a bit prematurely, sorry for the spam, we will work on it a bit more before it reaches an official point signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
On Sun, Jul 29, 2018 at 4:17 AM, Andrew Savchenko wrote: > On Sun, 29 Jul 2018 16:47:47 +0900 Alice Ferrazzi wrote: >> Sent from my phone. Please excuse my brevity. >> >> On Sun, 29 Jul 2018, 16:39 Fabian Groffen, wrote: >> >> > Completely agreeing with Sergei, with some additional suggestions: >> > >> > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: >> > > On Sun, 29 Jul 2018 00:40:18 +0300 >> > > Mikle Kolyada wrote: >> > > >> > > > Hello, >> > > > >> > > > The Gentoo QA team would like to introduce the following policy that >> > > > would be applied to individuals breaking the state and quality of the >> > > > main gentoo.git tree >> > > > >> > > > ( as we do not have this strictly documented yet): >> > > > >> > > > >> > > > >> > > > If recommended >> > > >> > > It's not called "recommended" but "enforced". >> > >> > I agree. If you put penalties on these, they become hard rules. I >> > think that change should be discussed by the council perhaps? > > +1. Also please provide some tool for developers to check for > compliance to these rules, e.g. repoman full must perform all these > checks. > > If developers have no way to verify correctness of the code, they > can't be held responsible for accidental violation of the rules. > >> > > > the standard QA >> > > > procedure is: >> > > > >> > > > 1.) Two warnings granted by QA team, after two independent breakages >> > > > 2.) Revoking the commit access for 14 days >> > > > >> > > > These violations will be evaluated individually by all QA team members. >> > > > Warnings can be revoked, if during 6 months period a developer makes at >> > > > least 20 non trivial changes not producing more breakages. > > Why 6 months period? Why time frame at all? 20 good commits sounds > OK. If you want time frame, then you should set autoexpire of > warning as well. > Best regards, > Andrew Savchenko That reads to me as "warnings become permanent after six months if not remediated with 20 non-trivial good commits", not that they expire.
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
On Sun, 29 Jul 2018 16:47:47 +0900 Alice Ferrazzi wrote: > Sent from my phone. Please excuse my brevity. > > On Sun, 29 Jul 2018, 16:39 Fabian Groffen, wrote: > > > Completely agreeing with Sergei, with some additional suggestions: > > > > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > > > On Sun, 29 Jul 2018 00:40:18 +0300 > > > Mikle Kolyada wrote: > > > > > > > Hello, > > > > > > > > The Gentoo QA team would like to introduce the following policy that > > > > would be applied to individuals breaking the state and quality of the > > > > main gentoo.git tree > > > > > > > > ( as we do not have this strictly documented yet): > > > > > > > > > > > > > > > > If recommended > > > > > > It's not called "recommended" but "enforced". > > > > I agree. If you put penalties on these, they become hard rules. I > > think that change should be discussed by the council perhaps? +1. Also please provide some tool for developers to check for compliance to these rules, e.g. repoman full must perform all these checks. If developers have no way to verify correctness of the code, they can't be held responsible for accidental violation of the rules. > > > > the standard QA > > > > procedure is: > > > > > > > > 1.) Two warnings granted by QA team, after two independent breakages > > > > 2.) Revoking the commit access for 14 days > > > > > > > > These violations will be evaluated individually by all QA team members. > > > > Warnings can be revoked, if during 6 months period a developer makes at > > > > least 20 non trivial changes not producing more breakages. Why 6 months period? Why time frame at all? 20 good commits sounds OK. If you want time frame, then you should set autoexpire of warning as well. What is the definition of non-trivial change? There will be commits which may be seen as trivial by one person (e.g. because it is one-liner) and as non-trivial by another (e.g. because such commit fixes serious bug). > if you want to enforce rules, would be productive to also have extensive > documentation on how to avoid to make such problems. > Better would be to invest more time in something like the breckage checker > script, similar at what mgorny is doing, than adding more ways to block > developers contributions. > > thanks, > Alice Best regards, Andrew Savchenko pgpmyxUP15S3S.pgp Description: PGP signature
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
Sent from my phone. Please excuse my brevity. On Sun, 29 Jul 2018, 16:39 Fabian Groffen, wrote: > Completely agreeing with Sergei, with some additional suggestions: > > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > > On Sun, 29 Jul 2018 00:40:18 +0300 > > Mikle Kolyada wrote: > > > > > Hello, > > > > > > The Gentoo QA team would like to introduce the following policy that > > > would be applied to individuals breaking the state and quality of the > > > main gentoo.git tree > > > > > > ( as we do not have this strictly documented yet): > > > > > > > > > > > > If recommended > > > > It's not called "recommended" but "enforced". > > I agree. If you put penalties on these, they become hard rules. I > think that change should be discussed by the council perhaps? > > > > Gentoo workflow policies are not followed by an > > > individual developer > > > (e.g make major changes to the widely used eclasses without prior > > > discussion on the mailing list or > > > commit changes that lead to multiple CI checks failure) > > > > Here should go exhaustive list of links to the policies to be enforced. > > At least. And they should be clear and concise. No "common sense" or > anything involved for exceptions and the like. In addition, new checks > should be introduced to the community and possibly approved by council > as to whether being enforced or not. > > Fabian > > > > > > the standard QA > > > procedure is: > > > > > > 1.) Two warnings granted by QA team, after two independent breakages > > > 2.) Revoking the commit access for 14 days > > > > > > These violations will be evaluated individually by all QA team members. > > > Warnings can be revoked, if during 6 months period a developer makes at > > > least 20 non trivial changes not producing more breakages. > > > > > > > > > > -- > > > if you want to enforce rules, would be productive to also have extensive documentation on how to avoid to make such problems. Better would be to invest more time in something like the breckage checker script, similar at what mgorny is doing, than adding more ways to block developers contributions. thanks, Alice >
Re: [gentoo-dev] rfc: [QA] Ban policy introduction
Completely agreeing with Sergei, with some additional suggestions: On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > On Sun, 29 Jul 2018 00:40:18 +0300 > Mikle Kolyada wrote: > > > Hello, > > > > The Gentoo QA team would like to introduce the following policy that > > would be applied to individuals breaking the state and quality of the > > main gentoo.git tree > > > > ( as we do not have this strictly documented yet): > > > > > > > > If recommended > > It's not called "recommended" but "enforced". I agree. If you put penalties on these, they become hard rules. I think that change should be discussed by the council perhaps? > > Gentoo workflow policies are not followed by an > > individual developer > > (e.g make major changes to the widely used eclasses without prior > > discussion on the mailing list or > > commit changes that lead to multiple CI checks failure) > > Here should go exhaustive list of links to the policies to be enforced. At least. And they should be clear and concise. No "common sense" or anything involved for exceptions and the like. In addition, new checks should be introduced to the community and possibly approved by council as to whether being enforced or not. Fabian > > > the standard QA > > procedure is: > > > > 1.) Two warnings granted by QA team, after two independent breakages > > 2.) Revoking the commit access for 14 days > > > > These violations will be evaluated individually by all QA team members. > > Warnings can be revoked, if during 6 months period a developer makes at > > least 20 non trivial changes not producing more breakages. > > > > > > -- > > Sergei > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
