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
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
> 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
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.
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
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
-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
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"
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
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 ->
> 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
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
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 ->
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_
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
[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
> 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
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
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
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
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
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
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
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 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:
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:
> >
>
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
27 matches
Mail list logo
