A Typed Model for Dynamic Authorizations

Security requirements in distributed software systems are inherently dynamic. In the case of authorization policies, resources are meant to be accessed only by authorized parties, but the authorization to access a resource may be dynamically granted/yielded. We describe ongoing work on a model for specifying communication and dynamic authorization handling. We build upon the pi-calculus so as to enrich communication-based systems with authorization specification and delegation; here authorizations regard channel usage and delegation refers to the act of yielding an authorization to another party. Our model includes: (i) a novel scoping construct for authorization, which allows to specify authorization boundaries, and (ii) communication primitives for authorizations, which allow to pass around authorizations to act on a given channel. An authorization error may consist in, e.g., performing an action along a name which is not under an appropriate authorization scope. We introduce a typing discipline that ensures that processes never reduce to authorization errors, even when authorizations are dynamically delegated.Comment: In Proceedings PLACES 2015, arXiv:1602.0325

Using higher-order contracts to model session types

Session types are used to describe and structure interactions between independent processes in distributed systems. Higher-order types are needed in order to properly structure delegation of responsibility between processes. In this paper we show that higher-order web-service contracts can be used to provide a fully-abstract model of recursive higher-order session types. The model is set-theoretic, in the sense that the meaning of a contract is given in terms of the set of contracts with which it complies. The proof of full-abstraction depends on a novel notion of the complement of a contract. This in turn gives rise to an alternative to the type duality commonly used in systems for type-checking session types. We believe that the notion of complement captures more faithfully the behavioural intuition underlying type duality.Comment: Added definitions of m-closed terms, of 'dual', and a discussion to show the problems of the complement functio

Rast: A Language for Resource-Aware Session Types

Traditional session types prescribe bidirectional communication protocols for concurrent computations, where well-typed programs are guaranteed to adhere to the protocols. However, simple session types cannot capture properties beyond the basic type of the exchanged messages. In response, recent work has extended session types with refinements from linear arithmetic, capturing intrinsic attributes of processes and data. These refinements then play a central role in describing sequential and parallel complexity bounds on session-typed programs. The Rast language provides an open-source implementation of session-typed concurrent programs extended with arithmetic refinements as well as ergometric and temporal types to capture work and span of program execution. To further support generic programming, Rast also enhances arithmetically refined session types with recently developed nested parametric polymorphism. Type checking relies on Cooper's algorithm for quantifier elimination in Presburger arithmetic with a few significant optimizations, and a heuristic extension to nonlinear constraints. Rast furthermore includes a reconstruction engine so that most program constructs pertaining the layers of refinements and resources are inserted automatically. We provide a variety of examples to demonstrate the expressivity of the language

A concurrent programming language with session types

Tese de mestrado em Engenharia Informática, apresentada à Universidade de Lisboa, através da Faculdade de Ciências, 2013Em computações concorrentes complexas onde os processos comunicam por troca de mensagens existe normalmente um elevado número de mensagens trocadas. Geralmente, estes programas são muito difíceis de implementar visto que a ordem e o tipo das mensagens enviadas e recebidas são muitas vezes alvos de erros dos programadores. Numa comunicação entre dois processos que partilham o mesmo meio de comunicação é necessário garantir que estes trocam as mensagens de forma correcta: quando um envia um valor de tipo inteiro, o outro deve estar a espera de receber um valor de tipo inteiro, quando um oferece um conjunto de opções, o outro deve estar pronto a selecionar uma dessas opções e quando um tem de terminar a sua interação nesse canal, o outro também deve terminar. Também é importante garantir a não ocorrência de condições de corrida, assegurando que durante uma comunicação entre dois intervenientes, outros não interferem. Por isso, é útil abstrair protocolos que governam as interações entre os intervenientes de uma comunicação descrevendo quando e quais são as mensagens trocadas entre eles. Temos então os tipos de sessão que descrevem as contínuas interações entre os diferentes parceiros de uma comunicação. Para definir quantos parceiros conhecem um dado canal de comunicação em qualquer ponto do programa, é possível qualificar o tipo de sessão, associado a esse canal, como linear ou partilhado. Os tipos qualificados como lineares representam extremidades de canais que apenas podem aparecer em exatamente um fio de execução, enquanto que os partilhados representam extremidades que podem ocorrer num número ilimitado de fios de execução. Deste modo podemos garantir que não existem condições de corrida, pois em situações sujeitas a tal pode-se usar tipos lineares. Mas por outro lado, se for necessário que muitos processos tenham acesso ao canal podemos usar tipos partilhados. Com vista a facilitar a programação concorrente, construímos uma nova linguagem de programação chamada SePi. Esta é uma linguagem de programação concorrente baseada no cálculo pi que usa tipos de sessão linearmente refinados para descrever as operações realizadas nos canais de comunicação. Esta linguagem concorrente, onde os processos comunicam de forma síncrona através canais bidirecionais (cada canal é definido por duas extremidades), permite que as interações entre processos sejam verificadas em tempo de compilação utilizando os tipos de sessão para descrever o tipo e a ordem das mensagens, bem como o número de processos que podem partilhar os canais. A linguagem SePi tem construtores de processos para enviar e receber uma mensagem, para representar a receção replicada, a composição paralela, com zero ou mais processos a serem executados concorrentemente, o processo condicional e a criação de novos canais definidos por duas extremidades. Os processos podem enviar mensagens de tipo inteiro, booleano, string ou extremidades de canais. Para além dos tipos primitivos, a linguagem apresenta também tipos para descrever o envio e receção de mensagens, a oferta e a seleção de opções, um tipo para representar canais onde não é possível ocorrer mais interações, tipos refinados e tipos recursivos. Por exemplo o tipo lin?boolean.lin! integer.end representa uma extremidade de um canal que recebe um valor booleano e de seguida envia um inteiro. Os tipos recursivos permitem efetuar a mesma operação, ou o mesmo conjunto de operações, no mesmo canal um número indeterminado de vezes. Os tipos refinados, uma forma de tipos dependentes, aparecem com o objetivo de especificar certas propriedades dos valores de um programa SePi anexando fórmulas a tipos. Estas fórmulas podem ser predicados não interpretados, na forma de p(v1, ..., vn), tensores na forma de A x A ou unit. Por exemplo, um cliente que queira efetuar um pagamento a uma loja utilizando o seu cartão de crédito quer ter a certeza que este é utilizado apenas uma vez e para cobrar a quantia certa. Os tipos de sessão não são suficientes para assegurar este comportamento, pois podemos garantir que a loja cobra um inteiro, mas não podemos garantir que cobra o montante exato da compra. No entanto podemos usar tipos refinados para especificar o montante que vai ser cobrado no cartão de crédito e o número de vezes que esta cobrança é feita. Um exemplo de tipos refinados é então {x:integer | charge(x , card)}. Para conseguirmos obter este comportamento, tratamos das fórmulas como se fossem recursos. Elas são introduzidas no sistema de tipos através do processo assume, passadas entre processos através dos tipos refinados e removidas através do processo assert. Existe outro conceito muito importante na nossa linguagem, a dualidade, que nos permite garantir que dois processos que partilham um canal comportam-se de forma complementar. Dizemos então que as duas extremidades de um canal têm tipos duais ou complementares. Isto é, quando uma extremidade é usada para enviar uma mensagem a outra deve ser usada para receber, quando uma é usada para selecionar uma opção então a outra tem de ser usada para oferecer um conjunto de opções. O tipo que define canais sem interação é dual dele próprio e os tipos primitivos e refinados não têm a função de dualidade definida. Por exemplo o tipo lin?boolean.lin!integer.end é dual de lin !boolean. lin?integer.end. Até agora descrevemos apenas a linguagem “base”. A versão mais recente da linguagem SePi é baseada na primeira mas apresenta mais construtores, tais como construtores derivados e abreviaturas. Como abreviaturas temos o uso opcional do qualificador linear ou o uso de um * para representar uma classe comum de tipos partilhados, o operador dualof que permite obter o tipo dual de outro, e a composição paralela de zero valores que também é opcional. Como construtores derivados dos da linguagem base, temos o envio e receção de múltiplos valores, a definição de processos (que deriva de uma criação de um novo canal seguido de uma receção replicada em paralelo com o resto do programa) e a declaração de tipos mutuamente recursivas. A linguagem SePi também apresenta expressões binárias, como as aritméticas, lógicas e relacionais, ou expressões unárias, como a negação. O nosso objetivo ao introduzir estes novos construtores é o de capturar com uma sintaxe especial, os idiomas e padrões de programação mais comuns e assim reduzir o número de linhas de código SePi e eventuais erros associados. Esta linguagem é baseada nos trabalhos de Vasconcelos e Baltazar et al. Para facilitar a programação em SePi desenvolvemos um plugin para o Eclipse de modo a permitir a validação sintática e semântica, completação e refactoring de código, bem como interpretação. Para além disso, implementamos também uma versão para a linha de comandos. A nossa implementação foi feita utilizando a framework Xtext que permite o desenvolvimento de novas linguagens de programação e plugins para o Eclipse. Sendo que o Xtext gera vários dos componentes de um compilador/interpretador, podemos dividir a nossa implementação em quatro partes: escrita da gramática, implementação de um mecanismo para verificar se todas as variáveis de um programa estão devidamente declaradas, implementação do algoritmo de verificação de tipos e escrita do interpretador. interpretador é baseado na máquina abstrata de estados de Turner. Este trabalho resulta assim numa linguagem de programação concorrente, baseada no cálculo pi monádico onde a comunicação entre os processos de um programa é governada por tipos que resultam de uma combinação entre tipos de sessão e tipos linearmente refinados.We present a concurrent programming language based on the monadic pi-calculus, where communication among processes is governed by linearly refined session types. In SePi, processes communicate synchronously via bi-directional channels (defined by two end-points) by message-passing. Interactions on channels are statically verified against session types describing the type and order of messages exchanged, as well as the number of processes that may share a channel. We first implement a core language where there are constructs to send and receive (including a form of replicated input) messages, select and offer a set of options, parallel composition, conditional and channel creation. In order to allow describing more precise properties of programs, SePi includes assume and assert primitives at the process level and refinements at the type level. Refinements are treated linearly, which allows a finer, resource-oriented use: each assumption is asserted exactly once, and conversely each assertion is also assumed exactly once. On top of this core language we provide some abbreviations and some derived constructs with the purpose of facilitate code development, resulting in the current version of SePi. We introduced a few abbreviations, as for instance the dualof operator or the optional qualifiers, and derived constructs, such as the input and output of multiple values and mutually recursive process definitions and type declarations. SePi is currently implemented as an Eclipse plugin, allowing code development (and interpretation) with the usual advantages of an IDE, such as syntax highlighting, syntactic and semantic validation, code completion and refactoring. The syntax, type system and operational semantics of SePi are introduced in references and the interpreter is based on Turner’s abstract machine