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

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
>

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
>>
> 
> 
> 

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

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

"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.