getting more efficiency along with safety from #SOA

20.9.25: addx/soa/

getting more efficiency along with safety:

10.19: summary:

. soa (service oriented architecture)

is expensive when it intervenes 

every call to a subprogram;

instead of calling soa mgt for every call,

we shouldn't be worried about an app making 

internal calls to parts of the same app

by the same author with the same privileges.

. a complement of soa controlling the calls,

is stack isolation controlling the returns.

reputation-based trust management

2.12: news.cyb/sec/reputation-based trust management:
2.14: summary:
. even if the NSA keeps vulnerabilities in place
so that they may continue accessing their backdoors;
they do not want you pawned by other nation states.
. they recommended "reputation management",
which I believe refers to
reputation-based trust management.

NSA`Tailored Access Operations`Rob Joyce:
. admins need to lock things down as far as possible;
whitelisting apps, locking down permissions,
patching as soon as possible,
and using reputation management.
. when up against a new piece of malware
it will be missed by Signature-based antivirus
but could still be caught by reputation.

reviewing the costs of SOA

31: addm/reviewing the costs of soa:
. when looking at SOA architecture,
how does that affect the
cross-module communications costs ?
there could be a devil in the details;
but, the bird's eye view is that
it could actually be quite minimal .

globalizing #SOA with web services

 1.30: web: cs/soa/globalizing SOA with web services
Filtering to Inspect XML: an Operational Framework for
Service Oriented Architecture Network Security
www.tacoma.uw.edu ... rbunge.pdf
Robert Bunge1, Sam Chung1, Barbara Endicott-Popovsky2, Don McLane1
1 Computing & Software Systems; Institute of Technology
University of Washington, Tacoma
{rbunge, chungsa, dmclane}@u.washington.edu
2 Center for Information Assurance and Cybersecurity
University of Washington, Seattle
endicott@u.washington.edu
1.30: summary of this paper:

#SOA -- where is #security today?

1.29: web.cs/soa/where is security today?:
. I was looking for updates on
how SOA is preventing malware;
instead, I find this claim about SOA's vulnerabilities:

"( Modern buffer overflows are more difficult to exploit
than Aleph One's
smashing the stack for fun and profit.
You should look into modern bypasses to ASLR
such as heap spraying or heap feng shui.
Attacks like jmp2reg (jmp2esp jump2ebx ect...)
are also interesting for bypasses for ASLR.
Attacking ActiveX components is fun.
I used H.D. Moore's AxMan with great success.
Here is the remote code execution exploit I found
using AxMan .
. Here are more exploits that I have written .
. The best fuzzer is by far PeachFuzz,
and writing some pit files for it
can be very fruitful research.
Buffer overflows and sql injection
are the most talked about,
but there are a couple hundred categories for vulnerabilities
and they are identified by CWE numbers.
Its worth exploring, I think it will surprise you
what NIST thinks a vulnerability is.

. that had nothing to do with SOA;
it should have been subtitled
"exploits you can avoid by using SOA" .

microsoft's changes for an insecure internet

5.18:  news.cyb/dev.net/silverlight killed by html5:
subodhnpushpak 2011:

Microsoft Silverlight is an application framework
for writing and running rich Internet applications,
with features and purposes similar to those of Adobe Flash.
. it's being replaced by html5 .

. the cool thing about it was
programming the browser with ironpython
-- or any other .net language --
instead of javascript .

6.10: why:

. the .NET system was designed for competing with java;
the cool idea at that time was mobile code;
but since internet security issues have gotten so thick,
the cool idea now is either minimizing code installs
by using web services with an html interface,
or controlling app quality
with something like Apple's App Store .

. now that html5 offers a multi-media experience,
the .NET and SilverLight plug-in's
are being discouraged as unnecessary installs .
. some apps may seem slow in a browser,
and those will need native code
that should be policed by an App Store .

