On Tue, 2009-04-14 at 16:19 -0700, Brian Ginn wrote:
Thanks for the answers! They bring up more questions for me, though.
As a user_u, with a non-secure tty, after 'su -', it makes some sense that newrole won't let me change the level.
From that same non-secure terminal, however, I can ssh root@localhost and get all the access I want.
For both of those examples, I used ssh to get to the host, and both ptys have the type devpts_t, so I am not sure why one is considered more secure than the other.
I can envision that for many installations, making some pty types secure via /etc/selinux/targeted/contexts/securetty_types is an acceptable practice - even desired.
From a more paranoid security viewpoint, wouldn't there be some installations where any non-secure terminal should be prohibited from gaining access to the sensitive data?
So, I am wondering
- From that same non-secure terminal, should 'ssh root@localhost' be allowed to get a terminal that is considered secure?
- Should a terminal from any non-SELinux host be considered non-secure and be prevented from accessing sensitive data?
I think that under the LSPP configuration, sshd is configured to run in a mode where it preserves the security context of the client (which it obtains via labeled networking), and thus the session security context is preserved across ssh.
In both cases, it is driven by the LSPP/MLS requirements to prevent unauthorized downgrading of information across levels.