DigSig currently offers:

• run time signature verification of ELF binaries and shared libraries.
• support for file's signature revocation.
• a signature caching mechanism to enhance performances.

Its latest stable release is digsig-1.5.
DSI currently offers user space tools, a kernel module and the following security services:

• a Distributed Access Control service (DisAC)
• a Distributed communications' Confidentiality and Integrity service (DisCI)

Other services are being investigated (such as  secure distributed logging service - DisLog) but not yet implemented.

Currently, the latest stable release of DSI is disec-0.3.
The latest unstable release of DSI is disec-0.4 (development).

The DSI and the DigSig source code are being released under the GNU Public License (GPL), version 2.

The following table is used to follow up the evolution of DSI and related developments.

Project milestones	Date started
DigSig
DigSig is created	September 2003
DigSig uses sysfs (v0.3)	October 2003
DigSig checks signature of shared libraries too (v1.0)	November 2003
Caching mechanism (v1.2)	February 2004
Signature revocation mechanism (v1.3)	September 2004
DSI
DSI - Created.	Janvier 2002
DSI hosted on Sourceforge.	November 2002
Design and implementation of the DisCI and DisAC service	December 2002
Design and implementation of the Distributed Security Policy (DSP) + major update to the DisAC service	March 2003
DSI ported to 2.5.66 kernels	July 2003
Design and implementation of the File Integrity service	August 2003
Other developments related to DSI
The Linux Secure Boot Kit	2002

Buffer overflow attack stopped by DSI [avi] - This small video demonstrates a possible use of DSI. It may be viewed with any AVI player. We use a demonstration cluster, containing two nodes: glacier and colby. First, we show, that initially, the vulnerable program is exploitable, and potentially gives root access to any user on both machines (from a lmcaxpr shell, we gain root access). To solve this problem, we suggest use of DSI on our cluster. Glacier acts as both a Security Server and a Security Manager, and Colby is another Security Manager. We initialize the CORBA layer, assign an ScID 5 to the vulnerable program, and load DSM in the kernel. At this point, if we try to run the 'vulnerable' program, it fails because DSI is too restrictive and does not allow a shell to spawn a process of ScID 5. So, we update the Distributed Security Policy (DSP), adding a rule to allow ScID 5 to be launched. It is then possible to run 'vulnerable', and we notice that the buffer overflow exploit does not work any longer ! So, with this DSP, we have been able to make buffer overflow exploits fail on all nodes of our cluster. Finally, just for curiosity, we show the rule to be added for the buffer overflow exploit to work again.
NB. We do not really stop buffer overflows exploits, but rather shell launching via a buffer overflow. .

Sharing a Linux cluster without DSI: resource theft exploit - The following screen captures illustrate a possible exploit where two companies share the same cluster, and one of them is illicitly capable of using resources owned by the other one.
image 1 - PhoneMania and RingBell share a Linux cluster made of two nodes: glacier and colby.
image 2 - Both companies offer a quoting service, which is made of an Entry Point (EP) server (to which customers connect), and a Back End (BE) server (which performs the actual job). We launch the Back End server of PhoneMania on glacier (172.0.0.1), and UDP port 8801.
image 3 - We also launch RingBell's back end server on glacier, but on UDP port 9001.
image 4 - Now, we work on colby: another node of the cluster. Its IP address is 172.0.0.2.
image 5 - We launch PhoneMania's entry point on colby (172.0.0.2). It shall receive incoming customer request on port 8800. BUT, the trick is that it doesn't like to its own back end server, but to RingBell's back end server (glacier on 172.0.0.1, port 9001). Connection succeeds without any problem.
image 6 - In this image, we are just searching through our directory to find our sample customer application: TelecomClient.
image 7 - On the bottom right xterm window, we launch the client application for PhoneMania. It basically communicates with PhoneMania's entry point server (colby on 172.0.0.2, port 8800). The customer sends several quotation requests.
Those requests are received by PhoneMania's entry point server (see bottom left xterm)... and they are forwared to RingBell's back end server ! (see upper right xterm). This is it: PhoneMania has been able to use illicitly resources owned by RingBell (back end server). There is no way to prevent this on an unsecure cluster.

In our article "Setting up Virtual Security Zones in a Linux Cluster" in Linux Journal (October 2004), we show how DSI handles such a situation, and shares securely a Linux cluster among several operators. In brief, this is done by setting different ScIDs to RingBell's and PhoneMania's executables, and enforcing a no-sharing policy on all nodes of the cluster.

• DSI at Sourceforge [ http://sourceforge.net/projects/disec ]
• Ericsson's Open System Lab [http://www.linux.ericsson.ca]
  
• OSDL Carrier-Grade Linux [ http://www.osdl.org/projects/cgl ]

• Miroslaw Zakrzewski (Ericsson Research Canada)
• Charles Levert (Ericsson Research Canada)
• Marc Chatel (Ericsson Research Canada)
• Prof. Michel Dagenais (Polytechnique de Montreal)
• Dominic Pelerin (Sherbrooke University)
• Sann Yan (Sherbrooke University)
• Eric Gingras (UQAM)
• Alain Patrick Medenou (University of Montreal)
• Gabriel-Ioan Ivascu (Polytechnique de Montreal)
• Jean-Guillaume Paradis (Sherbrooke University)
• Radu Filip (Computer Science Faculty of Iasi)
  
• Phil Conan (Polytechnique de Montreal)