Goal / Danger: Attack by malicious root

Goal / Danger: Attack by malicious root

[Jan Petranek]

dear guys,

did You consider the possibility of an malicious root attacks? In most
Linuxdistributions, the priviliged user can read & manipulate all of the user's
data. 

This is indeed a situation I find myself in today: I am working on a
Linux-Machine in the university's computer pool. And I find my own
(non-encrypted) home directory far too insecure to put a private key or
something like that in here.  This is also from the point of view, that the
root-login may be hacked on a campus site like this.

So to me, there is a need of encrypting the user's data. The question of the
key yet remains: A key like a password / passphrase is quite limited in it's
length (by the memory of the user). A key on a medium (like a CD-ROM,
chipcard etc.) could be longer, but still there is the demand, that it can't be read by 
somebody else (not even the superuser), when mounted /
used by the user.
Also, the key medium could compromise the encryption, but that is another
problem.

I'd be quite glad, if you could take this point in consideration,

JanP



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Goal / Danger: Attack by malicious root

[Robert Hartley]

Jan,

If we were to play paranoiac for a moment, we would have to assume that the application
that does the encryption would be compromised by the malicious root, and that even system
calls could be compromised by using a trace facility.

The only solution would be to either trust in the root users' lack of technical expertise,
or in their good will.

The alternative is not to allow access to your data using your crypto keys in an execution
environment you have no real control over.

Like Bennett just mentioned while I was typing this, you need assurance you have control
over the hardware.

Have you considered using something like your own bootable CD, or a Jazz/Zip drive?

Robert


Jan Petranek wrote:

> dear guys,
>
> did You consider the possibility of an malicious root attacks? In most
> Linuxdistributions, the priviliged user can read & manipulate all of the user's
> data.
>
> This is indeed a situation I find myself in today: I am working on a
> Linux-Machine in the university's computer pool. And I find my own
> (non-encrypted) home directory far too insecure to put a private key or
> something like that in here.  This is also from the point of view, that the
> root-login may be hacked on a campus site like this.
>
> So to me, there is a need of encrypting the user's data. The question of the
> key yet remains: A key like a password / passphrase is quite limited in it's
> length (by the memory of the user). A key on a medium (like a CD-ROM,
> chipcard etc.) could be longer, but still there is the demand, that it can't be read by
> somebody else (not even the superuser), when mounted /
> used by the user.
> Also, the key medium could compromise the encryption, but that is another
> problem.
>
> I'd be quite glad, if you could take this point in consideration,
>
> JanP
>
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
=  Robert Hartley                 Mail:         201 Broadway        =
=  Central Region Systems Engineer              Cambridge, MA 02139 =
=  Integrated Computer            Email:        rhartley@ics.com    =
=  Solutions, Inc.                Web Site:     www.ics.com         =
=  Tech Support: support@ics.com  Phone:        800-800-4271        =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Visit the MotifZone (www.motifzone.org) for info on Motif!




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Goal / Danger: Attack by malicious root

[Bennett Todd]

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

The problem you describe is right in the heart of the design
principles of trusted computing systems.

Basically, the only way you can trust a computer to use it for
sensitive purposes (like presenting your reusable authentication
credentials to it) is if you _know_ that the code it's running
hasn't been tampered with. If you want to use a system that's out in
a public lab where people can whack on it, your only real hope is to
see if you can force it to boot from some media you take with you
(or, depending on your assumptions and your local network
architecture, possibly do a network boot from a secured server ---
that latter was the Athena approach). Maybe take a CD-ROM with a
known-good OS along with you.

The problem is that if someone has complete control over a system,
no OS feature can possibly save you, since the attacker is in a
position to completely revise or replace the OS.

Now _if_ you had a situation where the machine was sufficiently
thoroughly physically secured, and the software running on it
sufficiently tightly configured, that you were confident that the OS
wasn't tampered with, then the problem would reduce to a real oldie,
the trusted path. The typical fix for that is to have the OS
directly support a special hot-key combo that is absolutely
guaranteed to terminate all processes associated with that console,
and start a new login process, guaranteed to come from the real OS
and not any trojan left running by the last person on that console.
That would be easy to add to selinux. In fact, I thought I'd
remembered seeing something along those lines, but when I just
checked the todo.html I didn't find 'em, maybe my brain is playing
nasty tricks on me.

