** Changed in: shadow (openSUSE)
Status: Confirmed => Fix Released
--
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 noti
@stgraber @mdeslaur - I'd considered making a release for Ubuntu... but
this is the negative acl thing... Your opinions appreciated.
--
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:
un
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
Launchpad has imported 5 comments from the remote bug at
https://bugzilla.opensuse.org/show_bug.cgi?id=1081294.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://h
** 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
It's really not a problem, I'm happy to leave it as it is.
--
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
On Thu, Feb 15, 2018 at 11:30 PM, Craig Furman
<1729...@bugs.launchpad.net> wrote:
> Thanks for the credit! I did highlight that the bug was in newgidmap in
> my initial report, by the way.
No problem -- you found the issue after all. Sorry for getting the timeline
wrong, did you want me to change
Thanks for the credit! I did highlight that the bug was in newgidmap in
my initial report, by the way.
Aleksa, thanks for asking for a CVE? How did you go about this? This is
new territory to me.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed t
Yes, of course. "Craig Furman (Pivotal)" is in the credits. I also
added Akihiro Suda (for suggesting him that it was a newgidmap bug)
and myself (for working on a fix for it), but if Craig prefers I can
just make him the only credit.
On Thu, Feb 15, 2018 at 11:00 PM, Christian Brauner
wrote:
> O
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 notification because you are a member of Ubuntu
Bugs, which is
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
@cyphar
Did you submit patch/CVE?
--
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 bug go to:
https:/
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
This sounds acceptable to me. Issues or (even better) PRs against
github.com/shadow-maint/shadow would be great :)
Indeed the default should be the more permissible. (I won't accept
patches which require changes to the container runtime.)
On Mon, Jan 15, 2018 at 9:13 AM, Akihiro Suda wrote:
>
> And we define flags "allow_setgroups" and "deny_setgrouops" (with
"deny_setgroups" being the default).
I think allow_setgropus should be the default for keeping compatibility.
However, useradd(8) may print warning for the default configuration.
--
You received this bug notification because y
> 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
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.
Also, newgidmap will allow a user to map their own GID to 0 in the user
name
Eric W. Biederman contributed this via email:
> The short answer is that if you want negative acls to work don't try and
> apply them to a user in /etc/subuid or /etc/subgid.
>
> To my knowledge there is not a good solution to this problem.
>
> As for setting setgroups to deny that is the defaul
23 matches
Mail list logo
