First Linux Question

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

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.

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

Quote:

---

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

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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)

Quote:

---

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.

Quote:

---

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

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

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.

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.

Quote:

---

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

---

More than anything else, this reveals why you are a suit and not a computer guy.
You live in a world of abstractions, coming from the top down, enforced by willpower,
rather than from the physical world, aware of what can actually be accomplished in hardware.

Do you think that, by putting security into a proprietary black box, totally inaccessible,
except, perhaps to the original designer, that we can all be happy and trust
a machine that refuses to trust us?

http://www.acm.org/classics/sep95/

http://catb.org/~esr/jargon/html/B/back-door.html

Root login can be disabled pretty much completely on the local box, ssh, through `su' or X. You could require multiple authentification tokens to be connected to the laptop before root login is allowed. PaX does some and the stock kernel has options for the 'token' that I'm speaking of.

You could disable root to the point where the nobody user has a greater chance to actually login than root ever does :P

And kudos to rcgreen for the link.

I'm not sure what Catch's over all goal is, but my guess is the root of which may be money. The cost of purchasing licensing and maintenance of the Microsoft platform versus open source which is (for the software) cost free. That's not to say there is no cost, there are man hour costs, development costs and even validation costs.

From reviewing this thread and previous ones, the options/opinions vary so much about the capabilities of Linux, which are the proven ones? I'm assuming the environment in which Catch would implement these, if it were possible are stringent and need to adhere to the "book". What if he attempts to implement those pieces(from a Linux standpoint), the pieces that would be all inclusive to create a complete environment to adhere to the guidelines, would it be more costly in time and trial and error than it would be to just pay the cost of Microsoft's already accepted system?

Don't get me wrong, I've been in *nix arena since 1986, when in UNIX, I don't use GUI's I am a vi diehard and most my emails are all in lower case, because that is how I use the keyboard in UNIX(most of my typing, this post would be all lowercase too but spellcheck fixed it for me). So, I am not, nor would I, condemn Linux or any variation of UNIX, it's my life. But that's not the question, the question is one of environments, needs and costs.

I don't think Catch is turning his nose up at Linux, I think he is honestly interested and if the capabilities were available and at a truly(all things considered) lower cost, would implement it. We've even done some similar studies, our company was heading for bankruptcy and management wanted us to look into Linux as an alternative to windows, but any direction we turned and looked, we found reasons to not switch, even at a lower cost. Most not having to do with security at all, but applications, user training and familiarity, the question was always "is it worth the time and effort?"

I have been reading this forums since March of 2001, only been a member since early this years, but I do have this to say, I do find this to be one of the best conversations/threads thus far, I only hope it stays in the direction needed and doesn't get into a pissing match. One thing that could come from it is an actual solution, that is if we stay focused.

My assumptions could be wrong of course, but I'm willing to think otherwise and take my chances, you guys can be tough on a person some times when you disagree with a post.

Quote:

---

but my guess is the root of which may be money. The cost of purchasing licensing and maintenance of the Microsoft platform versus open source

---

You hit the nail right on the head. From a management perspective, the question isn't
"are the threads on this bolt right or left handed", but "will it work?" and "how much will it cost"
The concern about ctrl-alt-del and the logon is misplaced, since the windows logon code
could be made untrustworthy, if not by a hacker, by its author.

It's not a technical issue, but a business one. If I buy from vendor A, I know where
they live, and who to sue when things go wrong. It may not bother me that their code
is a black box if i trust the people who sold me the software.

With open source, I have to take responsibility for my own security, or trust my in-house
people to administer the system sanely. Businesses are inherently conservative.
They would rather buy insurance than accept the risk themselves.

We need to get down to what has what.

These extensions and all this retrofitting to me are dubitable. Hey what do I know?
All your trust in the whole systems security lies in the TCB. So really, there is no trusted way to invoke a security enforcement module in Linux (trusted path), even with these other retrofitted "trusted"-linuxes too I presume? That's a lot of lost assurance to me right there alone.

Quote:

---

Originally posted here by Opus00
I'm not sure what Catch's over all goal is, but my guess is the root of which may be money.

---

I can't speak for the man but I'd say yes. I believe he's coming from a risk analysis perspective, which is at the core of security. You're going to implement this stuff in a business and all they care about first is money, that usually comes before security. This is where the real pros step in, the think-tank.
To calculate:
Asset values (AV)
Exposure factor (EF)
Annual rate of occurrence. (ARO)
Single Loss Expectancy (SLE)
Business Impact Anylysis (BIA)

A whole nother good topic.

Ok so I did some googleing..
And it tells the same story..
There is SAK but using it gives you all the power of the Magick System Request Key Hack..

First hit on 'linux "Secure Access Key'"
http://www.djcj.org/LAU/guide/sysreq.html

Quote:

---

'k' - Secure Access Key (SAK) Kills all programs on the current virtual
console. NOTE: See important comments below in SAK section.
..

sa'K' (Secure Access Key) is useful when you want to be sure there are no
trojan program is running at console and which could grab your password
when you would try to login. It will kill all programs on given console
and thus letting you make sure that the login prompt you see is actually
the one from init, not some trojan program.
IMPORTANT:In its true form it is not a true SAK like the one in :IMPORTANT
IMPORTATN:c2 compliant systems, and it should be mistook as such. :IMPORTANT
It seems other find it useful as (System Attention Key) which is
useful when you want to exit a program that will not let you switch consoles.
(For example, X or a svgalib program.)

---

Nice typo IMPORTATN there.. It has been fixed in later kernel versions.

First hit on 'SuSE "Secure Access Key'"
http://www.novell.com/coolsolutions/feature/15751.html

Quote:

---

'k' - Secure Access Key (SAK) Kills all programs on the current virtual console.

---

Cool Solutions :cry:

First hit on 'Red Hat "Secure Access Key'"
http://www.redhat.com/docs/manuals/e...rectories.html

Quote:

---

k — Kills all processes active in a virtual console. Also called the Secure Access Key (SAK), it is often used to verify that the login prompt is spawned from init and not a trojan copy designed to capture usernames and passwords.

---

Slackware has no official online documentation on this..
Well some of the same but all hearsay or the files below in mirrors..



So now let's get to the real documentation..
/usr/src/linux-2.x.x(.x)/Documentation/sysrq.txt

Quote:

---

Linux Magic System Request Key Hacks
Documentation for sysrq.c version 1.15
Last update: $Date: 2001/01/28 10:15:59 $

..

sa'K' (Secure Access Key) is useful when you want to be sure there are no
trojan program is running at console and which could grab your password
when you would try to login. It will kill all programs on given console
and thus letting you make sure that the login prompt you see is actually
the one from init, not some trojan program.
IMPORTANT:In its true form it is not a true SAK like the one in :IMPORTANT
IMPORTANT:c2 compliant systems, and it should be mistook as such. :IMPORTANT
It seems other find it useful as (System Attention Key) which is
useful when you want to exit a program that will not let you switch consoles.
(For example, X or a svgalib program.)

---

/usr/src/linux-2.x.x(.x)/Documentation/SAK.txt

Quote:

---

Linux 2.4.2 Secure Attention Key (SAK) handling
18 March 2001, Andrew Morton <[email protected]>

..

NOTES
=====

1: Linux SAK is said to be not a "true SAK" as is required by
systems which implement C2 level security. This author does not
know why.


2: On the PC keyboard, SAK kills all applications which have
/dev/console opened.

Unfortunately this includes a number of things which you don't
actually want killed. This is because these applications are
incorrectly holding /dev/console open. Be sure to complain to your
Linux distributor about this!

---

And the code ?
/usr/src/linux-2.x.x(.x)/drivers/char/sysrq.c

Code:

---

*      Linux Magic System Request Key Hacks
 *
 *      (c) 1997 Martin Mares <[email protected]>
 *      based on ideas by Pavel Machek <[email protected]>
 *
 *      (c) 2000 Crutcher Dunnavant <[email protected]>
 *      overhauled to use key registration

---

All quotes from linux-2.6.13.4

So I do think documentation is consistant..

Quote:

---

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.

---

No, the Administrator CANNOT violate the system's security policy, why is this so hard for you to understand?

Quote:

---

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.

---

I always forget about about SE Linux, have a look at my Zealocy in Linux-land post.

And aside from all of this... the root issue is just once example of wht it is not a trusted path, which is the actual topic here. Yes you can use a myriad of methods to restrict root... none of those methods are universally supported and subsequently none of those uses are suitable in my production environments.
I just want the system to work, I don't want exotic configurations that that I read about in some slashdotter's blog, I don't want prototpe patch work (the fact that SE Linux is supported by the standard kernel should make you all ask "Why?! Why in gods name would we give that kind of core support to research projects?"), and I don't want some random college kid's special lucky super security model extension that is labeled as "stable" because he finially got it to a point where it didn't crash when he launched it. Is all of this too much to ask for?

Opus00, i think your post was excellent, but I don't think most people that assigned you points actually read it. ;)

Quote:

---

These extensions and all this retrofitting to me are dubitable. Hey what do I know?

---

Well my thoughts exactly...

the_Jinx... your documentation is a little confusing to me:

Quote:

---

In its true form it is not a true SAK like the one in
c2 compliant systems, and it should be mistook as such.

---

Does this really say you should mistake the SAK for something it's not?
The trusted path is not a C2 requirement, it is introduced at the B2 level.
The reason why the Linux SAK isn't a true trusted path is because it can be initiated by other processes than the user.

So are we all in agreement then? And you can all start writting to your favorite distro and tell them that for real business needs they should implement a trusted path.

At first I thought this was an area where I was just plain ignorant... there are many solutions that look very good on the surface. It is unfortunate that none of them really panned out.

cheers,

catch

Quote:

---

Originally posted here by catch
No, the Administrator CANNOT violate the system's security policy, why is this so hard for you to understand?

---

But rights which are granted to Administrator by default, allow them to do things which make the policy pretty much academic.

For example, the "Debug any process" privilege, gives the administrator access to do, well, anything pretty much, seeing as they can take control of any process they want, including ones inside your precious "trusted computing base". Likewise, loading kernel code does too.

I'm not sure if you'd want these privileges to be disabled; the system probably wouldn't work terribly well if they were.

What I'm asking is, how is this different from "root" being allowed to do anything? If it truly is, the difference is only academic.

Slarty

Quote:

---

But rights which are granted to Administrator by default, allow them to do things which make the policy pretty much academic.

---

By default? Are you ****ing kidding me? By default Windows only has two accounts (Admin & Guest) and Microsoft recommends that you disable guest!

Right... because I have no plans of configuring these systems at all (much less in a way recommended by Microsoft). I just like to drop the boxes in and hope they work... if only there was some way to configure them... like with an inherited security policy *sigh* that would be dreamy.

Why do you think Windows ships with an Operators group? For show? You think because actually using that group will make the system not "work terribly well"?

Hahaha by default... let's all just run OpenBSD!!... come back when you have something serious to say.

cheers,

catch

Hmmm, good thread I think. I just got home from the opening day for DOOM!!!!! (GOOD movie, but not on topic, PM me for details).

First off, Catch isn't an ******* which for some reason seems to be what people are "thinking". Theya ren't thinking it maybe but it seems like someone is probably aboutto use the word. He's simply giving Linux a shot to see if it does what HE needs it to do. Not what everyone else uses it for, but what HE needs it to do, that's all.

Linux is an OS, and there isn't an OS on God's green Earth that does everything and makes EVERYONE happy.

Next time someone wants to call me an arrogant SUSE elitist, think long nd hard about that, Catch doesn't stand up for Linux in any way shape or form, and he's a good buddy.

Then again Catch gave SUSE props a while back ;)

catch does have a slightly odd outlook on security in general, I mean, he doesn't run AV software or install some patches. (Catch, Microsoft recommends you do that and you said something about doing what they recommend ;) )

Anyway I need to find what I was looking for earlier and post when I do because I just got home a bit ago. When I find it I'll post what I found, it's somewhere in one of my Mutt mailboxes with 3,000 other emails.

Catch, could you let us know of some Unix OSs that actually are up to your needs as a user?

Gore... I was enjoying this thread (even though it's a little over my head)... what are you doing here (other than the usual, of course)? :)

Actually I was one of the first the answer 3 of his questions. Give me SOME credit :(

Secure Attention Sequence (SAS), god this was just the first question, I suspect he's gonna hit on MAC,DAC, (DACLs), like (ACEs) access control entries, Auditing, Object Reuse, a performance monitor etc.. Maybe he's gonna want discretionary resource protection and auditing capability, A Reference Monitor (SRM) to keep things in check and run an access validation routine. Hell maybe displaying a Legal Notice Before Logon? Just off the top of my head. I can't wait to see the rest.

Actually IR, my next question has only marginally to do with security or assurances. :)

Gore, as for unices that I like... I like AIX and IRIX (an I miss XENIX) however neither of those systems really met my needs as a common workstation.

cheers,

catch

Can't the ctrl+alt+del thing be disabled? I guess that can be disallowed to be disabled with the security policy thing, so it goes right back in the "who's more powerfull administrator or root"-discussion. I thought I'd mention it anyway though.

Quote:

---

the "who's more powerfull administrator or root"-discussion

---

There is no discussion, the only people who don't know better have a total lack of understanding about how either UNIX or Windows works.

Yes requiring control-alt-delete can be disabled... by ANY USER authorized to do so. Obviously if it isn't required the user will know something is fishy... as for the sequence itself:

"What makes it secure is that the OS traps this key sequence in a way that makes it impossible for anything not in the Trusted Computing Base to handle it."
http://blogs.msdn.com/larryosterman/...24/359850.aspx

However... consider the Linux documentation refers to the C2 level even though no such requirement exists there and that they don't know why it doesn't meet C2 requirements (because nne exist?) and a two second glance at the B2 trusted path requirement would tell you why Linux fails to meet the criteria lets me know that there is mucho misunderstanding about security requirements i the Linux camp. This along wih things like how Windows only gets evaluated with epoxied floppy drives and no networking and in a single, totally unusable configuration... utter rubbish and to think this yo have to have very poor understanding of the evaluation criteria... or to think that SUSE at EAL4+ is more secure than Windows 2000 at EAL4... LOOK AT THE PP!

To be perfectly honest, I don't need it to meet B2 reuirements... I just need something that is universally accepted. For example, if I have two choice:

1. A really crappy but offically supported security solution by IBM/Microsoft/etc
2. A really brilliant but obscure solution from some college kid

If I go with 1, and it fails horribly... I can say "Well, IBM/Microsoft/etc let us down." if I go with 2 and it fails i am left with "Well, I took a gamble, I lost... I'll have my letter of resigantion on your desk by tomorrow morning."

I can't say it enough, security is all about assurance.

cheers,

catch

Hmmm, probably a silly question, but any opinions on how Linspire might fit in?

http://lwn.net/Articles/128869/

I know it is not particularly secure "out of the box" but it might be a better shot at catch's requirement for a desktop solution?

:)

Quote:

---

Originally posted here by catch
Actually IR, my next question has only marginally to do with security or assurances. :)

Gore, as for unices that I like... I like AIX and IRIX (an I miss XENIX) however neither of those systems really met my needs as a common workstation.

cheers,

catch

---

No Solaris or like trusted?

Never got to try AIX or IRIX :(

XENIX I know about and have a decent understanding of how it came to be. Hell I even have a scanned image of an old ad from Micorosft for it.

While searching for a final out for linux, my search led me into the depths of the internet, to Shanghai. A few translated pages later I find the best of the best the linux camp elders have to offer.

You're gonna roll when you read this!

They first start talking about (SAS), which is NT-TFM terminology for a trusted path. Then they go into what linux's power has to offer.

Quote:

---

And will list the security function - credible way the constitution part, but under linux, also has the similar pressed key sequence is serviceable.

Under the Linux environment security pays attention key - SAK [ Secure Attention Key ], this SAK is one group of keys, under our common X86 platform, it is " alt+sysrq+k ", but under SPARC, SAK is " alt+STOP+k ", SAK tacitly approves does not open, needs to use echo " 1 " > /proc/sys/kernel/sysrq this order to activate, certainly, you also may interpolate it register in the script, like this needed not each time to trouble. Friend has the interest which to the SAK realization, may refers linux/drivers/char/sysrq.c and linux/drivers/char/tty_io.c::doc_sak
The SAK sequence key actually is is called makes in " magic sysrq key " one group, " magic sysrq key " also has some special keys, same with SAK, they all are use " alt + sysrq +..." 袷 sword □... May trade for certain special letter for instance " i ", in " MAGIC SYSRQ KEY DOCUMENTATION v1.32 " in the handbook, the behavior which " alt + sysrq +i " represents is " Send a SIGKILL to all processes, except for init. " The meaning is to transmits one kill signal besides init all advancements; Now we have a look in " MAGIC SYSRQ KEY DOCUMENTATION v1.32 " in the handbook to the " alt + sysrq +k " explanation:

" sa ' K ' (Secure Access Key) is usefull when you want to be
sure there are no trojan program is running at console and
which could grab your password when you would try to login.
It will kill all programs on given console and thus
letting you make sure that the login prompt you see is
actually the one from init, not some trojan program. "

This section of speech is precisely the SAK function portrayal: SAK to you determines in lands when has not attempted to steal the secret cipher the Trojan horse procedure movement in the current control bench, it can kill in the current control bench the completely application procedure, believes firmly by 此令 you sees lands the picture comes from init, but non- wooden horse procedure. When you press down this group of key, also was initiates this specific event, then deferred to the design the flow, the system fell into the core condition, by now you will be allowed directly with the essence communication, in other words, to appear in you " should " be guarantee exchange if not genuine really land the prompt information, why was should? Our 下文 analysis: -> etc...etc.................................

..................But was destroys goal machine TCB, with GINA wooden horse similar......Therefore this still could not be one loophole, analyzed from the TCB concept angle

---

http://edu.chinaz.com/Get/Server/Ser...8021689970.asp
Translate through English --> Chinese Beta google.

Holy ****! What is this, have they thrown together some type of slap jaw TFM? MAGIC SYSRQ KEY DOCUMENTATION Maybe this is the super special ultra lucky super magical TFM.

All we need to do is use the super lucky k switch.....duh!

Code:

---

k

---

k - Secure Access Key (SAK) Kills all programs on the current virtual
console. NOTE: See important comments below in SAK section.

If Secure Xenix had several hundred TFM pages, how many will this have?

Quote:

---

No Solaris or like trusted?

---

I don't really care for Solaris and Trusted Solaris is an awful TOS. Trusted Solaris is better than normal Solaris, but it so heavily flies in the face of UNIX philosophy that neither I nor most people would ever conisder it UNIX (unless it was somehow conveiniant to win an argument).

NT Security is a direct decendant of Secure XENIX and it followed the sandard MS ideology of never breaking appliction support in any situation other than a last resort.

!ir, that document hurts my head.

Quote:

---

IMPORTANT:In its true form it is not a true SAK like the one in :IMPORTANT
IMPORTANT:c2 compliant systems, and it should be mistook as such. :IMPORTANT

---

Is still what I find entertaining... it does seem that Linux users do exactly that... ignore the standards, but mistake things for being compliant. ;)

cheers,

catch

I don't understand how
3. http://www.ggi-project.org/

...applies to the question.

Also...

Quote:

---

This work is not intended as a complete security solution for Linux. Security-enhanced Linux is not an attempt to correct any flaws that may currently exist in Linux. Instead, it is simply an example of how mandatory access controls that can confine the actions of any process, including a superuser process, can be added into Linux.

---

Quote:

---

Nonetheless, we feel we have presented a good starting point to bring valuable security features to Linux.

---

That won't look good in an audit, will it? ;)

Sorry, I like drawn out debates... it brings out very interesting information. Would another thread addressing the risks of a root account be participated in? Or has it been addressed enough here?

Quote:

---

Originally posted here by catch

!ir, that document hurts my head.

---

C'mon buddy, it's encrypted syntax. You just need some of this import imperial brew I've been drinking all day long. They refer to the "trusted" path as the sa ' K ' (Secure Access Key) not the (Secure Attention Key). This ones different than yours.....more secure.... maybe they collected all possible security functions into a security kernel......this time it lies iinside the TCB. I think this ones the ticket.

We touched on a little of MAC what's next? Usability?

First and foremost, I want to thank catch for these threads ( sorry the first went the route it did ). I really hope he continues, and posts the rest of the questions he asked ( those distributed privately, which was not apparent at first. ) I am really enjoying the discussions and opinions.

I really don't want to divert from the current path of this thread, but thought I should comment on something:

Quote:

---

(the fact that SE Linux is supported by the standard kernel should make you all ask "Why?! Why in gods name would we give that kind of core support to research projects?") ...

---

I think something has been overlooked here, although may be a matter of semantics.

SELinux is no longer just a research project. It is commercially available, and has been so since February, 2005 with the release of Red Hat Enterprise Linux v.4.

Quote:

---

Mandatory Access Control: Security Enhanced Linux (SELinux) provides a MAC infrastructure that complements the existing Discretionary Access Control security features provided by the standard Linux environment. ...

---

What may be ( is ) still a research project is how SELinux is implemented for individual Distros, and how it applies to new software and environments.

And to slarty

Quote:

---

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).

---

Although I do not know how to do this, just got done setting up an FC4 box during a binge with someone who has done the same routinely with Win2k on several networks ( acceptable use, while administering the networks, ) but just bypasses the SAK, no fake screen needed. If ever I need it, he will be glad to supply the info needed. But I may have to get him drunk again :)

Quote:

---

First and foremost, I want to thank catch for these threads ( sorry the first went the route it did ).

---

Thanks for that, i am mostly trying to get to the bottom of the issues I have had with Linux and I have received so many hundreds of zillions of answers for, most of them verifibaly incorrect. ;) I hope others can benefit as well.

Quote:

---

SELinux is no longer just a research project. It is commercially available, and has been so since February, 2005 with the release of Red Hat Enterprise Linux v.4.

---

I disagree with the idea of taking a research project, adding it to a commercial product as is and calling it no longer research... it isn't a more mature version it just isn't being researched any further.

Nowhere in the NSA documentation do they address SE Linux as ready for commercial implementation, in fact the make a point to say the opposite, yet there it is.

cheers,

catch

Here's a good paper for anyone who is interested: http://cisr.nps.navy.mil/downloads/t...is_bartram.pdf

Written June 2000: There seems to be a lack of progress in this area, anyone know why?

One, when designing an OS, security must be taken into consideration throughout the whole design of the OS.

Two, it’s extremely difficult to retrofit assurances into the OS after the OS is designed.

Three, at the price of being redundant, security should begin during the alpha stages and be continual right into the omega stage. Any seasoned architect will second this motion. There are principles concerning protection mechanisms that need to be thought-out in the alpha stages. Like (PA) Psychological acceptability etc...etc... break these principles early on and you're on your own. Sounds like a lot of lost time to me, which is lost money.

And well, this one's a wreck......you're supposed to start with small low-level code in the kernel containing the lowest of low level OS functions....such as the topic. Small = assurances hence why the microkernel is the bomb and is the cornerstone of any good design. ;)

Quote:

---

One, when designing an OS, security must be taken into consideration throughout the whole design of the OS.

---

In the context of this thread, IE Linux vis Windows, I think it safe to say, that both OS's have had to evolve and adapt as threats become known.

Quote:

---

Two, it’s extremely difficult to retrofit assurances into the OS after the OS is designed.

---

I'm sure that is true, but both OS's have had to do just that........XP service pack 2 comes to mind. Also, and I cant find it now, wasn't the functionality of the trusted path added to NT with a service pack?

Quote:

---

In the context of this thread, IE Linux vis Windows, I think it safe to say, that both OS's have had to evolve and adapt as threats become known.

---

Actually this thread isn't about Windows vs Linux, it's about Linux having a trusted path.

However, the Windows security model has remained largely the same, and its microkernel style style structure allows the simple and secure addition of core functionality.

cheers,

catch

Quote:

---

Actually this thread isn't about Windows vs Linux, it's about Linux having a trusted path.

---

I phrased my reply incorrectly, I should have made it more clear. When I said , "In the context of this thread" I was refering to the topic of trusted path and the two OS's.

Quote:

---

Originally posted here by jinxy
Also, and I cant find it now, wasn't the functionality of the trusted path added to NT with a service pack?

---

What company reads the NCSC-TG-002, enters into a product security evaluation and shows up with a half-ass TFM that doesn't explain how their products security mechanisms work (trusted path)? Or reads the NCSC-TG-016 for that matter?

Quote:

---

SPECIFICATIONS AND DESIGN DOCUMENTATION
When a vendor enters into a product evaluation, he must present evidence that his system and its design meets the appropriate criteria requirements. Examples of the type of evidence normally submitted to support an evaluation include the design specifications that explain the security mechanisms, the Trusted Computing Base (TCB) arguments that show how the TCB is tamperproof, always invoked and small enough to be analyzed. Also, the model (or philosophy of protection) and how it relates to the implementation are important parts of the evidence. The best test of evidence is that it must include all the information such that a new team that is basically unfamiliar with the product could evaluate only the evidence and reach the proper
conclusion. ~ NCSC-TG-002

---

Quote:

---

requires that vendors provide a document to the evaluators......These include ... trusted path.~ NCSC-TG-002

---

Quote:

---

The only additional TFM requirement here is that of documenting trusted path mechanisms availible to the admin....NCSC-TG-016

---

On top of that, what company creates an OS with a TCB that pretermits a trusted path?

Quote:

---

Originally posted here by jinxy
I phrased my reply incorrectly, I should have made it more clear. When I said , "In the context of this thread" I was refering to the topic of trusted path and the two OS's.

---

He said IBM/Windows and I'm assuming any other COTS system that meets his requirements in the mans production environment.
I'm a little hammered right now I'll fix typos later.

Quote:

---

Originally posted here by rcgreen
More than anything else, this reveals why you are a suit and not a computer guy.
You live in a world of abstractions, coming from the top down, enforced by willpower,
rather than from the physical world, aware of what can actually be accomplished in hardware.

---

You know, I've pondered your statement for a while now.....at first I said to myself WTF is he talking about...then I recollected one of my favorite threads here, and then it hit me.

Quote:

---

Originally posted by catch

In reality, the end result is that given similar funds we will end up with similar systems. Mine however will be more comprehensively defined, will mesh better with high level policy, and will have less demanding personnel requirements. For most however this is mere nuance, though as the initial budget increases, so does the gap between the systems. Until eventually one method tops out perfect and the other as a rotten pork chop with heaps of fancy gravy on it.

---

So now hopefully you can comprehend fully why he wants what he wants, and understand his precociousness, which will save future assets in his production environment.

edit### merged post