First Linux Question

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?