www.digitalmars.com         C & C++   DMDScript  

D - Compile time support for Run-time Security

reply andy <acoliver apache.org> writes:
One of the things that is really nice about D is that its pretty dern
light weight and efficient by comparison to most language coming out of 
the wood work today.

However, while this is D's power, its also its weakness in the realm of 
Security.

D allows all "Things" to have access to the underlying runtime library, 
anything out there, call any function of phobos etc.

It seems to me that most of the languages that support limiting this 
either through policy configuration, etc. are all "Virtual Machine" 
languages.  (I'm NOT distinguishing here between language and "all that 
other stuff to support it" and I'm aware of it)

I however am not sure that it is essential to use a VM.  It seems to me 
that the compiler could chose to compile in runtime support for security 
policy or not and the caller of a given object or call should be able to 
determine what priviledges it is to be granted.

Configuring this could be left up to the implementer, with basic support 
supplied through an API.

While I realize this is not as secure as a VM or something of the such, 
I think it could provide a substantial layer of protection for a number 
of web applications.

Does anyone have any thoughts on this?  Walter, any plans to provide 
such "security"?

I can provide some implementation suggestions if anyone is interested.

-Andy
Sep 07 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
I don't think this is possible with a language designed to allow access to
the bare metal. Heck, you can always just link in a C function to get around
any D protections. The sandbox here should be the operating system
allocating a virtual address space for the process, and then using privilege
levels.

"andy" <acoliver apache.org> wrote in message
news:3D7A44B2.2080609 apache.org...

 One of the things that is really nice about D is that its pretty dern
 light weight and efficient by comparison to most language coming out of
 the wood work today.

 However, while this is D's power, its also its weakness in the realm of
 Security.

 D allows all "Things" to have access to the underlying runtime library,
 anything out there, call any function of phobos etc.

 It seems to me that most of the languages that support limiting this
 either through policy configuration, etc. are all "Virtual Machine"
 languages.  (I'm NOT distinguishing here between language and "all that
 other stuff to support it" and I'm aware of it)

 I however am not sure that it is essential to use a VM.  It seems to me
 that the compiler could chose to compile in runtime support for security
 policy or not and the caller of a given object or call should be able to
 determine what priviledges it is to be granted.

 Configuring this could be left up to the implementer, with basic support
 supplied through an API.

 While I realize this is not as secure as a VM or something of the such,
 I think it could provide a substantial layer of protection for a number
 of web applications.

 Does anyone have any thoughts on this?  Walter, any plans to provide
 such "security"?

 I can provide some implementation suggestions if anyone is interested.

 -Andy
Sep 07 2002
parent reply andy <acoliver apache.org> writes:
Okay well thanks for considering it.

More I was thinking that one could specify by default that a child
could not call C functions.  And if it wanted to allow specific calls
it could allow them.

Languages with this kind of "sandbox" as you call it are strongly 
suggested by the Linux Security FAQ: 
http://www.tldp.org/HOWTO/Security-HOWTO/index.html and other security 
references.

While I understand that D is a more bare metal language than most 
langauges that do provide these services, it provides other features 
such as garbage collection that are traditionally not provided in bare 
metal languages.

The way I see this working is:

DCallerClass     DChildClass


DChildClass2     DClassSecurityDescriptorForChildClass
                  DClassSecurityDescriptorForChildClass2


ClassSecurityDescriptor objects just hold property-value pairs.  By 
default a class which is insantiated via a security descriptor can 
basically do nothing.  You can specify some kind of wild card "Do 
anything" to subvert protection if needed.

DClassSecurityDescriptorForChildClass specifies that it can make calls 
to objects within its own module, it cannot do IO or anything else of 
substance.

DClassSecurityDescriptorForChildClass2 specifies that it can call the 
printf function as well as any class in its own module.

DCallerClass instantiates DChildClass with the 
DClassSecurityDescriptorForChildClass.  DCallerClass insantiates 
DChildClass2 with the DClassSecurityDescriptorForChildClass2. 
DCallerClass passes a reference to the DChildClass2 into DChildClass.
It then executes the run() method on DChildClass which executes a method 
on DChildClass2 and prints "hello secure world" on the screen.

Because DCallerClass was instantiated without a security descriptor, it 
has permission to do anything it wants.  It allowed DChildClass and 
DChildClass2 some subset of this.  In this case it allowed DChildClass 
to make calls to DChildClass2.  Because DCallerClass allowed 
DChildClass2 to make a call to printf.

As for how to do this in the compiler I can only make some guesses.  A 
different form of a constructor (maybe new Bla() : descriptorInstance;) 
would be used.  In the event a construction was done with a security 
descriptor, the class is linked with all method calls being done via 
that security descriptor.

It doesn't seem totall unfeasible to me, but I haven't given it that 
much thought.

-Andy

Walter wrote:

 I don't think this is possible with a language designed to allow access to
 the bare metal. Heck, you can always just link in a C function to get around
 any D protections. The sandbox here should be the operating system
 allocating a virtual address space for the process, and then using privilege
 levels.
 
 "andy" <acoliver apache.org> wrote in message
 news:3D7A44B2.2080609 apache.org...
 

One of the things that is really nice about D is that its pretty dern
light weight and efficient by comparison to most language coming out of
the wood work today.

However, while this is D's power, its also its weakness in the realm of
Security.

D allows all "Things" to have access to the underlying runtime library,
anything out there, call any function of phobos etc.

It seems to me that most of the languages that support limiting this
either through policy configuration, etc. are all "Virtual Machine"
languages.  (I'm NOT distinguishing here between language and "all that
other stuff to support it" and I'm aware of it)

I however am not sure that it is essential to use a VM.  It seems to me
that the compiler could chose to compile in runtime support for security
policy or not and the caller of a given object or call should be able to
determine what priviledges it is to be granted.

Configuring this could be left up to the implementer, with basic support
supplied through an API.

While I realize this is not as secure as a VM or something of the such,
I think it could provide a substantial layer of protection for a number
of web applications.

Does anyone have any thoughts on this?  Walter, any plans to provide
such "security"?

I can provide some implementation suggestions if anyone is interested.

-Andy
Sep 08 2002
parent reply Mark Evans <Mark_member pathlink.com> writes:
I'm glad to see someone is mentioning security.  Usually security is tacked on
after the fact.  (I wish that security had been considered in the design of our
30-year-old email message standard.)

I have no opinion on the particular suggestion here, but do think that it's
worth considering D's support for commercial software products in need of
various protections.  For example -- code obfuscation (compiler renaming of all
symbols with junk names); on-the-fly binary code encryption/decryption;
self-modifying code; hash functions; computer station uniqueness identifiers.

Mark
Sep 08 2002
parent "Walter" <walter digitalmars.com> writes:
"Mark Evans" <Mark_member pathlink.com> wrote in message
news:algdvm$2omq$1 digitaldaemon.com...

 I'm glad to see someone is mentioning security.  Usually security is


tacked on

 after the fact.  (I wish that security had been considered in the design


of our

 30-year-old email message standard.)


Security is an important issue. One issue is preventing malicious D code
from running - that doesn't make too much sense for D since D is a systems
development language. It's more an operating system issue. The next security
issue is making security bugs in existing D applications less exploitable -
for example, the infamous buffer overflow bug. Since D has dynamic arrays,
and they are convenient to use, it is much less likely for a poorly written
D app to suffer from buffer overflow bugs than a poorly written C app. D
also has various runtime checks and contracts which can be used to increase
security of a trusted app.


 I have no opinion on the particular suggestion here, but do think that


it's

 worth considering D's support for commercial software products in need of
 various protections.  For example -- code obfuscation (compiler renaming


of all

 symbols with junk names); on-the-fly binary code encryption/decryption;
 self-modifying code; hash functions; computer station uniqueness


identifiers.

Since D is easy to parse, it makes it that much easier to write code
obfuscators.
Sep 08 2002
prev sibling parent Jonathan Andrew <jon ece.arizona.edu> writes:
I think one big step in this direction is ensuring the standard library is
free of potential buffer overflow exploits. Many of the functions in
the C standard library are vulnerable to buffer overflows, hopefully
phobos will be better in this regard.

-Jon
Sep 08 2002