They do mention integrating the file mandatory access controls with
file encryption, so that part of your question is on the todo list,
but trusted path I do not see. Perhaps it's too trivial. Certainly
it wouldn't be too hard to rig a script around lsof to blow away
anything that has an open file descriptor on the console device, and
let a getty get respawned by init, and wire that to the crtlaltdel
hook in inittab.

-Bennett

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Goal / Danger: Attack by malicious root

[Andi Kleen]

On Mon, Jan 15, 2001 at 11:22:53AM -0500, Bennett Todd wrote:
> Now _if_ you had a situation where the machine was sufficiently
> thoroughly physically secured, and the software running on it
> sufficiently tightly configured, that you were confident that the OS
> wasn't tampered with, then the problem would reduce to a real oldie,
> the trusted path. The typical fix for that is to have the OS
> directly support a special hot-key combo that is absolutely
> guaranteed to terminate all processes associated with that console,
> and start a new login process, guaranteed to come from the real OS
> and not any trojan left running by the last person on that console.
> That would be easy to add to selinux. In fact, I thought I'd
> remembered seeing something along those lines, but when I just
> checked the todo.html I didn't find 'em, maybe my brain is playing
> nasty tricks on me.

Linux already has a secure attention key, you just have to enable it.
Unfortunately it doesn't do very good, because when the X server is
unexpectedly killed it often leaves the graphic card in unusable state.
>From a network login you can also just open a new ssh/telnet etc. 


-Andi


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Goal / Danger: Attack by malicious root

[Preston L. Bannister]

I'd be *very* surprised if the selinux people can offer 
any protection from a hostile superuser.

Simply encrypting the data in your home directory offers
little protection as the software you use to perform the 
encryption is running on the superuser controlled machine. 

A superuser can intercept your input, change the software
you are running, and intercept output from the programs 
you run.  Under those circumstances nothing you do on that
machine is secure from a hostile superuser.

By definition a superuser can do anything on that machine.

Another basic rule is that no machine is secure if a hostile
has physical access to the hardware.  Visit the recent FBI 
planting of monitoring devices in the keyboards people on 
which they wish to spy.

In any case none of this is really relevant to selinux.


From: Jan Petranek
> did You consider the possibility of an malicious root attacks? In most
> Linuxdistributions, the priviliged user can read & manipulate all 
> of the user's data. 
> 
> This is indeed a situation I find myself in today: I am working on a
> Linux-Machine in the university's computer pool. And I find my own
> (non-encrypted) home directory far too insecure to put a private key or
> something like that in here.  This is also from the point of 
> view, that the root-login may be hacked on a campus site like this.
> 
> So to me, there is a need of encrypting the user's data. 
> The question of the key yet remains: A key like a password / 
> passphrase is quite limited in it's length (by the memory of 
> the user). A key on a medium (like a CD-ROM, chipcard etc.) 
> could be longer, but still there is the demand, that it can't 
> be read by somebody else (not even the superuser), when mounted /
> used by the user. Also, the key medium could compromise the 
> encryption, but that is another problem.

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Goal / Danger: Attack by malicious root

[Johnathon Day]

Hi,

   If someone on the SELinux team sees any mistakes in what I'm saying,
feel free to correct me.

   SELinux, as I understand it, uses mandatory access controls. To me,
