question about selinux_restore_tty() in sudo's selinux.c

question about selinux_restore_tty() in sudo's selinux.c

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]

[1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
[2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: question about selinux_restore_tty() in sudo's selinux.c

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

On Fri, Sep 27, 2019 at 09:55:07AM +0200, Dominick Grift wrote:
> sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]
> 
> [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
> [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c

Does fgetfilecon() get the context from the actual path or does it get it from file_contexts?
If it does the latter then i guess that would explain it as pty/tty contexts are customizable and thus have no entry in file_contexts:

# matchpathcon /dev/pts/0
/dev/pts/0      <<none>>

In that case i guess it skips the relabel?

> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: question about selinux_restore_tty() in sudo's selinux.c

[Stephen Smalley]

On 9/27/19 3:55 AM, Dominick Grift wrote:
> sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]
> 
> [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
> [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c

Are you sure sudo is calling selinux_restore_tty()?

Re: question about selinux_restore_tty() in sudo's selinux.c

[Stephen Smalley]

On 9/27/19 4:24 AM, Dominick Grift wrote:
> On Fri, Sep 27, 2019 at 09:55:07AM +0200, Dominick Grift wrote:
>> sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]
>>
>> [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
>> [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
> 
> Does fgetfilecon() get the context from the actual path or does it get it from file_contexts?
> If it does the latter then i guess that would explain it as pty/tty contexts are customizable and thus have no entry in file_contexts:
> 
> # matchpathcon /dev/pts/0
> /dev/pts/0      <<none>>
> 
> In that case i guess it skips the relabel?

I don't think that's relevant.  fgetfilecon() is a wrapper for 
fgetxattr(2); it gets the actual context set on the file, not something 
from file_contexts (you would use selabel_lookup(3) or matchpathcon(3) 
for the latter).

The behavior you describe suggests that sudo is never calling 
selinux_restore_tty() in this case (or there is some bug causing it to 
abort before reaching the fsetfilecon, or causing that to fail).

Don't know if you can turn up verbosity/logging and/or use strace or 
autrace or something to get more info.

Re: question about selinux_restore_tty() in sudo's selinux.c

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
> On 9/27/19 3:55 AM, Dominick Grift wrote:
> > sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]
> > 
> > [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
> > [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
> 
> Are you sure sudo is calling selinux_restore_tty()?
> 
> 

running sudo with:

Debug sudo /var/log/sudo_debug all@debug
Debug sudoers.so /var/log/sudo_debug all@debug

Yields:

grep selinux /var/log/sudo_debug
Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @ ../../../lib/util/key_val.c:61 := selinux_role=sysadm.role
Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
Sep 27 15:06:29 sudo[3447] -> get_exec_context @ ../../src/selinux.c:274
Sep 27 15:06:29 sudo[3447] <- get_exec_context @ ../../src/selinux.c:328 := 0x564eed3621b0
Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
Sep 27 15:06:29 sudo[3447] <- relabel_tty @ ../../src/selinux.c:253 := 0
Sep 27 15:06:29 sudo[3447] -> audit_role_change @ ../../src/selinux.c:76
Sep 27 15:06:29 sudo[3447] <- audit_role_change @ ../../src/selinux.c:98 := 6
Sep 27 15:06:29 sudo[3447] <- selinux_setup @ ../../src/selinux.c:395 := 0
Sep 27 15:06:29 sudo[3447] -> selinux_execve @ ../../src/selinux.c:405
Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @ ../../src/selinux.c:114
Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @ ../../src/selinux.c:142 := 0

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: question about selinux_restore_tty() in sudo's selinux.c

[Stephen Smalley]

On 9/27/19 9:08 AM, Dominick Grift wrote:
> On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
>> On 9/27/19 3:55 AM, Dominick Grift wrote:
>>> sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]
>>>
>>> [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
>>> [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
>>
>> Are you sure sudo is calling selinux_restore_tty()?
>>
>>
> 
> running sudo with:
> 
> Debug sudo /var/log/sudo_debug all@debug
> Debug sudoers.so /var/log/sudo_debug all@debug
> 
> Yields:
> 
> grep selinux /var/log/sudo_debug
> Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @ ../../../lib/util/key_val.c:61 := selinux_role=sysadm.role
> Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
> Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
> Sep 27 15:06:29 sudo[3447] -> get_exec_context @ ../../src/selinux.c:274
> Sep 27 15:06:29 sudo[3447] <- get_exec_context @ ../../src/selinux.c:328 := 0x564eed3621b0
> Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
> Sep 27 15:06:29 sudo[3447] <- relabel_tty @ ../../src/selinux.c:253 := 0
> Sep 27 15:06:29 sudo[3447] -> audit_role_change @ ../../src/selinux.c:76
> Sep 27 15:06:29 sudo[3447] <- audit_role_change @ ../../src/selinux.c:98 := 6
> Sep 27 15:06:29 sudo[3447] <- selinux_setup @ ../../src/selinux.c:395 := 0
> Sep 27 15:06:29 sudo[3447] -> selinux_execve @ ../../src/selinux.c:405
> Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @ ../../src/selinux.c:114
> Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @ ../../src/selinux.c:142 := 0

Ok, so you entered and exited selinux_restore_tty() without error. No 
warning messages of any kind in any of the sudo logs? Not sure where 
sudo_warn() and sudo_warnx() messages go.

selinux_restore_tty() does a goto skip_relabel in multiple cases:
- if there was no tty (ttyfd == -1),
- if we didn't set a new tty context (new_tty_context),
- if the context on the tty was changed from the value set by sudo 
(strcmp...) e.g. some other process changed it in the interim, but this 
should have logged a warning,

Re: question about selinux_restore_tty() in sudo's selinux.c

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 2716 bytes --]

On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
> On 9/27/19 9:08 AM, Dominick Grift wrote:
> > On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
> > > On 9/27/19 3:55 AM, Dominick Grift wrote:
> > > > sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]
> > > > 
> > > > [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
> > > > [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
> > > 
> > > Are you sure sudo is calling selinux_restore_tty()?
> > > 
> > > 
> > 
> > running sudo with:
> > 
> > Debug sudo /var/log/sudo_debug all@debug
> > Debug sudoers.so /var/log/sudo_debug all@debug
> > 
> > Yields:
> > 
> > grep selinux /var/log/sudo_debug
> > Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @ ../../../lib/util/key_val.c:61 := selinux_role=sysadm.role
> > Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
> > Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
> > Sep 27 15:06:29 sudo[3447] -> get_exec_context @ ../../src/selinux.c:274
> > Sep 27 15:06:29 sudo[3447] <- get_exec_context @ ../../src/selinux.c:328 := 0x564eed3621b0
> > Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
> > Sep 27 15:06:29 sudo[3447] <- relabel_tty @ ../../src/selinux.c:253 := 0
> > Sep 27 15:06:29 sudo[3447] -> audit_role_change @ ../../src/selinux.c:76
> > Sep 27 15:06:29 sudo[3447] <- audit_role_change @ ../../src/selinux.c:98 := 6
> > Sep 27 15:06:29 sudo[3447] <- selinux_setup @ ../../src/selinux.c:395 := 0
> > Sep 27 15:06:29 sudo[3447] -> selinux_execve @ ../../src/selinux.c:405
> > Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @ ../../src/selinux.c:114
> > Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @ ../../src/selinux.c:142 := 0
> 
> Ok, so you entered and exited selinux_restore_tty() without error. No
> warning messages of any kind in any of the sudo logs? Not sure where
> sudo_warn() and sudo_warnx() messages go.

No warnings or any other clues. I guess it must be this then:

    if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
	goto skip_relabel;

> 
> selinux_restore_tty() does a goto skip_relabel in multiple cases:
> - if there was no tty (ttyfd == -1),
> - if we didn't set a new tty context (new_tty_context),
> - if the context on the tty was changed from the value set by sudo
> (strcmp...) e.g. some other process changed it in the interim, but this
> should have logged a warning,
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: question about selinux_restore_tty() in sudo's selinux.c

[Stephen Smalley]

On 9/27/19 9:49 AM, Dominick Grift wrote:
> On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
>> On 9/27/19 9:08 AM, Dominick Grift wrote:
>>> On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
>>>> On 9/27/19 3:55 AM, Dominick Grift wrote:
>>>>> sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]
>>>>>
>>>>> [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
>>>>> [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
>>>>
>>>> Are you sure sudo is calling selinux_restore_tty()?
>>>>
>>>>
>>>
>>> running sudo with:
>>>
>>> Debug sudo /var/log/sudo_debug all@debug
>>> Debug sudoers.so /var/log/sudo_debug all@debug
>>>
>>> Yields:
>>>
>>> grep selinux /var/log/sudo_debug
>>> Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @ ../../../lib/util/key_val.c:61 := selinux_role=sysadm.role
>>> Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
>>> Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
>>> Sep 27 15:06:29 sudo[3447] -> get_exec_context @ ../../src/selinux.c:274
>>> Sep 27 15:06:29 sudo[3447] <- get_exec_context @ ../../src/selinux.c:328 := 0x564eed3621b0
>>> Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
>>> Sep 27 15:06:29 sudo[3447] <- relabel_tty @ ../../src/selinux.c:253 := 0
>>> Sep 27 15:06:29 sudo[3447] -> audit_role_change @ ../../src/selinux.c:76
>>> Sep 27 15:06:29 sudo[3447] <- audit_role_change @ ../../src/selinux.c:98 := 6
>>> Sep 27 15:06:29 sudo[3447] <- selinux_setup @ ../../src/selinux.c:395 := 0
>>> Sep 27 15:06:29 sudo[3447] -> selinux_execve @ ../../src/selinux.c:405
>>> Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @ ../../src/selinux.c:114
>>> Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @ ../../src/selinux.c:142 := 0
>>
>> Ok, so you entered and exited selinux_restore_tty() without error. No
>> warning messages of any kind in any of the sudo logs? Not sure where
>> sudo_warn() and sudo_warnx() messages go.
> 
> No warnings or any other clues. I guess it must be this then:
> 
>      if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
> 	goto skip_relabel;

That should only occur if there was no tty or security_compute_relabel() 
didn't provide a new context to set in the first place. Not if it 
actually relabeled the tty earlier.

Does newrole work correctly with your policy?

> 
>>
>> selinux_restore_tty() does a goto skip_relabel in multiple cases:
>> - if there was no tty (ttyfd == -1),
>> - if we didn't set a new tty context (new_tty_context),
>> - if the context on the tty was changed from the value set by sudo
>> (strcmp...) e.g. some other process changed it in the interim, but this
>> should have logged a warning,
>>

Re: question about selinux_restore_tty() in sudo's selinux.c

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 4199 bytes --]

On Fri, Sep 27, 2019 at 09:51:26AM -0400, Stephen Smalley wrote:
> On 9/27/19 9:49 AM, Dominick Grift wrote:
> > On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
> > > On 9/27/19 9:08 AM, Dominick Grift wrote:
> > > > On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
> > > > > On 9/27/19 3:55 AM, Dominick Grift wrote:
> > > > > > sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]
> > > > > > 
> > > > > > [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
> > > > > > [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
> > > > > 
> > > > > Are you sure sudo is calling selinux_restore_tty()?
> > > > > 
> > > > > 
> > > > 
> > > > running sudo with:
> > > > 
> > > > Debug sudo /var/log/sudo_debug all@debug
> > > > Debug sudoers.so /var/log/sudo_debug all@debug
> > > > 
> > > > Yields:
> > > > 
> > > > grep selinux /var/log/sudo_debug
> > > > Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @ ../../../lib/util/key_val.c:61 := selinux_role=sysadm.role
> > > > Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
> > > > Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
> > > > Sep 27 15:06:29 sudo[3447] -> get_exec_context @ ../../src/selinux.c:274
> > > > Sep 27 15:06:29 sudo[3447] <- get_exec_context @ ../../src/selinux.c:328 := 0x564eed3621b0
> > > > Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
> > > > Sep 27 15:06:29 sudo[3447] <- relabel_tty @ ../../src/selinux.c:253 := 0
> > > > Sep 27 15:06:29 sudo[3447] -> audit_role_change @ ../../src/selinux.c:76
> > > > Sep 27 15:06:29 sudo[3447] <- audit_role_change @ ../../src/selinux.c:98 := 6
> > > > Sep 27 15:06:29 sudo[3447] <- selinux_setup @ ../../src/selinux.c:395 := 0
> > > > Sep 27 15:06:29 sudo[3447] -> selinux_execve @ ../../src/selinux.c:405
> > > > Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @ ../../src/selinux.c:114
> > > > Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @ ../../src/selinux.c:142 := 0
> > > 
> > > Ok, so you entered and exited selinux_restore_tty() without error. No
> > > warning messages of any kind in any of the sudo logs? Not sure where
> > > sudo_warn() and sudo_warnx() messages go.
> > 
> > No warnings or any other clues. I guess it must be this then:
> > 
> >      if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
> > 	goto skip_relabel;
> 
> That should only occur if there was no tty or security_compute_relabel()
> didn't provide a new context to set in the first place. Not if it actually
> relabeled the tty earlier.
> 
> Does newrole work correctly with your policy?

Yes:

kcinimod@seamus:~$ id -Z
wheel.id:wheel.role:wheel.subj:s0
kcinimod@seamus:~$ ls -alZ `tty`
crw--w----. 1 kcinimod tty wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 15:55 /dev/pts/10
kcinimod@seamus:~$ newrole -r sysadm.role
Password: 
newrole: incorrect password for kcinimod
kcinimod@seamus:~$ ls -alZ `tty`
crw--w----. 1 kcinimod tty wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 15:56 /dev/pts/10
kcinimod@seamus:~$ newrole -r sysadm.role
Password: 
kcinimod@seamus:~$ id -Z
wheel.id:sysadm.role:sysadm.subj:s0
kcinimod@seamus:~$ ls -alZ `tty`
crw--w----. 1 kcinimod tty wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 15:56 /dev/pts/10
kcinimod@seamus:~$ exit
logout
kcinimod@seamus:~$ ls -alZ `tty`
crw--w----. 1 kcinimod tty wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 15:56 /dev/pts/10

> 
> > 
> > > 
> > > selinux_restore_tty() does a goto skip_relabel in multiple cases:
> > > - if there was no tty (ttyfd == -1),
> > > - if we didn't set a new tty context (new_tty_context),
> > > - if the context on the tty was changed from the value set by sudo
> > > (strcmp...) e.g. some other process changed it in the interim, but this
> > > should have logged a warning,
> > > 
> 
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: question about selinux_restore_tty() in sudo's selinux.c

[Stephen Smalley]

On 9/27/19 9:57 AM, Dominick Grift wrote:
> On Fri, Sep 27, 2019 at 09:51:26AM -0400, Stephen Smalley wrote:
>> On 9/27/19 9:49 AM, Dominick Grift wrote:
>>> On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
>>>> On 9/27/19 9:08 AM, Dominick Grift wrote:
>>>>> On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
>>>>>> On 9/27/19 3:55 AM, Dominick Grift wrote:
>>>>>>> sudo does not reset the role of my tty properly [1], and i was wondering if anyone is able to determine what is causing this [2]
>>>>>>>
>>>>>>> [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
>>>>>>> [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
>>>>>>
>>>>>> Are you sure sudo is calling selinux_restore_tty()?
>>>>>>
>>>>>>
>>>>>
>>>>> running sudo with:
>>>>>
>>>>> Debug sudo /var/log/sudo_debug all@debug
>>>>> Debug sudoers.so /var/log/sudo_debug all@debug
>>>>>
>>>>> Yields:
>>>>>
>>>>> grep selinux /var/log/sudo_debug
>>>>> Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @ ../../../lib/util/key_val.c:61 := selinux_role=sysadm.role
>>>>> Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
>>>>> Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
>>>>> Sep 27 15:06:29 sudo[3447] -> get_exec_context @ ../../src/selinux.c:274
>>>>> Sep 27 15:06:29 sudo[3447] <- get_exec_context @ ../../src/selinux.c:328 := 0x564eed3621b0
>>>>> Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
>>>>> Sep 27 15:06:29 sudo[3447] <- relabel_tty @ ../../src/selinux.c:253 := 0
>>>>> Sep 27 15:06:29 sudo[3447] -> audit_role_change @ ../../src/selinux.c:76
>>>>> Sep 27 15:06:29 sudo[3447] <- audit_role_change @ ../../src/selinux.c:98 := 6
>>>>> Sep 27 15:06:29 sudo[3447] <- selinux_setup @ ../../src/selinux.c:395 := 0
>>>>> Sep 27 15:06:29 sudo[3447] -> selinux_execve @ ../../src/selinux.c:405
>>>>> Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @ ../../src/selinux.c:114
>>>>> Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @ ../../src/selinux.c:142 := 0
>>>>
>>>> Ok, so you entered and exited selinux_restore_tty() without error. No
>>>> warning messages of any kind in any of the sudo logs? Not sure where
>>>> sudo_warn() and sudo_warnx() messages go.
>>>
>>> No warnings or any other clues. I guess it must be this then:
>>>
>>>       if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
>>> 	goto skip_relabel;
>>
>> That should only occur if there was no tty or security_compute_relabel()
>> didn't provide a new context to set in the first place. Not if it actually
>> relabeled the tty earlier.
>>
>> Does newrole work correctly with your policy?
> 
> Yes:
> 
> kcinimod@seamus:~$ id -Z
> wheel.id:wheel.role:wheel.subj:s0
> kcinimod@seamus:~$ ls -alZ `tty`
> crw--w----. 1 kcinimod tty wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 15:55 /dev/pts/10
> kcinimod@seamus:~$ newrole -r sysadm.role
> Password:
> newrole: incorrect password for kcinimod
> kcinimod@seamus:~$ ls -alZ `tty`
> crw--w----. 1 kcinimod tty wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 15:56 /dev/pts/10
> kcinimod@seamus:~$ newrole -r sysadm.role
> Password:
> kcinimod@seamus:~$ id -Z
> wheel.id:sysadm.role:sysadm.subj:s0
> kcinimod@seamus:~$ ls -alZ `tty`
> crw--w----. 1 kcinimod tty wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 15:56 /dev/pts/10
> kcinimod@seamus:~$ exit
> logout
> kcinimod@seamus:~$ ls -alZ `tty`
> crw--w----. 1 kcinimod tty wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 15:56 /dev/pts/10

Ok, so at least we know it is a bug in the sudo code somewhere.  I'd 
assume that for some reason ttyfd or new_tty_context are either not 
being set in the first place or are being unset somewhere?

Re: question about selinux_restore_tty() in sudo's selinux.c

[Stephen Smalley]

On 9/27/19 10:01 AM, Stephen Smalley wrote:
> On 9/27/19 9:57 AM, Dominick Grift wrote:
>> On Fri, Sep 27, 2019 at 09:51:26AM -0400, Stephen Smalley wrote:
>>> On 9/27/19 9:49 AM, Dominick Grift wrote:
>>>> On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
>>>>> On 9/27/19 9:08 AM, Dominick Grift wrote:
>>>>>> On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
>>>>>>> On 9/27/19 3:55 AM, Dominick Grift wrote:
>>>>>>>> sudo does not reset the role of my tty properly [1], and i was 
>>>>>>>> wondering if anyone is able to determine what is causing this [2]
>>>>>>>>
>>>>>>>> [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
>>>>>>>> [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
>>>>>>>
>>>>>>> Are you sure sudo is calling selinux_restore_tty()?
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> running sudo with:
>>>>>>
>>>>>> Debug sudo /var/log/sudo_debug all@debug
>>>>>> Debug sudoers.so /var/log/sudo_debug all@debug
>>>>>>
>>>>>> Yields:
>>>>>>
>>>>>> grep selinux /var/log/sudo_debug
>>>>>> Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @ 
>>>>>> ../../../lib/util/key_val.c:61 := selinux_role=sysadm.role
>>>>>> Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
>>>>>> Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
>>>>>> Sep 27 15:06:29 sudo[3447] -> get_exec_context @ 
>>>>>> ../../src/selinux.c:274
>>>>>> Sep 27 15:06:29 sudo[3447] <- get_exec_context @ 
>>>>>> ../../src/selinux.c:328 := 0x564eed3621b0
>>>>>> Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
>>>>>> Sep 27 15:06:29 sudo[3447] <- relabel_tty @ 
>>>>>> ../../src/selinux.c:253 := 0
>>>>>> Sep 27 15:06:29 sudo[3447] -> audit_role_change @ 
>>>>>> ../../src/selinux.c:76
>>>>>> Sep 27 15:06:29 sudo[3447] <- audit_role_change @ 
>>>>>> ../../src/selinux.c:98 := 6
>>>>>> Sep 27 15:06:29 sudo[3447] <- selinux_setup @ 
>>>>>> ../../src/selinux.c:395 := 0
>>>>>> Sep 27 15:06:29 sudo[3447] -> selinux_execve @ 
>>>>>> ../../src/selinux.c:405
>>>>>> Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @ 
>>>>>> ../../src/selinux.c:114
>>>>>> Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @ 
>>>>>> ../../src/selinux.c:142 := 0
>>>>>
>>>>> Ok, so you entered and exited selinux_restore_tty() without error. No
>>>>> warning messages of any kind in any of the sudo logs? Not sure where
>>>>> sudo_warn() and sudo_warnx() messages go.
>>>>
>>>> No warnings or any other clues. I guess it must be this then:
>>>>
>>>>       if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
>>>>     goto skip_relabel;
>>>
>>> That should only occur if there was no tty or security_compute_relabel()
>>> didn't provide a new context to set in the first place. Not if it 
>>> actually
>>> relabeled the tty earlier.
>>>
>>> Does newrole work correctly with your policy?
>>
>> Yes:
>>
>> kcinimod@seamus:~$ id -Z
>> wheel.id:wheel.role:wheel.subj:s0
>> kcinimod@seamus:~$ ls -alZ `tty`
>> crw--w----. 1 kcinimod tty 
>> wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 
>> 15:55 /dev/pts/10
>> kcinimod@seamus:~$ newrole -r sysadm.role
>> Password:
>> newrole: incorrect password for kcinimod
>> kcinimod@seamus:~$ ls -alZ `tty`
>> crw--w----. 1 kcinimod tty 
>> wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 
>> 15:56 /dev/pts/10
>> kcinimod@seamus:~$ newrole -r sysadm.role
>> Password:
>> kcinimod@seamus:~$ id -Z
>> wheel.id:sysadm.role:sysadm.subj:s0
>> kcinimod@seamus:~$ ls -alZ `tty`
>> crw--w----. 1 kcinimod tty 
>> wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 
>> 15:56 /dev/pts/10
>> kcinimod@seamus:~$ exit
>> logout
>> kcinimod@seamus:~$ ls -alZ `tty`
>> crw--w----. 1 kcinimod tty 
>> wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27 
>> 15:56 /dev/pts/10
> 
> Ok, so at least we know it is a bug in the sudo code somewhere.  I'd 
> assume that for some reason ttyfd or new_tty_context are either not 
> being set in the first place or are being unset somewhere?

Can you provide your sudo package version so I can be sure I'm looking 
at the right sources?  The line numbers in your debug output don't quite 
align with the current upstream.

Re: question about selinux_restore_tty() in sudo's selinux.c

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 6219 bytes --]

On Fri, Sep 27, 2019 at 10:17:16AM -0400, Stephen Smalley wrote:
> On 9/27/19 10:01 AM, Stephen Smalley wrote:
> > On 9/27/19 9:57 AM, Dominick Grift wrote:
> > > On Fri, Sep 27, 2019 at 09:51:26AM -0400, Stephen Smalley wrote:
> > > > On 9/27/19 9:49 AM, Dominick Grift wrote:
> > > > > On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
> > > > > > On 9/27/19 9:08 AM, Dominick Grift wrote:
> > > > > > > On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
> > > > > > > > On 9/27/19 3:55 AM, Dominick Grift wrote:
> > > > > > > > > sudo does not reset the role of my tty
> > > > > > > > > properly [1], and i was wondering if anyone
> > > > > > > > > is able to determine what is causing this
> > > > > > > > > [2]
> > > > > > > > > 
> > > > > > > > > [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
> > > > > > > > > [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
> > > > > > > > 
> > > > > > > > Are you sure sudo is calling selinux_restore_tty()?
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > running sudo with:
> > > > > > > 
> > > > > > > Debug sudo /var/log/sudo_debug all@debug
> > > > > > > Debug sudoers.so /var/log/sudo_debug all@debug
> > > > > > > 
> > > > > > > Yields:
> > > > > > > 
> > > > > > > grep selinux /var/log/sudo_debug
> > > > > > > Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @
> > > > > > > ../../../lib/util/key_val.c:61 :=
> > > > > > > selinux_role=sysadm.role
> > > > > > > Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
> > > > > > > Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
> > > > > > > Sep 27 15:06:29 sudo[3447] -> get_exec_context @
> > > > > > > ../../src/selinux.c:274
> > > > > > > Sep 27 15:06:29 sudo[3447] <- get_exec_context @
> > > > > > > ../../src/selinux.c:328 := 0x564eed3621b0
> > > > > > > Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
> > > > > > > Sep 27 15:06:29 sudo[3447] <- relabel_tty @
> > > > > > > ../../src/selinux.c:253 := 0
> > > > > > > Sep 27 15:06:29 sudo[3447] -> audit_role_change @
> > > > > > > ../../src/selinux.c:76
> > > > > > > Sep 27 15:06:29 sudo[3447] <- audit_role_change @
> > > > > > > ../../src/selinux.c:98 := 6
> > > > > > > Sep 27 15:06:29 sudo[3447] <- selinux_setup @
> > > > > > > ../../src/selinux.c:395 := 0
> > > > > > > Sep 27 15:06:29 sudo[3447] -> selinux_execve @
> > > > > > > ../../src/selinux.c:405
> > > > > > > Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @
> > > > > > > ../../src/selinux.c:114
> > > > > > > Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @
> > > > > > > ../../src/selinux.c:142 := 0
> > > > > > 
> > > > > > Ok, so you entered and exited selinux_restore_tty() without error. No
> > > > > > warning messages of any kind in any of the sudo logs? Not sure where
> > > > > > sudo_warn() and sudo_warnx() messages go.
> > > > > 
> > > > > No warnings or any other clues. I guess it must be this then:
> > > > > 
> > > > >       if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
> > > > >     goto skip_relabel;
> > > > 
> > > > That should only occur if there was no tty or security_compute_relabel()
> > > > didn't provide a new context to set in the first place. Not if
> > > > it actually
> > > > relabeled the tty earlier.
> > > > 
> > > > Does newrole work correctly with your policy?
> > > 
> > > Yes:
> > > 
> > > kcinimod@seamus:~$ id -Z
> > > wheel.id:wheel.role:wheel.subj:s0
> > > kcinimod@seamus:~$ ls -alZ `tty`
> > > crw--w----. 1 kcinimod tty
> > > wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > 15:55 /dev/pts/10
> > > kcinimod@seamus:~$ newrole -r sysadm.role
> > > Password:
> > > newrole: incorrect password for kcinimod
> > > kcinimod@seamus:~$ ls -alZ `tty`
> > > crw--w----. 1 kcinimod tty
> > > wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > 15:56 /dev/pts/10
> > > kcinimod@seamus:~$ newrole -r sysadm.role
> > > Password:
> > > kcinimod@seamus:~$ id -Z
> > > wheel.id:sysadm.role:sysadm.subj:s0
> > > kcinimod@seamus:~$ ls -alZ `tty`
> > > crw--w----. 1 kcinimod tty
> > > wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > 15:56 /dev/pts/10
> > > kcinimod@seamus:~$ exit
> > > logout
> > > kcinimod@seamus:~$ ls -alZ `tty`
> > > crw--w----. 1 kcinimod tty
> > > wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > 15:56 /dev/pts/10
> > 
> > Ok, so at least we know it is a bug in the sudo code somewhere.  I'd
> > assume that for some reason ttyfd or new_tty_context are either not
> > being set in the first place or are being unset somewhere?
> 
> Can you provide your sudo package version so I can be sure I'm looking at
> the right sources?  The line numbers in your debug output don't quite align
> with the current upstream.

root@seamus:~# apt info sudo
Package: sudo
Version: 1.8.27-1+b1
Priority: optional
Section: admin
Source: sudo (1.8.27-1)
Maintainer: Bdale Garbee <bdale@gag.com>
Installed-Size: 3,879 kB
Depends: libaudit1 (>= 1:2.2.1), libc6 (>= 2.27), libpam0g (>= 0.99.7.1), libselinux1 (>= 1.32), libpam-modules, lsb-base
Conflicts: sudo-ldap
Replaces: sudo-ldap
Homepage: http://www.sudo.ws/
Tag: admin::login, admin::user-management, implemented-in::c,
 interface::commandline, role::program, scope::utility,
 security::authentication, use::login
Download-Size: 1,244 kB
APT-Manual-Installed: yes
APT-Sources: http://mirror.nl.leaseweb.net/debian sid/main amd64 Packages
Description: Provide limited super user privileges to specific users
 Sudo is a program designed to allow a sysadmin to give limited root
 privileges to users and log root activity.  The basic philosophy is to give
 as few privileges as possible but still allow people to get their work done.
 .
 This version is built with minimal shared library dependencies, use the
 sudo-ldap package instead if you need LDAP support for sudoers.

> 
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: question about selinux_restore_tty() in sudo's selinux.c

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 15110 bytes --]

On Fri, Sep 27, 2019 at 04:28:35PM +0200, Dominick Grift wrote:
> On Fri, Sep 27, 2019 at 10:17:16AM -0400, Stephen Smalley wrote:
> > On 9/27/19 10:01 AM, Stephen Smalley wrote:
> > > On 9/27/19 9:57 AM, Dominick Grift wrote:
> > > > On Fri, Sep 27, 2019 at 09:51:26AM -0400, Stephen Smalley wrote:
> > > > > On 9/27/19 9:49 AM, Dominick Grift wrote:
> > > > > > On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
> > > > > > > On 9/27/19 9:08 AM, Dominick Grift wrote:
> > > > > > > > On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
> > > > > > > > > On 9/27/19 3:55 AM, Dominick Grift wrote:
> > > > > > > > > > sudo does not reset the role of my tty
> > > > > > > > > > properly [1], and i was wondering if anyone
> > > > > > > > > > is able to determine what is causing this
> > > > > > > > > > [2]
> > > > > > > > > > 
> > > > > > > > > > [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
> > > > > > > > > > [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
> > > > > > > > > 
> > > > > > > > > Are you sure sudo is calling selinux_restore_tty()?
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > running sudo with:
> > > > > > > > 
> > > > > > > > Debug sudo /var/log/sudo_debug all@debug
> > > > > > > > Debug sudoers.so /var/log/sudo_debug all@debug
> > > > > > > > 
> > > > > > > > Yields:
> > > > > > > > 
> > > > > > > > grep selinux /var/log/sudo_debug
> > > > > > > > Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @
> > > > > > > > ../../../lib/util/key_val.c:61 :=
> > > > > > > > selinux_role=sysadm.role
> > > > > > > > Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
> > > > > > > > Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
> > > > > > > > Sep 27 15:06:29 sudo[3447] -> get_exec_context @
> > > > > > > > ../../src/selinux.c:274
> > > > > > > > Sep 27 15:06:29 sudo[3447] <- get_exec_context @
> > > > > > > > ../../src/selinux.c:328 := 0x564eed3621b0
> > > > > > > > Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
> > > > > > > > Sep 27 15:06:29 sudo[3447] <- relabel_tty @
> > > > > > > > ../../src/selinux.c:253 := 0
> > > > > > > > Sep 27 15:06:29 sudo[3447] -> audit_role_change @
> > > > > > > > ../../src/selinux.c:76
> > > > > > > > Sep 27 15:06:29 sudo[3447] <- audit_role_change @
> > > > > > > > ../../src/selinux.c:98 := 6
> > > > > > > > Sep 27 15:06:29 sudo[3447] <- selinux_setup @
> > > > > > > > ../../src/selinux.c:395 := 0
> > > > > > > > Sep 27 15:06:29 sudo[3447] -> selinux_execve @
> > > > > > > > ../../src/selinux.c:405
> > > > > > > > Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @
> > > > > > > > ../../src/selinux.c:114
> > > > > > > > Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @
> > > > > > > > ../../src/selinux.c:142 := 0
> > > > > > > 
> > > > > > > Ok, so you entered and exited selinux_restore_tty() without error. No
> > > > > > > warning messages of any kind in any of the sudo logs? Not sure where
> > > > > > > sudo_warn() and sudo_warnx() messages go.
> > > > > > 
> > > > > > No warnings or any other clues. I guess it must be this then:
> > > > > > 
> > > > > >       if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
> > > > > >     goto skip_relabel;
> > > > > 
> > > > > That should only occur if there was no tty or security_compute_relabel()
> > > > > didn't provide a new context to set in the first place. Not if
> > > > > it actually
> > > > > relabeled the tty earlier.
> > > > > 
> > > > > Does newrole work correctly with your policy?
> > > > 
> > > > Yes:
> > > > 
> > > > kcinimod@seamus:~$ id -Z
> > > > wheel.id:wheel.role:wheel.subj:s0
> > > > kcinimod@seamus:~$ ls -alZ `tty`
> > > > crw--w----. 1 kcinimod tty
> > > > wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > > 15:55 /dev/pts/10
> > > > kcinimod@seamus:~$ newrole -r sysadm.role
> > > > Password:
> > > > newrole: incorrect password for kcinimod
> > > > kcinimod@seamus:~$ ls -alZ `tty`
> > > > crw--w----. 1 kcinimod tty
> > > > wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > > 15:56 /dev/pts/10
> > > > kcinimod@seamus:~$ newrole -r sysadm.role
> > > > Password:
> > > > kcinimod@seamus:~$ id -Z
> > > > wheel.id:sysadm.role:sysadm.subj:s0
> > > > kcinimod@seamus:~$ ls -alZ `tty`
> > > > crw--w----. 1 kcinimod tty
> > > > wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > > 15:56 /dev/pts/10
> > > > kcinimod@seamus:~$ exit
> > > > logout
> > > > kcinimod@seamus:~$ ls -alZ `tty`
> > > > crw--w----. 1 kcinimod tty
> > > > wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > > 15:56 /dev/pts/10
> > > 
> > > Ok, so at least we know it is a bug in the sudo code somewhere.  I'd
> > > assume that for some reason ttyfd or new_tty_context are either not
> > > being set in the first place or are being unset somewhere?
> > 
> > Can you provide your sudo package version so I can be sure I'm looking at
> > the right sources?  The line numbers in your debug output don't quite align
> > with the current upstream.
> 
> root@seamus:~# apt info sudo
> Package: sudo
> Version: 1.8.27-1+b1
> Priority: optional
> Section: admin
> Source: sudo (1.8.27-1)
> Maintainer: Bdale Garbee <bdale@gag.com>
> Installed-Size: 3,879 kB
> Depends: libaudit1 (>= 1:2.2.1), libc6 (>= 2.27), libpam0g (>= 0.99.7.1), libselinux1 (>= 1.32), libpam-modules, lsb-base
> Conflicts: sudo-ldap
> Replaces: sudo-ldap
> Homepage: http://www.sudo.ws/
> Tag: admin::login, admin::user-management, implemented-in::c,
>  interface::commandline, role::program, scope::utility,
>  security::authentication, use::login
> Download-Size: 1,244 kB
> APT-Manual-Installed: yes
> APT-Sources: http://mirror.nl.leaseweb.net/debian sid/main amd64 Packages
> Description: Provide limited super user privileges to specific users
>  Sudo is a program designed to allow a sysadmin to give limited root
>  privileges to users and log root activity.  The basic philosophy is to give
>  as few privileges as possible but still allow people to get their work done.
>  .
>  This version is built with minimal shared library dependencies, use the
>  sudo-ldap package instead if you need LDAP support for sudoers.
> 
> > 
> > 


this is on fedora:

sudo-1.8.27-3.fc31.x86_64

[kcinimod@agnus ~]$ id -Z
wheel.id:wheel.role:wheel.subj:s0
[kcinimod@agnus ~]$ ls -alZ `tty`
crw--w----. 1 kcinimod tty wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 0 Sep 27 16:30 /dev/pts/0
[kcinimod@agnus ~]$ sudo id -Z
wheel.id:sysadm.role:sysadm.subj:s0
[kcinimod@agnus ~]$ ls -alZ `tty`
crw--w----. 1 kcinimod tty wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 136, 0 Sep 27 16:31 /dev/pts/0
[kcinimod@agnus ~]$ sudo grep selinux /var/lib/sudo_debug
/usr/bin/grep: /var/lib/sudo_debug: No such file or directory
[kcinimod@agnus ~]$ sudo grep selinux /var/log/sudo_debug
Sep 27 16:31:06 sudo[68151] <- sudo_new_key_val_v1 @ ./key_val.c:61 := selinux_role=sysadm.role
Sep 27 16:31:06 sudo[68151]     7: selinux_role=sysadm.role
Sep 27 16:31:06 sudo[68158] -> selinux_setup @ ./selinux.c:349
Sep 27 16:31:06 sudo[68158] -> get_exec_context @ ./selinux.c:274
Sep 27 16:31:06 sudo[68158] <- get_exec_context @ ./selinux.c:328 := 0x561fecaca550
Sep 27 16:31:06 sudo[68158] -> relabel_tty @ ./selinux.c:160
Sep 27 16:31:06 sudo[68158] <- relabel_tty @ ./selinux.c:253 := 0
Sep 27 16:31:06 sudo[68158] -> audit_role_change @ ./selinux.c:76
Sep 27 16:31:06 sudo[68158] <- audit_role_change @ ./selinux.c:98 := 6
Sep 27 16:31:06 sudo[68158] <- selinux_setup @ ./selinux.c:395 := 0
Sep 27 16:31:06 sudo[68158] -> selinux_execve @ ./selinux.c:405
Sep 27 16:31:06 sudo[68151] -> selinux_restore_tty @ ./selinux.c:114
Sep 27 16:31:06 sudo[68151] <- selinux_restore_tty @ ./selinux.c:142 := 0
Sep 27 16:31:23 sudo[68191] sudo_putenv: SUDO_COMMAND=/usr/bin/grep selinux /var/lib/sudo_debug
Sep 27 16:31:23 sudo[68191] <- new_logline @ ./logging.c:1034 := TTY=pts/0 ; PWD=/home/kcinimod ; USER=root ; COMMAND=/usr/bin/grep selinux /var/lib/sudo_debug
Sep 27 16:31:23 sudo[68191] <- sudo_new_key_val_v1 @ ./key_val.c:61 := selinux_role=sysadm.role
Sep 27 16:31:23 sudo[68191]     7: selinux_role=sysadm.role
Sep 27 16:31:23 sudo[68194] -> selinux_setup @ ./selinux.c:349
Sep 27 16:31:23 sudo[68194] -> get_exec_context @ ./selinux.c:274
Sep 27 16:31:23 sudo[68194] <- get_exec_context @ ./selinux.c:328 := 0x55ec736b3430
Sep 27 16:31:23 sudo[68194] -> relabel_tty @ ./selinux.c:160
Sep 27 16:31:23 sudo[68194] <- relabel_tty @ ./selinux.c:253 := 0
Sep 27 16:31:23 sudo[68194] -> audit_role_change @ ./selinux.c:76
Sep 27 16:31:23 sudo[68194] <- audit_role_change @ ./selinux.c:98 := 5
Sep 27 16:31:23 sudo[68194] <- selinux_setup @ ./selinux.c:395 := 0
Sep 27 16:31:23 sudo[68194] -> selinux_execve @ ./selinux.c:405
Sep 27 16:31:23 sudo[68194] exec /usr/libexec/sudo/sesh [sesh /usr/bin/grep selinux /var/lib/sudo_debug] [HISTSIZE=1000 HOSTNAME=agnus SSH_AUTH_SOCK=/run/user/9999/gnupg/S.gpg-agent.ssh LANG=en_US.UTF-8 LS_COLORS=di=38;5;33:ln=38;5;14:pi=38;5;11;40:so=38;5;13:bd=38;5;11;48;5;232:cd=33;48;5;232:or=38;5;196;48;5;232:mi=1;5;37;41:su=38;5;231;48;5;196:sg=38;5;16;48;5;226:ca=38;5;226;48;5;196:tw=38;5;16;48;5;40:ow=38;5;21;48;5;40:st=38;5;231;48;5;21:ex=38;5;40:*.nuv=38;5;13:*.m4v=38;5;13:*.ogv=38;5;13:*.rpm=38;5;9:*.tz=38;5;9:*.pbm=38;5;13:*.rm=38;5;13:*.svg=38;5;13:*.tiff=38;5;13:*.xpm=38;5;13:*.m4a=38;5;45:*.cab=38;5;9:*.ogm=38;5;13:*.arj=38;5;9:*.mpg=38;5;13:*.ppm=38;5;13:*.zip=38;5;9:*.rz=38;5;9:*.ogx=38;5;13:*.fli=38;5;13:*.rar=38;5;9:*.pgm=38;5;13:*.deb=38;5;9:*.dwm=38;5;9:*.bz2=38;5;9:*.mid=38;5;45:*.alz=38;5;9:*.xspf=38;5;45:*.tgz=38;5;9:*.t7z=38;5;9:*.taz=38;5;9:*.zst=38;5;9:*.lz=38;5;9:*.avi=38;5;13:*.webm=38;5;13:*.au=38;5;45:*.bz=38;5;9:*.flac=38;5;45:*.lz4=38;5;9:*.tzo=38;5;9:*.ogg=38;5;45:*.yuv=38;5;13:*.lzo=38;5;9:*.xbm=38;5;13:*.mng=38;5;13:*.xcf=38;5;13:*.z=38;5;9:*.mjpeg=38;5;13:*.ace=38;5;9:*.midi=38;5;45:*.lha=38;5;9:*.war=38;5;9:*.mpeg=38;5;13:*.Z=38;5;9:*.dz=38;5;9:*.aac=38;5;45:*.mp4v=38;5;13:*.tif=38;5;13:*.wim=38;5;9:*.lzma=38;5;9:*.opus=38;5;45:*.oga=38;5;45:*.wav=38;5;45:*.tzst=38;5;9:*.arc=38;5;9:*.tlz=38;5;9:*.zoo=38;5;9:*.esd=38;5;9:*.rmvb=38;5;13:*.tar=38;5;9:*.mp4=38;5;13:*.mka=38;5;45:*.tga=38;5;13:*.spx=38;5;45:*.jar=38;5;9:*.7z=38;5;9:*.flc=38;5;13:*.sar=38;5;9:*.png=38;5;13:*.dl=38;5;13:*.gz=38;5;9:*.cpio=38;5;9:*.mjpg=38;5;13:*.gif=38;5;13:*.emf=38;5;13:*.asf=38;5;13:*.qt=38;5;13:*.xwd=38;5;13:*.mpc=38;5;45:*.lzh=38;5;9:*.ear=38;5;9:*.m2v=38;5;13:*.vob=38;5;13:*.flv=38;5;13:*.ra=38;5;45:*.mkv=38;5;13:*.svgz=38;5;13:*.mov=38;5;13:*.swm=38;5;9:*.txz=38;5;9:*.pcx=38;5;13:*.gl=38;5;13:*.lrz=38;5;9:*.wmv=38;5;13:*.bmp=38;5;13:*.cgm=38;5;13:*.tbz2=38;5;9:*.xz=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.mp3=38;5;45:*.tbz=38;5;9: TERM=xterm-256color PS1=[\u@\h \W$(__git_ps1 " (%s)")]\$  MAIL=/var/spool/mail/kcinimod PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LOGNAME=root USER=root HOME=/root SHELL=/bin/bash SUDO_COMMAND=/usr/bin/grep selinux /var/lib/sudo_debug SUDO_USER=kcinimod SUDO_UID=9999 SUDO_GID=9999]
Sep 27 16:31:23 sudo[68191] -> selinux_restore_tty @ ./selinux.c:114
Sep 27 16:31:23 sudo[68191] <- selinux_restore_tty @ ./selinux.c:142 := 0
Sep 27 16:31:29 sudo[68211] sudo_putenv: SUDO_COMMAND=/usr/bin/grep selinux /var/log/sudo_debug
Sep 27 16:31:29 sudo[68211] <- new_logline @ ./logging.c:1034 := TTY=pts/0 ; PWD=/home/kcinimod ; USER=root ; COMMAND=/usr/bin/grep selinux /var/log/sudo_debug
Sep 27 16:31:29 sudo[68211] <- sudo_new_key_val_v1 @ ./key_val.c:61 := selinux_role=sysadm.role
Sep 27 16:31:29 sudo[68211]     7: selinux_role=sysadm.role
Sep 27 16:31:29 sudo[68214] -> selinux_setup @ ./selinux.c:349
Sep 27 16:31:29 sudo[68214] -> get_exec_context @ ./selinux.c:274
Sep 27 16:31:29 sudo[68214] <- get_exec_context @ ./selinux.c:328 := 0x5599c6ea8430
Sep 27 16:31:29 sudo[68214] -> relabel_tty @ ./selinux.c:160
Sep 27 16:31:29 sudo[68214] <- relabel_tty @ ./selinux.c:253 := 0
Sep 27 16:31:29 sudo[68214] -> audit_role_change @ ./selinux.c:76
Sep 27 16:31:29 sudo[68214] <- audit_role_change @ ./selinux.c:98 := 5
Sep 27 16:31:29 sudo[68214] <- selinux_setup @ ./selinux.c:395 := 0
Sep 27 16:31:29 sudo[68214] -> selinux_execve @ ./selinux.c:405
Sep 27 16:31:29 sudo[68214] exec /usr/libexec/sudo/sesh [sesh /usr/bin/grep selinux /var/log/sudo_debug] [HISTSIZE=1000 HOSTNAME=agnus SSH_AUTH_SOCK=/run/user/9999/gnupg/S.gpg-agent.ssh LANG=en_US.UTF-8 LS_COLORS=di=38;5;33:ln=38;5;14:pi=38;5;11;40:so=38;5;13:bd=38;5;11;48;5;232:cd=33;48;5;232:or=38;5;196;48;5;232:mi=1;5;37;41:su=38;5;231;48;5;196:sg=38;5;16;48;5;226:ca=38;5;226;48;5;196:tw=38;5;16;48;5;40:ow=38;5;21;48;5;40:st=38;5;231;48;5;21:ex=38;5;40:*.nuv=38;5;13:*.m4v=38;5;13:*.ogv=38;5;13:*.rpm=38;5;9:*.tz=38;5;9:*.pbm=38;5;13:*.rm=38;5;13:*.svg=38;5;13:*.tiff=38;5;13:*.xpm=38;5;13:*.m4a=38;5;45:*.cab=38;5;9:*.ogm=38;5;13:*.arj=38;5;9:*.mpg=38;5;13:*.ppm=38;5;13:*.zip=38;5;9:*.rz=38;5;9:*.ogx=38;5;13:*.fli=38;5;13:*.rar=38;5;9:*.pgm=38;5;13:*.deb=38;5;9:*.dwm=38;5;9:*.bz2=38;5;9:*.mid=38;5;45:*.alz=38;5;9:*.xspf=38;5;45:*.tgz=38;5;9:*.t7z=38;5;9:*.taz=38;5;9:*.zst=38;5;9:*.lz=38;5;9:*.avi=38;5;13:*.webm=38;5;13:*.au=38;5;45:*.bz=38;5;9:*.flac=38;5;45:*.lz4=38;5;9:*.tzo=38;5;9:*.ogg=38;5;45:*.yuv=38;5;13:*.lzo=38;5;9:*.xbm=38;5;13:*.mng=38;5;13:*.xcf=38;5;13:*.z=38;5;9:*.mjpeg=38;5;13:*.ace=38;5;9:*.midi=38;5;45:*.lha=38;5;9:*.war=38;5;9:*.mpeg=38;5;13:*.Z=38;5;9:*.dz=38;5;9:*.aac=38;5;45:*.mp4v=38;5;13:*.tif=38;5;13:*.wim=38;5;9:*.lzma=38;5;9:*.opus=38;5;45:*.oga=38;5;45:*.wav=38;5;45:*.tzst=38;5;9:*.arc=38;5;9:*.tlz=38;5;9:*.zoo=38;5;9:*.esd=38;5;9:*.rmvb=38;5;13:*.tar=38;5;9:*.mp4=38;5;13:*.mka=38;5;45:*.tga=38;5;13:*.spx=38;5;45:*.jar=38;5;9:*.7z=38;5;9:*.flc=38;5;13:*.sar=38;5;9:*.png=38;5;13:*.dl=38;5;13:*.gz=38;5;9:*.cpio=38;5;9:*.mjpg=38;5;13:*.gif=38;5;13:*.emf=38;5;13:*.asf=38;5;13:*.qt=38;5;13:*.xwd=38;5;13:*.mpc=38;5;45:*.lzh=38;5;9:*.ear=38;5;9:*.m2v=38;5;13:*.vob=38;5;13:*.flv=38;5;13:*.ra=38;5;45:*.mkv=38;5;13:*.svgz=38;5;13:*.mov=38;5;13:*.swm=38;5;9:*.txz=38;5;9:*.pcx=38;5;13:*.gl=38;5;13:*.lrz=38;5;9:*.wmv=38;5;13:*.bmp=38;5;13:*.cgm=38;5;13:*.tbz2=38;5;9:*.xz=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.mp3=38;5;45:*.tbz=38;5;9: TERM=xterm-256color PS1=[\u@\h \W$(__git_ps1 " (%s)")]\$  MAIL=/var/spool/mail/kcinimod PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LOGNAME=root USER=root HOME=/root SHELL=/bin/bash SUDO_COMMAND=/usr/bin/grep selinux /var/log/sudo_debug SUDO_USER=kcinimod SUDO_UID=9999 SUDO_GID=9999]

> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: question about selinux_restore_tty() in sudo's selinux.c

[Stephen Smalley]

On 9/27/19 10:28 AM, Dominick Grift wrote:
> On Fri, Sep 27, 2019 at 10:17:16AM -0400, Stephen Smalley wrote:
>> On 9/27/19 10:01 AM, Stephen Smalley wrote:
>>> On 9/27/19 9:57 AM, Dominick Grift wrote:
>>>> On Fri, Sep 27, 2019 at 09:51:26AM -0400, Stephen Smalley wrote:
>>>>> On 9/27/19 9:49 AM, Dominick Grift wrote:
>>>>>> On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
>>>>>>> On 9/27/19 9:08 AM, Dominick Grift wrote:
>>>>>>>> On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
>>>>>>>>> On 9/27/19 3:55 AM, Dominick Grift wrote:
>>>>>>>>>> sudo does not reset the role of my tty
>>>>>>>>>> properly [1], and i was wondering if anyone
>>>>>>>>>> is able to determine what is causing this
>>>>>>>>>> [2]
>>>>>>>>>>
>>>>>>>>>> [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
>>>>>>>>>> [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
>>>>>>>>>
>>>>>>>>> Are you sure sudo is calling selinux_restore_tty()?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> running sudo with:
>>>>>>>>
>>>>>>>> Debug sudo /var/log/sudo_debug all@debug
>>>>>>>> Debug sudoers.so /var/log/sudo_debug all@debug
>>>>>>>>
>>>>>>>> Yields:
>>>>>>>>
>>>>>>>> grep selinux /var/log/sudo_debug
>>>>>>>> Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @
>>>>>>>> ../../../lib/util/key_val.c:61 :=
>>>>>>>> selinux_role=sysadm.role
>>>>>>>> Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
>>>>>>>> Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
>>>>>>>> Sep 27 15:06:29 sudo[3447] -> get_exec_context @
>>>>>>>> ../../src/selinux.c:274
>>>>>>>> Sep 27 15:06:29 sudo[3447] <- get_exec_context @
>>>>>>>> ../../src/selinux.c:328 := 0x564eed3621b0
>>>>>>>> Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
>>>>>>>> Sep 27 15:06:29 sudo[3447] <- relabel_tty @
>>>>>>>> ../../src/selinux.c:253 := 0
>>>>>>>> Sep 27 15:06:29 sudo[3447] -> audit_role_change @
>>>>>>>> ../../src/selinux.c:76
>>>>>>>> Sep 27 15:06:29 sudo[3447] <- audit_role_change @
>>>>>>>> ../../src/selinux.c:98 := 6
>>>>>>>> Sep 27 15:06:29 sudo[3447] <- selinux_setup @
>>>>>>>> ../../src/selinux.c:395 := 0
>>>>>>>> Sep 27 15:06:29 sudo[3447] -> selinux_execve @
>>>>>>>> ../../src/selinux.c:405
>>>>>>>> Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @
>>>>>>>> ../../src/selinux.c:114
>>>>>>>> Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @
>>>>>>>> ../../src/selinux.c:142 := 0
>>>>>>>
>>>>>>> Ok, so you entered and exited selinux_restore_tty() without error. No
>>>>>>> warning messages of any kind in any of the sudo logs? Not sure where
>>>>>>> sudo_warn() and sudo_warnx() messages go.
>>>>>>
>>>>>> No warnings or any other clues. I guess it must be this then:
>>>>>>
>>>>>>        if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
>>>>>>      goto skip_relabel;
>>>>>
>>>>> That should only occur if there was no tty or security_compute_relabel()
>>>>> didn't provide a new context to set in the first place. Not if
>>>>> it actually
>>>>> relabeled the tty earlier.
>>>>>
>>>>> Does newrole work correctly with your policy?
>>>>
>>>> Yes:
>>>>
>>>> kcinimod@seamus:~$ id -Z
>>>> wheel.id:wheel.role:wheel.subj:s0
>>>> kcinimod@seamus:~$ ls -alZ `tty`
>>>> crw--w----. 1 kcinimod tty
>>>> wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
>>>> 15:55 /dev/pts/10
>>>> kcinimod@seamus:~$ newrole -r sysadm.role
>>>> Password:
>>>> newrole: incorrect password for kcinimod
>>>> kcinimod@seamus:~$ ls -alZ `tty`
>>>> crw--w----. 1 kcinimod tty
>>>> wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
>>>> 15:56 /dev/pts/10
>>>> kcinimod@seamus:~$ newrole -r sysadm.role
>>>> Password:
>>>> kcinimod@seamus:~$ id -Z
>>>> wheel.id:sysadm.role:sysadm.subj:s0
>>>> kcinimod@seamus:~$ ls -alZ `tty`
>>>> crw--w----. 1 kcinimod tty
>>>> wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
>>>> 15:56 /dev/pts/10
>>>> kcinimod@seamus:~$ exit
>>>> logout
>>>> kcinimod@seamus:~$ ls -alZ `tty`
>>>> crw--w----. 1 kcinimod tty
>>>> wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
>>>> 15:56 /dev/pts/10
>>>
>>> Ok, so at least we know it is a bug in the sudo code somewhere.  I'd
>>> assume that for some reason ttyfd or new_tty_context are either not
>>> being set in the first place or are being unset somewhere?
>>
>> Can you provide your sudo package version so I can be sure I'm looking at
>> the right sources?  The line numbers in your debug output don't quite align
>> with the current upstream.
> 
> root@seamus:~# apt info sudo
> Package: sudo
> Version: 1.8.27-1+b1
> Priority: optional
> Section: admin
> Source: sudo (1.8.27-1)
> Maintainer: Bdale Garbee <bdale@gag.com>
> Installed-Size: 3,879 kB
> Depends: libaudit1 (>= 1:2.2.1), libc6 (>= 2.27), libpam0g (>= 0.99.7.1), libselinux1 (>= 1.32), libpam-modules, lsb-base
> Conflicts: sudo-ldap
> Replaces: sudo-ldap
> Homepage: http://www.sudo.ws/
> Tag: admin::login, admin::user-management, implemented-in::c,
>   interface::commandline, role::program, scope::utility,
>   security::authentication, use::login
> Download-Size: 1,244 kB
> APT-Manual-Installed: yes
> APT-Sources: http://mirror.nl.leaseweb.net/debian sid/main amd64 Packages
> Description: Provide limited super user privileges to specific users
>   Sudo is a program designed to allow a sysadmin to give limited root
>   privileges to users and log root activity.  The basic philosophy is to give
>   as few privileges as possible but still allow people to get their work done.
>   .
>   This version is built with minimal shared library dependencies, use the
>   sudo-ldap package instead if you need LDAP support for sudoers.

Ok, I can match up the line numbers successfully.

I could be wrong since I am not especially familiar with sudo's internal 
structure, but I'm wondering if the call to selinux_setup() is occurring 
in a different process than the call to selinux_restore_tty().  If so, 
then the use of global state by those functions like the se_state would 
be broken.  Ask the sudo maintainers.   This probably wouldn't show up 
under Fedora's default policies since I don't think they bother with 
different types on ttys for the different user roles, so no relabeling 
is needed.

Re: question about selinux_restore_tty() in sudo's selinux.c

[Stephen Smalley]

On 9/27/19 10:49 AM, Stephen Smalley wrote:
> On 9/27/19 10:28 AM, Dominick Grift wrote:
>> On Fri, Sep 27, 2019 at 10:17:16AM -0400, Stephen Smalley wrote:
>>> On 9/27/19 10:01 AM, Stephen Smalley wrote:
>>>> On 9/27/19 9:57 AM, Dominick Grift wrote:
>>>>> On Fri, Sep 27, 2019 at 09:51:26AM -0400, Stephen Smalley wrote:
>>>>>> On 9/27/19 9:49 AM, Dominick Grift wrote:
>>>>>>> On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
>>>>>>>> On 9/27/19 9:08 AM, Dominick Grift wrote:
>>>>>>>>> On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
>>>>>>>>>> On 9/27/19 3:55 AM, Dominick Grift wrote:
>>>>>>>>>>> sudo does not reset the role of my tty
>>>>>>>>>>> properly [1], and i was wondering if anyone
>>>>>>>>>>> is able to determine what is causing this
>>>>>>>>>>> [2]
>>>>>>>>>>>
>>>>>>>>>>> [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
>>>>>>>>>>> [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
>>>>>>>>>>
>>>>>>>>>> Are you sure sudo is calling selinux_restore_tty()?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> running sudo with:
>>>>>>>>>
>>>>>>>>> Debug sudo /var/log/sudo_debug all@debug
>>>>>>>>> Debug sudoers.so /var/log/sudo_debug all@debug
>>>>>>>>>
>>>>>>>>> Yields:
>>>>>>>>>
>>>>>>>>> grep selinux /var/log/sudo_debug
>>>>>>>>> Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @
>>>>>>>>> ../../../lib/util/key_val.c:61 :=
>>>>>>>>> selinux_role=sysadm.role
>>>>>>>>> Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
>>>>>>>>> Sep 27 15:06:29 sudo[3447] -> selinux_setup @ 
>>>>>>>>> ../../src/selinux.c:349
>>>>>>>>> Sep 27 15:06:29 sudo[3447] -> get_exec_context @
>>>>>>>>> ../../src/selinux.c:274
>>>>>>>>> Sep 27 15:06:29 sudo[3447] <- get_exec_context @
>>>>>>>>> ../../src/selinux.c:328 := 0x564eed3621b0
>>>>>>>>> Sep 27 15:06:29 sudo[3447] -> relabel_tty @ 
>>>>>>>>> ../../src/selinux.c:160
>>>>>>>>> Sep 27 15:06:29 sudo[3447] <- relabel_tty @
>>>>>>>>> ../../src/selinux.c:253 := 0
>>>>>>>>> Sep 27 15:06:29 sudo[3447] -> audit_role_change @
>>>>>>>>> ../../src/selinux.c:76
>>>>>>>>> Sep 27 15:06:29 sudo[3447] <- audit_role_change @
>>>>>>>>> ../../src/selinux.c:98 := 6
>>>>>>>>> Sep 27 15:06:29 sudo[3447] <- selinux_setup @
>>>>>>>>> ../../src/selinux.c:395 := 0
>>>>>>>>> Sep 27 15:06:29 sudo[3447] -> selinux_execve @
>>>>>>>>> ../../src/selinux.c:405
>>>>>>>>> Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @
>>>>>>>>> ../../src/selinux.c:114
>>>>>>>>> Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @
>>>>>>>>> ../../src/selinux.c:142 := 0
>>>>>>>>
>>>>>>>> Ok, so you entered and exited selinux_restore_tty() without 
>>>>>>>> error. No
>>>>>>>> warning messages of any kind in any of the sudo logs? Not sure 
>>>>>>>> where
>>>>>>>> sudo_warn() and sudo_warnx() messages go.
>>>>>>>
>>>>>>> No warnings or any other clues. I guess it must be this then:
>>>>>>>
>>>>>>>        if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
>>>>>>>      goto skip_relabel;
>>>>>>
>>>>>> That should only occur if there was no tty or 
>>>>>> security_compute_relabel()
>>>>>> didn't provide a new context to set in the first place. Not if
>>>>>> it actually
>>>>>> relabeled the tty earlier.
>>>>>>
>>>>>> Does newrole work correctly with your policy?
>>>>>
>>>>> Yes:
>>>>>
>>>>> kcinimod@seamus:~$ id -Z
>>>>> wheel.id:wheel.role:wheel.subj:s0
>>>>> kcinimod@seamus:~$ ls -alZ `tty`
>>>>> crw--w----. 1 kcinimod tty
>>>>> wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
>>>>> 15:55 /dev/pts/10
>>>>> kcinimod@seamus:~$ newrole -r sysadm.role
>>>>> Password:
>>>>> newrole: incorrect password for kcinimod
>>>>> kcinimod@seamus:~$ ls -alZ `tty`
>>>>> crw--w----. 1 kcinimod tty
>>>>> wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
>>>>> 15:56 /dev/pts/10
>>>>> kcinimod@seamus:~$ newrole -r sysadm.role
>>>>> Password:
>>>>> kcinimod@seamus:~$ id -Z
>>>>> wheel.id:sysadm.role:sysadm.subj:s0
>>>>> kcinimod@seamus:~$ ls -alZ `tty`
>>>>> crw--w----. 1 kcinimod tty
>>>>> wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
>>>>> 15:56 /dev/pts/10
>>>>> kcinimod@seamus:~$ exit
>>>>> logout
>>>>> kcinimod@seamus:~$ ls -alZ `tty`
>>>>> crw--w----. 1 kcinimod tty
>>>>> wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
>>>>> 15:56 /dev/pts/10
>>>>
>>>> Ok, so at least we know it is a bug in the sudo code somewhere.  I'd
>>>> assume that for some reason ttyfd or new_tty_context are either not
>>>> being set in the first place or are being unset somewhere?
>>>
>>> Can you provide your sudo package version so I can be sure I'm 
>>> looking at
>>> the right sources?  The line numbers in your debug output don't quite 
>>> align
>>> with the current upstream.
>>
>> root@seamus:~# apt info sudo
>> Package: sudo
>> Version: 1.8.27-1+b1
>> Priority: optional
>> Section: admin
>> Source: sudo (1.8.27-1)
>> Maintainer: Bdale Garbee <bdale@gag.com>
>> Installed-Size: 3,879 kB
>> Depends: libaudit1 (>= 1:2.2.1), libc6 (>= 2.27), libpam0g (>= 
>> 0.99.7.1), libselinux1 (>= 1.32), libpam-modules, lsb-base
>> Conflicts: sudo-ldap
>> Replaces: sudo-ldap
>> Homepage: http://www.sudo.ws/
>> Tag: admin::login, admin::user-management, implemented-in::c,
>>   interface::commandline, role::program, scope::utility,
>>   security::authentication, use::login
>> Download-Size: 1,244 kB
>> APT-Manual-Installed: yes
>> APT-Sources: http://mirror.nl.leaseweb.net/debian sid/main amd64 Packages
>> Description: Provide limited super user privileges to specific users
>>   Sudo is a program designed to allow a sysadmin to give limited root
>>   privileges to users and log root activity.  The basic philosophy is 
>> to give
>>   as few privileges as possible but still allow people to get their 
>> work done.
>>   .
>>   This version is built with minimal shared library dependencies, use the
>>   sudo-ldap package instead if you need LDAP support for sudoers.
> 
> Ok, I can match up the line numbers successfully.
> 
> I could be wrong since I am not especially familiar with sudo's internal 
> structure, but I'm wondering if the call to selinux_setup() is occurring 
> in a different process than the call to selinux_restore_tty().  If so, 
> then the use of global state by those functions like the se_state would 
> be broken.  Ask the sudo maintainers.   This probably wouldn't show up 
> under Fedora's default policies since I don't think they bother with 
> different types on ttys for the different user roles, so no relabeling 
> is needed.

Actually, looking back at your debug logs, that is evident from the 
different PIDs reported for the calls to selinux_setup() vs 
selinux_restore_tty().  Originally these were probably both called from 
the parent process, then someone must have re-factored and moved the 
selinux_setup() to the child?

Re: question about selinux_restore_tty() in sudo's selinux.c

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 7508 bytes --]

On Fri, Sep 27, 2019 at 10:49:15AM -0400, Stephen Smalley wrote:
> On 9/27/19 10:28 AM, Dominick Grift wrote:
> > On Fri, Sep 27, 2019 at 10:17:16AM -0400, Stephen Smalley wrote:
> > > On 9/27/19 10:01 AM, Stephen Smalley wrote:
> > > > On 9/27/19 9:57 AM, Dominick Grift wrote:
> > > > > On Fri, Sep 27, 2019 at 09:51:26AM -0400, Stephen Smalley wrote:
> > > > > > On 9/27/19 9:49 AM, Dominick Grift wrote:
> > > > > > > On Fri, Sep 27, 2019 at 09:33:06AM -0400, Stephen Smalley wrote:
> > > > > > > > On 9/27/19 9:08 AM, Dominick Grift wrote:
> > > > > > > > > On Fri, Sep 27, 2019 at 08:59:26AM -0400, Stephen Smalley wrote:
> > > > > > > > > > On 9/27/19 3:55 AM, Dominick Grift wrote:
> > > > > > > > > > > sudo does not reset the role of my tty
> > > > > > > > > > > properly [1], and i was wondering if anyone
> > > > > > > > > > > is able to determine what is causing this
> > > > > > > > > > > [2]
> > > > > > > > > > > 
> > > > > > > > > > > [1] https://bugzilla.sudo.ws/show_bug.cgi?id=898
> > > > > > > > > > > [2] https://www.sudo.ws/repos/sudo/file/tip/src/selinux.c
> > > > > > > > > > 
> > > > > > > > > > Are you sure sudo is calling selinux_restore_tty()?
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > running sudo with:
> > > > > > > > > 
> > > > > > > > > Debug sudo /var/log/sudo_debug all@debug
> > > > > > > > > Debug sudoers.so /var/log/sudo_debug all@debug
> > > > > > > > > 
> > > > > > > > > Yields:
> > > > > > > > > 
> > > > > > > > > grep selinux /var/log/sudo_debug
> > > > > > > > > Sep 27 15:06:29 sudo[3417] <- sudo_new_key_val_v1 @
> > > > > > > > > ../../../lib/util/key_val.c:61 :=
> > > > > > > > > selinux_role=sysadm.role
> > > > > > > > > Sep 27 15:06:29 sudo[3417]     7: selinux_role=sysadm.role
> > > > > > > > > Sep 27 15:06:29 sudo[3447] -> selinux_setup @ ../../src/selinux.c:349
> > > > > > > > > Sep 27 15:06:29 sudo[3447] -> get_exec_context @
> > > > > > > > > ../../src/selinux.c:274
> > > > > > > > > Sep 27 15:06:29 sudo[3447] <- get_exec_context @
> > > > > > > > > ../../src/selinux.c:328 := 0x564eed3621b0
> > > > > > > > > Sep 27 15:06:29 sudo[3447] -> relabel_tty @ ../../src/selinux.c:160
> > > > > > > > > Sep 27 15:06:29 sudo[3447] <- relabel_tty @
> > > > > > > > > ../../src/selinux.c:253 := 0
> > > > > > > > > Sep 27 15:06:29 sudo[3447] -> audit_role_change @
> > > > > > > > > ../../src/selinux.c:76
> > > > > > > > > Sep 27 15:06:29 sudo[3447] <- audit_role_change @
> > > > > > > > > ../../src/selinux.c:98 := 6
> > > > > > > > > Sep 27 15:06:29 sudo[3447] <- selinux_setup @
> > > > > > > > > ../../src/selinux.c:395 := 0
> > > > > > > > > Sep 27 15:06:29 sudo[3447] -> selinux_execve @
> > > > > > > > > ../../src/selinux.c:405
> > > > > > > > > Sep 27 15:06:29 sudo[3417] -> selinux_restore_tty @
> > > > > > > > > ../../src/selinux.c:114
> > > > > > > > > Sep 27 15:06:29 sudo[3417] <- selinux_restore_tty @
> > > > > > > > > ../../src/selinux.c:142 := 0
> > > > > > > > 
> > > > > > > > Ok, so you entered and exited selinux_restore_tty() without error. No
> > > > > > > > warning messages of any kind in any of the sudo logs? Not sure where
> > > > > > > > sudo_warn() and sudo_warnx() messages go.
> > > > > > > 
> > > > > > > No warnings or any other clues. I guess it must be this then:
> > > > > > > 
> > > > > > >        if (se_state.ttyfd == -1 || se_state.new_tty_context == NULL)
> > > > > > >      goto skip_relabel;
> > > > > > 
> > > > > > That should only occur if there was no tty or security_compute_relabel()
> > > > > > didn't provide a new context to set in the first place. Not if
> > > > > > it actually
> > > > > > relabeled the tty earlier.
> > > > > > 
> > > > > > Does newrole work correctly with your policy?
> > > > > 
> > > > > Yes:
> > > > > 
> > > > > kcinimod@seamus:~$ id -Z
> > > > > wheel.id:wheel.role:wheel.subj:s0
> > > > > kcinimod@seamus:~$ ls -alZ `tty`
> > > > > crw--w----. 1 kcinimod tty
> > > > > wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > > > 15:55 /dev/pts/10
> > > > > kcinimod@seamus:~$ newrole -r sysadm.role
> > > > > Password:
> > > > > newrole: incorrect password for kcinimod
> > > > > kcinimod@seamus:~$ ls -alZ `tty`
> > > > > crw--w----. 1 kcinimod tty
> > > > > wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > > > 15:56 /dev/pts/10
> > > > > kcinimod@seamus:~$ newrole -r sysadm.role
> > > > > Password:
> > > > > kcinimod@seamus:~$ id -Z
> > > > > wheel.id:sysadm.role:sysadm.subj:s0
> > > > > kcinimod@seamus:~$ ls -alZ `tty`
> > > > > crw--w----. 1 kcinimod tty
> > > > > wheel.id:sysadm.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > > > 15:56 /dev/pts/10
> > > > > kcinimod@seamus:~$ exit
> > > > > logout
> > > > > kcinimod@seamus:~$ ls -alZ `tty`
> > > > > crw--w----. 1 kcinimod tty
> > > > > wheel.id:wheel.role:users.terminals.pty.pty_file:s0 136, 10 Sep 27
> > > > > 15:56 /dev/pts/10
> > > > 
> > > > Ok, so at least we know it is a bug in the sudo code somewhere.  I'd
> > > > assume that for some reason ttyfd or new_tty_context are either not
> > > > being set in the first place or are being unset somewhere?
> > > 
> > > Can you provide your sudo package version so I can be sure I'm looking at
> > > the right sources?  The line numbers in your debug output don't quite align
> > > with the current upstream.
> > 
> > root@seamus:~# apt info sudo
> > Package: sudo
> > Version: 1.8.27-1+b1
> > Priority: optional
> > Section: admin
> > Source: sudo (1.8.27-1)
> > Maintainer: Bdale Garbee <bdale@gag.com>
> > Installed-Size: 3,879 kB
> > Depends: libaudit1 (>= 1:2.2.1), libc6 (>= 2.27), libpam0g (>= 0.99.7.1), libselinux1 (>= 1.32), libpam-modules, lsb-base
> > Conflicts: sudo-ldap
> > Replaces: sudo-ldap
> > Homepage: http://www.sudo.ws/
> > Tag: admin::login, admin::user-management, implemented-in::c,
> >   interface::commandline, role::program, scope::utility,
> >   security::authentication, use::login
> > Download-Size: 1,244 kB
> > APT-Manual-Installed: yes
> > APT-Sources: http://mirror.nl.leaseweb.net/debian sid/main amd64 Packages
> > Description: Provide limited super user privileges to specific users
> >   Sudo is a program designed to allow a sysadmin to give limited root
> >   privileges to users and log root activity.  The basic philosophy is to give
> >   as few privileges as possible but still allow people to get their work done.
> >   .
> >   This version is built with minimal shared library dependencies, use the
> >   sudo-ldap package instead if you need LDAP support for sudoers.
> 
> Ok, I can match up the line numbers successfully.
> 
> I could be wrong since I am not especially familiar with sudo's internal
> structure, but I'm wondering if the call to selinux_setup() is occurring in
> a different process than the call to selinux_restore_tty().  If so, then the
> use of global state by those functions like the se_state would be broken.
> Ask the sudo maintainers.   This probably wouldn't show up under Fedora's
> default policies since I don't think they bother with different types on
> ttys for the different user roles, so no relabeling is needed.

Thanks for helping! My policy is a bit "special".

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]