| Summary: | do not change the context from unconfined_t | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | jchadima | ||||||
| Component: | sshd | Assignee: | Assigned to nobody <unassigned-bugs> | ||||||
| Status: | CLOSED FIXED | ||||||||
| Severity: | minor | CC: | djm, jchadima, t8m | ||||||
| Priority: | P2 | ||||||||
| Version: | 5.8p1 | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
|
Description
jchadima
2011-07-21 23:30:27 AEST
Created attachment 2066 [details]
patch solving the problem
Is the restriction of changing away from unconfined_t just a matter of policy? If so, then introducing a short-circuit like this could severely break people who have modified this policy. Would it be better to attempt the change in policy but just downgrade the logit() to a debug3() if the previous type was unconfined_t? Unconfined is unprivileged default, something like database NULL. There should be no operations on it in the policy. Unconfined thing should stay unconfined forever. Jan, in arbitrary policies the unconfined_t might mean just anything. So I agree with Damien, that just downgrading the log messages to debug3 if transition from unconfined_t is involved is more appropriate. Created attachment 2077 [details]
selinux-unconfined.diff
revised patch
applied - this will be in 5.9, due in a few days close resolved bugs now that openssh-5.9 has been released |