this implies that NO user, including the superuser, has automatic right
of access, except in those specific cases where access is explicitly 
granted. ie: the default is to deny access. (The Dead Man's Handle.)

   This would imply that, in the event of a successful root attack, the
attacker would be limited in what they could see, and limited in what they
could set themselves able to see.

   The "ultimate" in this path is to have no concept of a
super-user. Then, attacking one username is as good as attacking
another. There isn't one ripe target that's necessarily vulnerable AND
powerful.

   Yes, you -can- hide hardware, put on tamper-proof locks, et al, but
those are really useless for security, as the main source of attacks is
from the INside. (This has been true, ever since "Hugo Cornwall" wrote the
"Hacker's Handbook".) Security comes from within, not without. In other
words, security shouldn't be a matter of which direction the enemy comes
from. It should still be there. Holding the hard-disk must be as useless
as holding the IP address. Otherwise, you're vulnerable.

   As for encryption, you make the assumption of a static key. A rolling
key, where the key value is some arbritary function of the previous key,
location on disk, user profile, etc, and other random data, means that any
crack in the encryption ONLY reveals data from the point of crack onwards,
provided the cracker has the algorithm and ALL necessary rolled-over
data. This essentially means that, for incomplete information, a cracker
would never be 100% sure they -had- cracked the data, as multiple
"valid" translations would exist.

   THAT is the key to good encryption, IMHO. Anyone can crack a code, IF
they know how to tell if they -have- cracked it. As soon as you get many
possible translations, all of which "work", then you're down to guesswork
as to which one is "real". And the more "valid" translations you can get,
the worse it'll be. By using a randomly-shifting key, where the shift is
deterministic but non-predictable (ie: chaotic), and functions which are
sensitive to initial conditions, you can make it impractical for a cracker
to guess which of the N decrypts is meaningful.


Jonathan Day



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Goal / Danger: Attack by malicious root

[Bennett Todd]

[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]

2001-01-15-12:53:07 Johnathon Day:
>    If someone on the SELinux team sees any mistakes in what I'm saying,
> feel free to correct me.

I'm not on the selinux team, but I see an assumption you're making
that needs to be hauled out and examined clearly.

You're assuming that control mechanisms wired into selinux can be
effective. This is true only as long as the selinux installation
itself isn't modified or replaced by something else.

The original poster seemed to be describing a setting where the
physical hardware on which the OS was running was left exposed in a
public lab. If that were the case, then no OS protections could
solve the resulting security problem; before OS design can be of any
help, the hardware itself must be physically secured enough to
prevent the attacker from simply replacing it.

That's why replies emphasized tricks like rigging a bootable CD to
carry with you.

>    SELinux, as I understand it, uses mandatory access controls. To me,
> this implies that NO user, including the superuser, has automatic right
> of access, except in those specific cases where access is explicitly 
> granted. ie: the default is to deny access.

That's all fine --- as long as selinux is running, and the OS itself
hasn't been compromised. With physically unprotected hardware, that
cannot be guaranteed.

-Bennett

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Goal / Danger: Attack by malicious root

[Johnathon Day]

Hi again,

	The problem is this. Let your innermost layer of defence be
defined as "L".

	If there exists any "legit" method of bypassing "L", there exists
a malicious method of bypassing "L".

	So, yes, if someone can bypass the OS by running their own, or
tampering with the HW, anything that is actively prohibited by the OS can
be done.

	The trick is to NOT rely on active defences, but to also use some
form of passive defence, where the OS doesn't prevent the unauthorised as
actively permit the authorised. That way, bypassing the OS achieves
nothing.

	The "usual" way to do this is to use encrypted storage space. The
problem there is that you've got to have an unprotected way for the system
to bootstrap. Catch-22.

	This is usually dealt with by placing the unprotected component on
a removable device. Then, it's only vulnerable at the time when an
authorised person is present. In theory. In reality, all you're doing is
shifting the problem, not solving it.

	How to solve the problem? This isn't as hard as it sounds. Trying
to stop the unstoppable is an obvious impossibility. So, instead of being
a follower of King Canute, it makes more sense to =assume= that someone
can/has tampered with the HW, and figure out how to limit the damage.

	That -is- a solvable problem. If the OS is segmented, with each
segment itself constrained by mandatory access controls, then tampering
with the OS won't achieve much, without disabling the MAC first. And if
the MAC is part of the mechanism which permits the OS to do anything, then
disabling it disables the OS. Hmmm.

	It's true that NO protection, however good, will be 100%
effective. That's why it's better to concentrate on damage limitation
systems and compartmentalization, so that damage is always confined.

	In summary, the DEFAULT privilage, regardless of the method of
access, or what OS is used, should be that the user cannot read the data
on the disk. ONLY through active, specific, deliberate permission should
any other privilage be possible. THEN, you have as much security as you
can realistically achieve.

Jonathan Day



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: Goal / Danger: Attack by malicious root

[Matthew Pemble]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Consider, for a moment, the irony here. 

For the record, the "boot from your own device" solution, I agree
with, as the only way of establishing trust in your OS (although
keystroke loggers that don't use OS functions, video capture devices
etc in tampered hardware can still get you).

Take a step back - we are assuming an attacker, whether a legitimate
holder of super-user privileges whom you do not want to have access
to your data or protection against an "Evil Minded Toad" who has
stolen root.  In the former case, limiting the privileges of the root
user through MAC is good protection (assuming you can generate or
request your own MAC labels and root is not the MAC privilege
assigner.)  In the latter case, if the lab environment allows you to
boot a CD, they don't need to "hack", they can craft a malicious
version of the OS and boot that.

You, a specialist user who reads a security mailing list may be safe,
but the vast majority of users will be at greater risk than if
booting from a CD was prevented.  Who are we trying to protect?  Us
or the normal user - consider, when your boss is writing your annual
report, will (s)he take these precautions.  Mine won't.

Matthew Pemble, Principal Consultant, IS Integration,
Preston Technology Management Centre, Marsh Lane, PRESTON,
Lancashire, PR1 8UD

Tel: +44 (0)1324 820690  Fax: +44 (0)1324 826034

Head Office: 
Tel: +44 (0)1772 885850  Fax: +44 (0)1772 558881
Mobile: +44 (0)7050 128620
Mailto:mpemble@isintegration.com  Web: http://www.isintegration.com

This email and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you have received this email in error please notify your system
manager
or IS Integration Limited on +44 (0) 1772 885850

Any Views expressed in this e-mail message are those of the
individual
sending the message, except where the sender specifically states them
to be
the views of IS Integration Limited. 

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBOmQOhGrvMjpl5yaUEQLQwQCgjiquMMxqV4j54RiMZF0kptVtl2sAoOQm
NmCkT9tsDvLjwn6OyNGlMAlF
=/MHf
-----END PGP SIGNATURE-----


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Goal / Danger: Attack by malicious root

[Stephen Smalley]

On Mon, 15 Jan 2001, Jan Petranek wrote:

> did You consider the possibility of an malicious root attacks? In most
> Linuxdistributions, the priviliged user can read & manipulate all of the user's
> data. 

In SELinux, the root user has no special privileges with respect to the
mandatory access controls.  Neither the Unix superuser identity nor the
Linux capabilities override the mandatory access controls.  Hence,
a root process can be confined like any other process.  Furthermore,
in contrast to typical multi-level secure systems, there are no
"trusted subjects" in SELinux that are authorized to violate the
mandatory access control policy.  As I explained in the thread about
how SELinux compares with the Linux-Privs project, there is no
need for a mechanism to override the SELinux mandatory access
controls because the security policy can be configured as
needed to support fine-grained privileges for processes wtith
respect to the mandatory controls.

System processes and setuid programs can be placed into very
fine-grained protection domains in SELinux that are granted
only those privileges that they truly require.  The example
security policy configuration provides a number of examples
of how to do this for various system daemons and programs.
The example security policy configuration also shows how to
ensure that the legitimate administrator domain can be protected
from various threats, including the threat of executing
untrustworthy code.

--
Stephen D. Smalley, NAI Labs
sds@tislabs.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Goal / Danger: Attack by malicious root

[Roger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> How to solve the problem? This isn't as hard as it sounds. Trying
> to stop the unstoppable is an obvious impossibility. So, instead of being
> a follower of King Canute, it makes more sense to =assume= that someone
> can/has tampered with the HW, and figure out how to limit the damage.

eh....i'd just skip the coding and go straight to using a stick of TNT and a 
'tripwire'.  



- -- 
- -----
To verify the signature, get GNUPG (Open Source PGP Security)
http://www.gnupg.org/

My pulic key (in armor format) can be found at:
http://www.alltel.net/rogerx/index.html

My ICQ UIN# = 21252173

Created with Linux Mandrake 7.2!
http://www.linux-mandrake.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjpkPlYACgkQZA/JYxAFHWFreACdHIZHyNVl5ZMhnVqq3D0BmmPP
BWcAn13ARxe2NTfaheF4l2FCVa6MqSzy
=/lGL
-----END PGP SIGNATURE-----



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.