First Linux Question

[catch]

I have gotten enough answers now that I am finished with the private portion of the research... now let's open it up. (I hope we can all be adult enough to not have this thread suicide as well)

My question, which is based on a particular need I have that I understood as not being possible to implement in Linux was:
[QUOTE]What: How can I create a trusted path in Linux?

Explained: I need an inimitable key/key sequence that allows the user to connect directly to the trusted computer base (TCB).

Why: To prevent users at shared terminals from utilizing false login screens for the purpose of elevating their access by capturing user credentials.

Windows: Windows 2000 offers this functionality by requiring the control-alt-delete key sequence before providing a login screen. User space Windows applications cannot capture this sequence.

My understanding: Although Linux does support the Secure Attention Key (SAK) it is not part of the TCB, it is buggy, and not universally supported.
QUOTE]

The answers I received included:

[list=1][*]compile the kernel with sysrq support and this will provide the SysRQ+K or Alt+SySRQ+K keystroke combination.[*]rc.local (depending on the distro) and add the command: echo "control alt keycode 101 = SAK" | /bin/loadkeys ... This would make Alt+Ctrl+Pause the SAK sequence and could only be modified by the superuser. [*]http://www.ggi-project.org/[*]SAK is still premature in development projects[*] If you suspect there might be a bogus login screen on your tty, simply enter a couple bogus usernames and passwords, so that it exits and puts you back to the (hopefully) regular /bin/login program.[*]try to kill any programs running on that current tty before you login[*]You do need the "Magic SysRq key" enabled in the kernel (has been in there since 2.1.0).[*]Since the X server is not part of the Linux kernel I don't think there will be a secure path for graphical logins for quite some time..[*]Linux needs to catch up here.[*]CTRL-ALT-DEL is trapped by the system and /etc/inititab specifies which prog. to run: ca::ctrlaltdel:/sbin/shutdown -t3 -r now ... By modifying the /etc/X11/xdm/xdm-config and modify: DisplayManager*chooser: /etc/X11/xdm/chooser to run an app of your choosing that displays a screen that says Press CTRL-ALT-DEL to login and mdify inittab to run chooser when pressed.[*]In short, due to the current way Linux is designed, you can't.[*]Linux doesn't really have a TCB, so you can never get a reasonable level of trust. [/list=1]

The conclusions I have drawn from this are:

Although there are ways to kill processes and bypass keystroke trapping... none of these methods are high enough assurance to use in a production environment. At the end of the day, a single compromised terminal can gain the passwords to every account that uses it.

http://www.linux.com/howtos/Secure-P...ted-path.shtml

Seems to agree with this point.

I feel confident that I can chalk this up to the "Not Capable" section. What is troubling is the number of varied responses I received, in this case I blame the fact that without a bit of research, it is difficult to determine if most open source packages are considered no longer research level. To make the issue even more confusing is the fact that there is no agreed upon point where something goes from "research level" to "production level".

Any disagreements to the conclusions made here or should I go on to question two?

cheers,

catch

[!mitationRust]

Yes, you need to be able to communicate with a security enforcement module through a succession of keys. Good first question, really puts the heat on. Standards.... a good yardstick to measure with. Golden rule start with the TCB design security kernel first, then the OS around it. And....fractionate TCB from non-TCB...I don't see how lunix is going to pull this one off.

[slarty]

I'm aware that normal Linux distributions lack the "secure attention key" feature. However, it is present in the kernel (as noted above).

As far as "TCB" is concerned, Linux has no TCB, but that doesn't stop some distribution defining one, after all, a TCB only exists by definition. I'd argue, that probably all of Linux would be in the TCB, as Linux is just the kernel.

The Linux kernel secure attention key *should* be able to work perfectly well with X, as I think it's implemented at the kernel level in the keyboard driver before X can trap it (X is a userspace process).

Non-root users can't mess with the SAK, or disable it in non-root userspace programs.

Slarty

[catch]