. to replace .NET's multi-lang feature,
here's how your favorite languages
can be turned into javascript:
# for Python code:
. use Pyjamas, a port of Google Web Toolkit.
# for C, C++, Objective-C:
. use the Emscripten LLVM-to-JavaScript compiler
(eg, if your translator emits Objective-C,
then it can be converted to LLVM byte code,
which can finally be converted to JavaScript ).

. given the move away from mobile code,
Microsoft has evolved from .NET
and its new language C#,
back to a popular language, C++
with Component Extensions, C++/CX .
. its syntax borrows from C++/CLI
but targets native instead of managed code.
. Apple went through such a phase also
when it dropped their new lang, Dylan,
for the popular lang, C,
with oop extensions, Objective-C .
. the .NET developer framework was part of
WPF (Win' Presentation Foundation),
and Silverlight was a .NET-powered flash competitor;
the new platform using c++/CX
is called WinRT (Win' Run Time).

survey of programming architectures

11.15: web.adda/oop/architectures:

the categories of inheritance:

# type clustering (inclusion polymorphism):

. numbers are the classic type cluster;
that type's major subtypes have overlapping interfaces;
and they need a supertype to coordinate biop's
(binary operations; a function with 2 arg's;
eg, addition's signature is: +:NxN->N )
whenever the param's have unmatched subtypes
(eg, RxC->C, ZxN->Z, /:NxN->Q, ...).

type cluster/supervision models:
#coordinated:
. the set of polymorphic subtypes is fixed,
and the supertype knows how to convert between them;
because,
it knows the data formats of all its subtypes .
# translated:
. the supertype provides an all-inclusive
universal data format;
eg, numbers -> complex .
. all subtypes convert between that format
and their own .

type cluster/subtypes must include range constraints:
. range constraints are essential for efficiency
as well as stronger static typing;
because, range limits are what allow
direct use of native numeric types .
. typical native types include
{N,Z,R}{8,16,32,64,128} .

# type classing (Subtype polymorphism):
. declaring a type is a member of a class,
and is compatable with that class
by inheriting its interface;
the new type is then usable
anywhere the inherited class is . [12.31:
. the type class is defined by its interface;
any type following that interface
is considered a member of that class .
. it's not about sharing code by extension;
it's organizing hierarchies of compatability .]

# type cluster combined with type classing:
. the subtypes of a type cluster
can be type classed; eg,
a dimensioned number could inherit from int;
and then to coordinate with the numeric supertype
it uses functionality from int.type
to deal with these messages:
{ what is your numeric subtype?
, your numeric value?
, replace your numeric value with this one
} .
. with just that interface,
any subclass of any numeric subtype
can be used in any numeric operation . [12.31:
. all self-modifying operations ( x`f)
can be translated as assignments (x`= f(x));
so then the inherited subtype
provides all the transform code .]

#type classing without clustering:
11.20:
. without type clustering;
what does type classing do then?
are biop's supported? polymorphism?
. historical reasons for inheritance:
# polymorphism
# type compatability
# reuse of work .
. you want to extend a type's
structure and functionality,
not interfere with its code base,
and still be useful everywhere your ancestors are .

. in the popular oop model,
the inherited work is reused by
adding to an inherited type's
functionality and instance var'space
(creating a polymorphism in the type).
. there's type compatability because
the obj' can handle all the ancestor's
unary and self-modifying functions;
but, popular oop approaches differ on
how biop's are handled .

. the classic, math'al oop uses clusters, [12.31:
which can handle biop's because the supertype
has limited membership to its type class
and can thus know in advance
what combinations of subtypes to expect
among a biop's pair of arg's .
. in a system without clustering's
closed class of subtypes
then there is no particular type to handle
the coordination of mixed biop arg's .
(that mix can consist of any types in
one arg's ancestors, or their descendents).]

. if subtypes can redefine a biop,
then a biop's method might be arbitrated by:
# nearest common ancestor:
the arg' set's nearest common ancestor type;
# popular:
the first arg determines the method;
# translation:
. an inheritable type has a universal format
which inheritors convert to,
in order to use the root's biop method .]

# incremental composition:
. it can be simplifying to describe a type
in terms of how it differs from other types;
this case includes anything not considered to be
type clustering or subclassing .
. revisions such as removing inherited parts
can preclude type compatability;
in such cases, compatability could be declared
with the use of a conversion map .
. incremental composition provides
module operators for building in ways
familiar to lisp users:
code can read other code, modify it,
and then use it as a module definition .
[11.20:
. with incremental composition,
any inheritance behaviors should be possible;
but the built-in inheritance should be
simple, classic type clustering and classing
as described above .
. the directions of popular oop
are not helping either readability or reuse;
esp'y unrewarding is the ability to
inherit multiple implementations
that have overlapping interfaces .]

#frameworks:
11.15:
. generic types can implement frameworks:
a type is an interface with all code supplied;
a generic type
leaves some of its interface undefined
or optionally redefinable,
with the intent that parameter instantiations
are customizing the framework;
eg,
a typical gui framework would be impl'd as
a generic task type;
so that creating an obj' of that type
initiates a thread of execution
that captures all user input
and responds to these events by
calling functions supplied by the
framework's customizing init's .]

adda/oop/value types:
11.16:
. the classic use of oop is type clustering
as is done for numerics:
it provides users of the numeric library
with an effortless, automated way
to use a variety of numeric subtypes
while also employing static typing,
and enjoying any enhanced readability or safety
that may be provided by that .
. coercions and range checks can all be
tucked under the hood,
without requiring compliance from clients .
. this automation is possible because
the designer of a type cluster's supertype
is using subtype tags to determine
each value's data format .

. the supertype module is also
the only place to coordinate
multiple param's having unmatched subtypes;
after one param' is coerced to match the other,
operations involving matched binary subtypes
are then relegated to subtype modules .

11.19: intro to value`type:
. static typing generally means
that a var's allowed values are confined to
one declared type,
and perhaps also constrained;
eg, limited to a range of values,
or a specific subtype .
. if that declared type is a type cluster,
it's values will include a type tag
for use by the supertype module,
to indicate which of its subtype modules
is responsible for that data format .

. type.tags are sometimes seen as a way to
replace Static typing with ducktyping
(where the tag is used at run-time
to check that the given value has a type
that is compatible with the requested operation).
. type clustering, in contrast to ducktyping,
is static typing with polymorphism
(statically bound to the cluster's supertype);
and there, the purpose of the type.tag
is merely to allow the supertype module
to support a variety of subtypes,
usually for the efficiency to be gained
from supporting a variety of data formats;
eg,
if huge complex numbers won't be used,
then a real.tag can indicate there is
no mem' allocated for the imaginary component;
or,
if only int's within a certain range will be used,
then the format can be that of a native int,
which is considerably faster than non-native formats .

. the value's subtype (or value`type)
is contrasted with a var's subtype
to remind us that they need not be equal
as long as they are compatable;
eg,
a var' of type"real may contain
a value of type"integer;
because they are both subtypes of number,
and the integer values are a
subset of the real values
(independent of format).

. the obj's subtype puts a limit on
the value`types it can support;
eg,
while a var' of subtype"R16 (16bit float)
can coerce any ints to float,
it raises an exception if that float
can't fit in a 16-bit storage .

. another possibly interesting distinction
between var' types and value`types
is that value`types have no concept of
operating on self; [11.19:
a unary operation over a value`type
doesn't involve any addresses,
and there is nothing being modified .
. while popular oop has a var`address
modify itself with a msg,
eg, x`f;
classic oop would say that was an
assignment stmt plus a unary operation:
x`= x`type`f(x) -- shown here fully qualified
to indicate how modularity is preserved:
the function belongs to x's type .]

. adda can also enforce typing between
unrelated types like {pure number, Meters},
but the system depends on supertype designers
to correctly handle their own subtypes .

. in addition to the distinction between
{library, application} programmers,
there is also kernel mode:
the adda run-time manages all native types
so that any code that
could be responsible for system crashes
is all in one module .

10.23: news.adda/compositional modularity:
11.14: Bracha, Lindstrom 1992`Modularity meets Inheritance

We "unbundle" the roles of classes
by providing a suite of operators
independently controlling such effects as
combination, modification, encapsulation,
name resolution, and sharing,
all on the single notion of module.
All module operators are forms of inheritance.
Thus, inheritance not only is
not in conflict with modularity in our system,
but is its foundation.
This allows a previously unobtainable
spectrum of features
to be combined in a cohesive manner,
including multiple inheritance, mixins,
encapsulation and strong typing.
We demonstrate our approach in a language:
Jigsaw is modular in two senses:
# it manipulates modules,
# it is highly modular in its own conception,
permitting various module combinators to be
included, omitted, or newly constructed
in various realizations .

10.23: Banavar 1995`compositional modularity app framework:
11.14:

. it provides not only decomposition and encapsulation
but also module recomposition .
. the model of compositional modularity is itself
realized as a generic, reusable software arch',
an oo-app framework" Etyma
that borrows meta module operators
from the module manipulation lang, Jigsaw
-- Bracha 1992`modularity meets inheritance .

. it efficiently builds completions;
ie, tools for compositionally modular system .
. it uses the unix toolbox approach:
each module does just one thing well,
but has sophisticated and reliable mechanisms
for massive recomposition .
. forms of composition:
#functional: returns are piped to param's;
#data-flow: data filters piped;
#conventional modules: lib api calls;
# compositional modularity:
. interfaces and module impl's
operated on to obtain new modules .

. oop inheritance is a form of recomposition;
it's a linguistic mechanism that supports
reuse via incremental programming;
ie, describing a system in terms of
how it differs from another system .
. compositional modularity evolves
traditional modules beyond oop .

. that compositional modularity
sounds interesting,
what's the author been up to recently?
reflective cap'based security lang's!

Bracha 2010`Modules as Objects in Newspeak:

. a module can exist as several instances;
they can be mutually recursive .
. Newspeak, a msg-based lang has no globals,
and all names are late-bound (obj' msg's).
. programming to an interface (msg's vs methods)
is central to modularity .

. it features cap'based security:
# obj's can hide internals
even from other instances of the same class;
# obj's have no access to globals
thus avoiding [ambient authority]
(being modified by external agents) .
# unlike E-lang, Newspeak supports reflection .

Newspeak handles foreign functions
by wrapping them in an alien obj,
rather than let safe code
call unsafe functions directly .

--. this is the equivalent of SOA:
whatever you foreigners want to do,
do it on your own box (thread, module)
and send me the neat results .

newspeak for Strongtalk

12.26: adda/arch/newspeak for strongtalk:

[12.29:
Bracha, a proponent of pluggable types,
was concerned that it weakened security
to rely on datatypes rather than
use oop`ducktyping everywhere .
. datatypes make several leaps of faith:
# the compiler has correctly analyzed
the program's compliance to type compatibility;
# the compiler's optimizations
still maintain this compliance;
# changes to the environment don't bedevil
assumptions required by this compliance .]

. Bracha, a proponent of Strongtalk
(smalltalk with pluggable types)
has moved on to Newspeak
but expects a pluggable typesystem
can be integrated later .
. Newspeak's most notable difference
seems to be capability-based security (cap's);
let's review what that does
compared to oop's ducktyping .

. oop's ducktyping calls turned
anything like f(x)
into x`type-mgt( operation:f, arg:x),
and x's type-mgt provides this service
for anyone who asks;
ie, if the current account can use x,
then any app running under that account
has permission to use x;
[12.29: whereas,
cap's are object-specific permissions:
an object accepts a call only if
the caller possesses a permission that
# specifies that object, and
# doesn't preclude the requested operation .
. a process starts out with no cap's
except those needed to remain functional:
it can accept arg's, return results,
and modify its own local mem allotment .
. other capabilities require
special permission provided by employers
(the user, admin, or os kernel).]

12.26: caller id:
. cap's are giving each app their own id,
so that cap'based calls would also involve
the caller id; [12.29:
well,
it includes the concept of caller id;
like so:
cap's are awarded to particular id's,
and they are non-transferable;
so, then cap's are essentially a tuple:
(caller id, allowed object, allowed operations) .]

12.27: adda`plans:
. cap's can be controlled by
the run-time supervisor
instead of the current object's type-mgt .
. after the user has set limits on each app;
these become part of process records
(owned by supervision's task mgt),
and all attempts by a process
to communicate with others,
becomes a function of the capabilities:
eg, instead of asking to access the file system,
a process says things like,
"( let me modify the portion of filesystem
pointed at by my process record's writableFiles cap' .)
"( let me read all files within
my process record's readableFiles cap' ).

managing capabilities without encryption

12.7: adda/cstr/managing capabilities without encryption:
. in a read of capability-based security
I wondered if there was some way to
have capability enforcement
without having to encrypt all the shared pointers .
. related ideas include:
# Singularity's faster task switching
done by using ref's to shared mem'
instead of passing copies between modules;
# how to use pointers to shared resources
so that even though 2 concurrent sharers
were both active at different processors,
only one active sharer at a time
would have a useful link to the shared resource .
sketch of a possible design:
. a process can never reach out directly,
but is always accessing things via
pointers located in their header,
and only the supervisor can modify this header;
eg, the task scheduler .
. it's not enough to have possession of a pointer,
you've got to have a supervisor
copy it to your header;
so, it's like encryption,
in that it requires an authorization .
layers for when bugs happen:
. encrypted cap'pointers are being
another level of security; [12.25:
. cap'based is supposed to include
the soa idea:
. bugs are going to get into the system,
but in a software system that
connected it's modules
the same way https connects computers,
then it wouldn't matter bugs had invaded;
because each of the components is
being separately guarded by modularity
(not allowing direct access to state)
and is working only with ID'd clients
(not servicing anonymous agents).
. the idea of unencrypted header pointers
is assuming that
the system's runtime can be secured
which is not likely
on today's monolithic OS's .]

live obj's have a guest.tag

4.25: adda/{oop, concurrency}/live obj's have a guest.tag:
. type.tags could be shorter than a ptr
by being a node-specific typeId#,
where the term "(node)
is supposed to conjure up the idea of networking
as being a collection of communicating modules .
. a node-based library is specific to
either a computer or a user account .
. if a live object is passed between nodes
then how is the typeId associated with
an implementation of a type'mgt?
[4.29:
. a live obj' is sent from a guest node
to a host node;
the guest-host handshake starts by
associating a type'name with the
type'mgt's body of code,
and after that,
the host can then refer to that type
using a pair of both the guest#,
and the obj's typeid# .
. the handshake ends with the host
telling the guest or the messaging system
what the guest's guestID# is .
. after that,
all obj's come in from a guestID#,
and all obj's contain a type.tag that's
understood within the context of a given guest .]

soa (service oriented architectures)

3.22: web.addx/soa/openware options:
. I was really impressed by the bright ideas
in the book "(soa for dummies);
is there any openware project that embodies
or further documents those ideas? .

3.22 .. 3.23:
bk.addx/soa/Its Role in Your Connected Systems Strategy 2004:

. this 2004 article assumes soa starts with
a common language that we agree on in advance .
. we've seen businesses on the internet
agree on xml,
but that language should be used
only for the handshake,
which asks:
"(what binary language do you speak;
something more efficient than wordy xml? ) .

. reviewing what I learned in "(soa for dummies),
you design an soa sytem by arbitrarily choosing
a common binary language for your messaging system .
. then you provide a converter for each of your programs
that will translate between their command language
and your system messages language .
. a fundamental requirement of soa
is token-based (smart-carded) logged messaging,
where every interaction leaves a paper trail
so that while maleware can happen
it is always discovered, and the source known .


3.24: bk.addx/soa/token-based security

. make web services secure:

"(. use token-based security:
an STS [Security Token Service] that emits
SAML tokens that can be cached on the client
(like kerberos token but with open standards).
Your webservices can be secured with
the wsFederationBinding
and you can do access checks based on
saml assertions that contain claims.
. here's a post that shows a web client
but it applies to smart clients as well .)

