https://github.com/shadow-maint/shadow/pull/99 includes the
allow_setgroups/deny_setgroups feature that we discussed earlier.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1729357
Title:
unprivilege
** Bug watch added: bugzilla.opensuse.org/ #1081294
https://bugzilla.opensuse.org/show_bug.cgi?id=1081294
** Changed in: shadow (openSUSE)
Importance: Undecided => Unknown
** Changed in: shadow (openSUSE)
Status: New => Unknown
** Changed in: shadow (openSUSE)
Remote watch: None =>
CVE-2018-7169 is assigned for this issue.
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-7169
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1729357
Title:
unprivileged user can d
** Also affects: shadow (openSUSE)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1729357
Title:
unprivileged user can drop supplementary groups
To manage
https://github.com/shadow-maint/shadow/pull/97 is my proposed patch. It
currently only deals with the immediate security issue of allowing users
that don't have
% echo "$(whoami):$(id -g):1" >> /etc/setgid
... set up. I've tested this with a couple of different setups and it
appears to preserve
th MITRE. (Canonical is
registered for example, but since this bug affects all distributions and not
just Ubuntu I felt it made more sense to just submit directly.)
There didn't appear to be any way for me to add you to Cc in the form (I could
only provide a single contact address), but I can forward t
ner
wrote:
> On Thu, Feb 15, 2018 at 11:29:03AM -, Aleksa Sarai wrote:
>> I've just sent a request for a CVE. I'm working on the patch now. My
>
> I assume the CVE will at least be correctly attributed to Craig.
>
> Christian
>
> --
> You received this bug
I've just sent a request for a CVE. I'm working on the patch now. My
current plan is that allow_setgroups will be the default for all
mappings that are present in /etc/subgid -- but any "implicit" mappings
(like mapping your own group) will be deny_setgroups by default (because
that's the biggest s
I had a preliminary patch written, but it was getting quite complicated
(shadow's codebase is much more complicated than I expected -- and the
/etc/subgid parsing code is intertwined with the parsing code for all of
the other /etc/... files). I am working on it though.
I've also email the SUSE Sec
Serge: I will submit a patch later today. However, I just thought that
it's probably better that "allow_setgroups" should be "ignore_setgroups"
and we retain the current behaviour (we don't write anything to
/proc/$pid/setgroups) -- which allows a user (or runtime) to explicitly
disable setgroups e
Oh, and we should definitely get a CVE assigned IMO.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1729357
Title:
unprivileged user can drop supplementary groups
To manage notifications about this
> Thanks for replying Eric, but I'm having trouble reproducing what you've
> posted. I can't write the gid map until I've written deny to
> /prod/$pid/setgroups, not the other way around. There might be some nuance
> I've missed.
Yes, this is a security feature. setgroups must be written to *befor
12 matches
Mail list logo
