Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1069385 > unrolled thread

Bug#993488: security-tracker: Revoked group permission on a user continue to take effect on all existing processes and sessions

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#993488: security-tracker: Revoked group permission on a user continue to take effect on all existing processes and sessions xuancong84 <xuancong84@gmail.com> - 2021-09-02 05:30 +0200
    Bug#993488: maybe reason for wontfix? Tomas Pospisek <tpo@sourcepole.ch> - 2021-09-03 14:30 +0200
      Bug#993488: maybe reason for wontfix? Philipp Kern <pkern@debian.org> - 2021-09-03 15:10 +0200

#1069385 — Bug#993488: security-tracker: Revoked group permission on a user continue to take effect on all existing processes and sessions

Package: security-tracker
Severity: important
Tags: security

Dear Debian security team,

This bug deals with the lower framework of Linux/Debian system, it affects at
least all debian-based Linux Distros like Ubuntu, MX-Linux, etc.

Steps to reproduce:
1. create a new group called secure01
addgroup secure01

2. create files that are only accessible by the group
mkdir /mnt/secure-folder
echo yes >/mnt/secure-folder/secure-file
chown -R root:secure01 /mnt/secure-folder/
chmod -R o-rwx /mnt/secure-folder

3. add an existing user into the group
usermod -a -G secure01 user01

BUG1:
if user01 is already logged in, he still cannot access /mnt/secure-
folder/secure-file
ls: cannot open directory '/mnt/secure-folder/': Permission denied

4. del the user from the group
gpasswd -d user01 secure01

BUG2:
if user01 is already logged in or it has running tmux/screen sessions, he still
can access that group's /mnt/secure-folder/secure-file
user01@local:~$ cat /mnt/secure-folder/secure-file
yes


This bug is significant for a multi-user secure Linux environment. In a secure
network cluster, new data files are often dynamically added into the system
with new group permissions created, and some users are added into the group or
removed from the group depending on role change, task change, etc. However, the
changed permission does not reflect immediately on all the running processes
belonging to that user.

As a result, a user can have a persistent tmux/screen session (that does not go
away unless reboot) to continue to access group files he can access before,
even though his access permission has been revoked now.



-- System Information:
Debian Release: 10.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.57 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_CPU_OUT_OF_SPEC, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

[toc] | [next] | [standalone]

#1069588 — Bug#993488: maybe reason for wontfix?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a 
"wontfix + close" but no rationale. Which leaves the original reporter 
with a large "?" I guess.

I am guessing that the reason for the "wontfix" is "that's just how Unix 
works unfortunately" aka "that's a Unix design bug"? Is my guess correct?

One other question - any idea on a way forward here? I would guess that 
behaviour (changing group membership won't change group membership of 
running processes) is rooted somewhere quite low in the stack, maybe in 
the kernel itself (or in posix :-#)? So if the original reporter would 
want to go ahead and look to that problem beeing fixed would he need to go 
talk to the kernel mailing list or do you have idea where he could go 
to?
*t

[toc] | [prev] | [next] | [standalone]

#1069595 — Bug#993488: maybe reason for wontfix?

On 2021-09-03 14:23, Tomas Pospisek wrote:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993488#16 contains a
> "wontfix + close" but no rationale. Which leaves the original reporter
> with a large "?" I guess.
> 
> I am guessing that the reason for the "wontfix" is "that's just how
> Unix works unfortunately" aka "that's a Unix design bug"? Is my guess
> correct?
> 
> One other question - any idea on a way forward here? I would guess
> that behaviour (changing group membership won't change group
> membership of running processes) is rooted somewhere quite low in the
> stack, maybe in the kernel itself (or in posix :-#)? So if the
> original reporter would want to go ahead and look to that problem
> beeing fixed would he need to go talk to the kernel mailing list or do
> you have idea where he could go to?

Processes in *nix inherit permissions. That's inherent to the design. If 
you want more guarantees, you need to move from discretionary access 
control (based on the identity at the time of process (tree) creation) 
to mandatory access control (e.g. SELinux).

Kind regards
Philipp Kern

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web