. wiki`Security_token .

Web Services Trust Language:

"(Web Services Trust Language (or WS-Trust)
defines extensions that build on Web Services Security
to provide a framework for
requesting and issuing security tokens,
and to broker trust relationships.
WS-Trust describes:
1. Methods for issuing, renewing, and validating security tokens.
2. Ways to establish, access the presence of, and broker
trust relationships.
CICS supports the February 2005 version of the specification )

WS-Trust specification:

CICS can interoperate with
a Security Token Service (STS),
to provide more advanced authentication:
An STS is a Web service that acts as a
trusted third party
to broker trust relationships between
a Web service requester and provider.
In a similar manner to a
certificate authority in an SSL handshake,
the STS guarantees that the requester and provider
can "trust" the credentials
that are provided in the message.
This trust is represented through the
exchange of security tokens.
CICS acts as a Trust client
and can send two types of requests to an STS.
* validate the security token
in the WS-Security message header;
* exchange the security token for a different type,
enabling CICS to send and receive
from a wide variety of trust domains,
such as SAML assertions and Kerberos tokens.
. use SSL to secure the connection
between CICS and the STS.

. the meat: an open soa security std .


3.24: addx/soa/efficiency and accountability:

. security is slow because it involves
carding for permissions and logging uses;
therefore, the os applies security only to
accesses of obj's it deems are
critically in need of protection .
. the dev' too, can be asking for protection
of particular obj's, types, or type classes .
[3.26:
. the os`security is protecting the user,
while the dev`security is asking the os
for help with organizing large projects;
security helps find where the bugs originate .]
. logging interactions and param's
can determine a crash's cause
amidst multiple authors or products .

. copying is minimized to make logging cheap:
msg's from task queues are
requeued on the log's queue,
so then only a ptr is copied per instruction .

logging timestamps:
. in a strictly modular system,
a concurrent system may not need
to log a msg's {creation, executed} timestamps
in order to assign blame during a system problem;
[3.26: but,
it might be helpful, so it should be optional .]

3.25: sci.addx/soa/saas (sw as a service):
. may be keyword for soa token:
security done at the local level
rather than the web (where each process
also has its own processor) .

3.26: lib.addx/soa:
docs.oasis-open.org/ws-sx/
www.oasis-open.org/committees/tc_cat.php?cat=soa
www.oasis-open.org/committees/tc_cat.php?cat=security
. SCA Client and Implementation Model for C language.
. Service Component Architecture (SCA)
defines a biz model using a soa,
based on the concept of Service Components .

3.27: addx/gemini kernels:
look at this viral load:
> I just received a notification
> that I have used over 10GB of data this billing cycle,
> which is unusual (as I haven't been doing anything ...)
--. there should be
even in a monolithic system like linux
a gemini system, where a supervisor system would be
untouchable even by root
and this sup' would give you an honest reading
of things like the traffic you're generating .

securing the paste.buffer

addx/soa:

10.10: addm/securing the paste.buffer:

. to support both multitasking and also be safe,

app's need their own versions of paste.buffer .

. my current idea of a security app'

would hold passes and paste them in,

and then make sure my paste.buffer was cleared,

but it can't do that if other app's

can use the paste.buffer concurrently .

[12.24:

. this is where soa comes to the rescue:

the os needs to have secured connections between each app'

with journaling and tokens that leaves a paper trail

of which app's have been communicating .

. soa has the same architecture between app's

as the internet has between websites .

]