Non-root users can't mess with the SAK, or disable it in non-root userspace programs.

Exactly the point, indicating that root can alter the SAK, which means it cannot be trusted.

cheers,

catch

[Trevoke]

Catch, root has every right to the system. That's what a supervisor account is.
Is it possible to disable the admin account on a Windows server? Why would you want to do that? The root account is necessary to maintenance.
Saying that root has access to it means "Erm, it's closed off, no one gets to touch it".

Compromising root is the same thing as compromising the admin account.

[phishphreek]

Originally posted here by catch
Exactly the point, indicating that root can alter the SAK, which means it cannot be trusted.

cheers,

catch

Couldn't the same be said about windows? Maybe Administrator doesn't have the power to modify certain things in windows... but it is quite easy to elevate your privledges from administrator to SYSTEM.

My experience/knowledge is lacking in SAK and TCB... but a "super user" exists on both Linux and Windows.

[catch]

Is it possible to disable the admin account on a Windows server?

Windows Administrator != UNIX root

Windows Administrator exists within the context of the system's security policy and can be limited accordingly.

Why would you want to do that?

So you don't have a huge gaping hole that is the all powerful account... same reason why things like SE Linux and LIDS limit the root account (somewhat)

Compromising root is the same thing as compromising the admin account.

Really? Try this:

On a Linux system create a file as user "Trevoke" and set the perms as "700" now try to access this file as root, what happens?

On a Windows system create a file as "Trevoke" and set "Administrator" as deny all, now try to access the file as Administrator... notice a difference?

For extra fun on the Windows system, create a new account called SSO and using the local security policy editor, remove Administrator from the "Take Ownership" entry and add SSO. Next set Administrator to "deny all" on the local security policy editor.

Root is all powerful, Administrator is a normal user (that can't be deleted) that just has more entries in the system's security policy. the same goes for the SYSTEM account.

but a "super user" exists on both Linux and Windows

Again, root exists outside the scope of the system security policy, Windows has no such users... windows has a reference monitor.

cheers,

catch

[slarty]

Personally, I think the difference is really fairly subtle.

True, systems like WinNT do not *automatically* allow the administrator to violate the ACLs on objects - but they still *can*, because other facilities which exist, allow them to gain access despite permissions.

Likewise, just because root is "All powerful", does not mean that they can't be restricted - stuff like NSA security enhanced Linux does not allow root to violate the privileges associated with its context.

It is entirely possible, on WinNT, for someone with Administrator access to create a fake login screen which bypasses the secure attention key. I know how to do it (if anyone is interested).

Slarty

[gore]

OK, Catch, now I know you're not Windows only, I've known you long enough to know you do in fact like Unix. There IS something.... And of course at the moment I can't think about what it is exactly, but there is something you can add to a Linux system, where you could give the root password to everyone and no one could break anything.

The thing I'm talking about is I think an add on, I have to check though, I have the mail saved somewhere where me and some people were talking about Linux, I just need to check a few emails for it on this box (I save all emails that are interresting to me and BugTraq mails too, so I just need to find where it is and then I can paste it here) But it has to be tonight because right now, work calls, and from there I'm going to the Doom Movie opening.

And just on my box here, I don't log in as root usually. I have all the root mail sent to my ISP's email addy and I use other things for doing admin work.

Hell if you were ballsy you could edit permissions by hand and make root nothing. Though it could break some system stuff, but what I'm saying is that there is more to it than what you've seen so far. anyway I have to run but I'll look for that tonight.

[Trevoke]

Here's a security tutorial I found while looking around:
http://www.linux-tutorial.info/modul...ial&pageid=188
The page on the root account is interesting, as they explain that you can disable direct root logins and only allow them through 'su', which writes a system event, at least..

if you have access to 'sudo' (which lets a user do things limited to root, another can of worms, right?), you can lock the root account altogether with "sudo passwd -l root" [ -l = lock user account ].

And you can also only allow root logins from a serial terminal, so no network logins. That's bound to help a bit.