public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Makan Pourzandi <Makan.Pourzandi@ericsson.ca>
To: Pavel Machek <pavel@suse.cz>
Cc: linux-kernel@vger.kernel.org,
	Axelle Apvrille <Axelle.Apvrille@ericsson.ca>,
	Vincent Roy <vincent.roy@ericsson.ca>,
	David Gordon <davidgordonca@yahoo.ca>,
	socrate@infoiasi.ro
Subject: Re: [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries
Date: Wed, 01 Oct 2003 09:33:09 -0400	[thread overview]
Message-ID: <3F7AD795.1040001@ericsson.ca> (raw)
In-Reply-To: 20031001102631.GC398@elf.ucw.cz

Pavel Machek wrote:

>Hi!
>
>  
>
>>overview
>>=======
>>
>>Instead of writing a long detailed explication, I rather give you an 
>>example of how you can use it.
>>    
>>
>
>Can you also add example *why* one would want to use it?
>  
>
>AFAICS if I want to exec something, I can avoid exec() syscall and do
>mmaps by hand...
>

Hi,

Thank you for your feedback. This is my understanding of the situation, 
if I'm wrong in my analysis, let me know.

There are different answers to this question because there are many 
possible attack scenarios. I try to take the most realistic one and give 
a short answer.  

For the attacke described by you to be successful, one assumes that the 
intruder  gained access to the system,  he wrote his own code on the 
system (or brought it in),  and compile  it on the system (cannot 
execute its own code as it is not signed), produced the binary to mmap 
the malicious code to the memory, and run the code that call syscall 
mmap.   

First digsig can help to avoid the access to the system by the intruder. 
as it aborts the execution of malicious code which often leads to a root 
access for the intruder.

Second, digsig can avoid the execution of the binary that allows to 
bring in the code or other malicious binaries. AFAIK, the intruders 
generally use their own binary to download malicious code. This is 
because in hardened systems, the use of ftp ot other alike binaries, 
(when these binaries are not completely removed from the system for 
security reasons) is closely monitored and controled through firewalling 
rules. Even in simple desktops, it is rather easy to control the use of 
ftp and alike to track down the intrusion source.  therefore, the 
intruder needs to run  his own binary to download the root kit which is 
avoided by the use of digsig.

Third, the intruder now has access to the system, he cannot execute the 
code he brought in with himself (not signed) or he cannot bring it in 
(c.f. above). So he needs to compile the code on the system. AFAIK, for 
the absolute majority of servers the admins remove all compilers 
(specially gcc) on all servers. this is for several different security 
reasons  (I don't want to get there). therefore, the above hypothesis 
gets even more difficult to realize. 

Last, but I believe the most important, the level of difficulty of 
execution of such an attack is much higher than the average knowledge 
level of many script kiddies. The absolute majority of attackers have 
little or absolutely not any knowledge of the operating systems in 
general and linux in particular, let aside the knowledge of writing a C 
program, calling mmaps in that progam and run the malicious code to gain 
access as root, then remove the module to execute a classical attack.

There is no such thing as 100% secure system, digsig increases the level 
of security of the system as it just makes it much more difficult for 
the intruder to succeed in his/her attack.

regards,
makan

-------------------------------------------------------
Makan Pourzandi,
Ericsson Research Canada
*This email does not represent or express the opinions of
Ericsson Inc.
-------------------------------------------------------



  reply	other threads:[~2003-10-01 13:25 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-25 19:19 [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification for binaries Makan Pourzandi
2003-10-01 10:26 ` Pavel Machek
2003-10-01 13:33   ` Makan Pourzandi [this message]
2003-10-01 14:17     ` viro
2003-10-01 18:14       ` Makan Pourzandi
2003-10-01 18:24         ` viro
2003-10-01 21:51           ` Willy Tarreau
2003-10-01 21:55           ` Radu Filip
2003-10-01 22:05             ` Pavel Machek
2003-10-01 23:36             ` Larry McVoy
2003-10-02  0:53               ` jlnance
2003-10-02  0:17             ` [ANNOUNCE] DigSig 0.2: kernel module for digital signatureverification " Edgar Toernig
2003-10-02  2:04               ` David Gordon
2003-10-02  2:42             ` [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification " Valdis.Kletnieks
2003-10-02 18:36               ` [ANNOUNCE] DigSig 0.2: kernel module for digital signature ve rification " Makan Pourzandi
2003-10-01 14:05   ` [ANNOUNCE] DigSig 0.2: kernel module for digital signature verification " Valdis.Kletnieks

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3F7AD795.1040001@ericsson.ca \
    --to=makan.pourzandi@ericsson.ca \
    --cc=Axelle.Apvrille@ericsson.ca \
    --cc=davidgordonca@yahoo.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    --cc=socrate@infoiasi.ro \
    --cc=vincent.roy@ericsson.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox