Meccanismi di access control in SELinux

Save this PDF as:
 WORD  PNG  TXT  JPG

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "Meccanismi di access control in SELinux"

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Sistemi Operativi Meccanismi di access control in SELinux Anno Accademico 2012/2013 Candidato: Stephanie Cané matr. N

2 A tutti coloro che lottano per qualcosa in cui credono.

3 Indice Indice... III Introduzione... 4 Capitolo 1: Introduzione a SELinux Cenni sui meccanismi di access control La storia di SELinux Architettura di SELinux Cenni sull architettura del kernel Cenni sul SELinux Policy Language Capitolo 2: Type Enforcement Tipi, Attributi e Alias Access Vector Rules Type Rules Capitolo 3: Role-Based access control e Multilevel Security Role-Based access control Multilevel security Conclusioni Bibliografia... 30

4 Introduzione Hello netlanders, Due to a project I'm working on (in minix), I'm interested in the posix standard definition. Could somebody please point me to a (preferably) machine-readable format of the latest posix rules? Ftp-sites would be nice. Tutto ebbe inizio da questo messaggio che Linus Benedict Torvalds inserì su usenet il 3 luglio 1991: il progetto a cui si riferisce Torvalds è Linux, noto sistema operativo UNIXlike open-source. Il più famoso progetto GNU eredita il proprio modello di sicurezza da UNIX, sistema operativo multiutente per il quale la sicurezza assume un ruolo cruciale. Un sistema contiene molti oggetti che necessitano di protezione, sia hardware (CPU, segmenti di memoria) che software (processi, file). L access control, come definito da Sandhu [2], permette di prevenire violazioni di sicurezza sul sistema, limitando ciò che un soggetto può fare sugli oggetti del sistema. È importante distinguere, come specificato da Sandhu [2], le politiche dai meccanismi di access control: le politiche rappresentano delle linee guida di alto livello che specificano cosa deve essere protetto e da chi, mentre i meccanismi sono funzioni hardware di basso livello che implementano le politiche. In generale non esiste una politica migliore delle altre, ma esistono politiche che assicurano una maggior protezione del sistema; ciò nonostante non è possibile fare un confronto da questo punto di vista in quanto ogni 4

5 politica deve essere contestualizzata in base all uso per cui il sistema è stato adibito. Esistono infatti sistemi che richiedono flessibilità e in tal caso una politica di access control troppo rigida risulterebbe inappropriata. Esistono tre categorie di politiche di access control: discretionary access control, mandatory access control e role-based access control. La discretionary access control policy è la principale politica di access control, la quale permette ad un soggetto di poter dire chi può o non può accedere a determinate risorse. Questo tipo di politica è flessibile, tuttavia non impone alcun vincolo all utente abilitato di concedere gli stessi permessi a terzi. Bisogna infatti sempre tener presente che non è l utente in sé e per sé ad accedere ad un oggetto, ma sono i programmi che vi accedono a nome dell utente, e non tutti i programmi sono benevoli. La sicurezza standard in Linux è di tipo discretionary. Nella politica mandatory access control, invece, la decisione su chi può o non può accedere ad una determinata risorsa non viene più presa da un soggetto in quanto l obiettivo principale in questo tipo di politica è la riservatezza delle informazioni. Esistono diversi meccanismi di mandatory access control tra i quali si citano TOMOYO Linux, lanciata nel marzo 2003 e sponsorizzata dalla NTT DATA Corporation nipponica, AppArmor e SELinux. Nel corso del tempo a queste due politiche sono state proposte diverse alternative, le quali hanno cercato di coniugare i punti di forza di entrambe. In particolare si parla di una politica role-based access control basata sul ruolo che gli utenti hanno in un sistema. Dunque le autorizzazioni per l accesso ad un determinato oggetto non vengono specificate per ogni utente ma per ogni ruolo, che può essere visto come un insieme di azioni e di responsabilità, come definito da Sandhu [2]. Lo scopo del presente elaborato è quello di trattare uno dei meccanismi di access control citati in precedenza: SELinux. Nel primo capitolo verrà introdotto SELinux fornendo cenni sulle sue implementazioni e sul contesto storico e infine analizzandone architettura e linguaggio. Nel secondo capitolo verrà analizzata in dettaglio la principale implementazione di SELinux, ovvero type enforcement (di tipo mandatory) mentre nel terzo capitolo si tratterà di ulteriori implementazioni (role-based e multilevel security) che basandosi sul type enforcement lo vincolano maggiormente. 5

6 Capitolo 1: Introduzione a SELinux SELinux (Security Enhanced Linux) è una tecnologia per la sicurezza del sistema operativo che rappresenta un implementazione di mandatory access control nel kernel Linux. L obiettivo dei ricercatori di SELinux è stato quello di creare un complemento al sistema operativo che ne garantisse la sicurezza sia per quanto concerne riduzione delle vulnerabilità presenti in esso, sia per la realizzazione di quegli obiettivi di sicurezza quali la riservatezza, l integrità e la robustezza dei dati. 1.1 Cenni sui meccanismi di access control Il meccanismo MAC più comune è il Multilevel Security (MLS), nel quale ad ogni soggetto e ad ogni oggetto del sistema viene assegnato un livello di sicurezza (ad esempio pubblico e segreto) che ne indica la sensibilità delle informazioni, ovvero i potenziali danni che scaturirebbero da una divulgazione non autorizzata delle stesse. In figura tratta da [1] è illustrato il modello di sicurezza MLS, per il quale valgono le seguenti: un soggetto può scrivere e leggere su e da un oggetto dello stesso livello; un soggetto con livello più alto di un oggetto può leggere su quell oggetto ma non può scrivere su di esso; un soggetto con livello più basso di un oggetto può scrivere su quell oggetto ma non può leggere da esso. 6

7 A titolo esemplificativo, si supponga di avere due server Apache come riportato da Walsh [4], di cui il primo ha un livello di sicurezza di tipo secret mentre il secondo è di tipo top secret. Se il processo Apache di tipo secret viene violato, l hacker è in grado di leggere il contenuto del server di livello secret, ma non può leggere quello di livello top secret proprio grazie a MLS. Se invece viene attaccato il processo Apache di tipo top secret, l hacker può leggere sia il contenuto del server di tipo top secret che quello di tipo secret. Concludendo, MLS è stato implementato con l obiettivo di evitare la disseminazione di informazioni dai livelli alti ai livelli più bassi, salvaguardando in tal modo la riservatezza dei dati. Tuttavia, proprio per questo motivo, presenta una rigidità non necessaria in tutti i sistemi. SELinux adotta un meccanismo MAC più flessibile che prende il nome di Type Enforcement (TE), il quale permette di soddisfare anche altri obiettivi di sicurezza oltre la riservatezza, permettendo alla società che ne fa uso di poter definire una politica di sicurezza adeguata ai propri bisogni. In particolare ad ogni oggetto ed ad ogni soggetto è assegnato un security context costituito da tre elementi: user, role e type identifier. Affinché ad un soggetto venga concesso l accesso ad un oggetto, è necessario che il type identifier del soggetto sia autorizzato ad accedere al type identifier dell oggetto, indipendentemente dall identità del soggetto. Quello che essenzialmente differenzia MLS dall approccio adottato da SELinux, è che mentre il primo è predefinito, il secondo di default non concede l accesso a nessuno: saranno le politiche specificate dall organizzazione a decretare l accesso o meno a determinate risorse, permettendo in tal modo una modellazione delle politiche di sicurezza perfettamente adeguata alle esigenze del sistema. L insieme di regole che gestiscono gli accessi si trovano in un file speciale 7

8 detto SELinux policy, il quale verrà caricato nel kernel durante il processo di boot. SELinux implementa anche una politica di tipo Role-Based basata su TE: in tal caso i ruoli sono usati per raggruppare i tipi identificativi dei soggetti. Si vuole precisare però che la politica RBAC non garantisce l accesso, ma di fatto vincola maggiormente la politica TE. 1.2 La storia di SELinux SELinux trae le sue origini da ricerche effettuate negli anni 80 sulla sicurezza dei sistemi operativi e sui microkernel. Agli inizi degli anni 90 i ricercatori dell NSA (National Security Agency) e della SCC (Secure Computing Corporation) lavorarono insieme al sistema operativo DTMach (Distribute Trusted Mach), il quale combinava i risultati raggiunti dal progetto LOCK (Logical Co-processing Kernel) e dal progetto Trusted Mach, come scritto da Ivashko [5]. Il progetto LOCK nacque per sviluppare un sistema di sicurezza affidabile fornendo una sicurezza multilivello, mentre il progetto Trusted Mach incorporò i controlli di sicurezza nei sistemi operativi a microkernel [1]. Successivamente DTMach divenne parte del progetto Distributed Trusted Operating System (DTOS) la cui architettura, grazie agli sforzi congiunti dell NSA, SCC e dell università dello Utah, fu integrata nel sistema operativo Fluke dando vita ad un nuovo progetto chiamato Flux, il quale a sua volta ha portato allo sviluppo dell architettura Flask [5]. Nell estate del 1999 l NSA cominciò ad implementare l architettura di sicurezza Flask nel kernel di Linux e nel dicembre del 2000 rilasciò pubblicamente il suo lavoro sotto il nome di SELinux, acronimo di Security Enhanced Linux, il quale venne originariamente fornito come una serie di patch per il kernel 2.2.x. Durante il Linux Kernel Summit del 2001 ad Ottawa, in Canada, i rappresentanti dell NSA proposero di integrare SELinux nel kernel 2.5. Tuttavia la proposta venne respinta da Linus Torvalds e da altri sviluppatori i quali non ritennero SELinux la migliore soluzione possibile [5]. Dunque fu iniziato il progetto Linux Security Modules (LSM), il quale rappresentò un sottosistema del kernel Linux atto all integrazione di moduli di sicurezza in quest ultimo. Dopo circa 3 anni il sottosistema LSM è stato incluso dal kernel Linux versione 2.6 in poi. I moduli di sicurezza attualmente 8

9 supportati sono TOMOYO Linux, AppArmor, SMACK e SELinux. Tuttavia solo grazie all interesse di Red Hat, SELinux è diventato una parte della distribuzione convenzionale di Fedora Core Linux: in questo modo se ne è provata l efficacia anche in ambito aziendale. Agli inizi del 2005, Red Hat ha rilasciato l Enterprise Linux version 4 avente SELinux abilitato di default [1]. 1.3 Architettura di SELinux Come visto nel paragrafo precedente, SELinux è integrato nel kernel grazie al modulo LSM. In questo paragrafo si analizzerà l architettura del kernel e il policy language di SELinux Cenni sull architettura del Kernel SELinux rappresenta un aggiunta al sistema di controllo degli accessi standard di Linux, di conseguenza è consultato solo se è stato validato l accesso ad una determinata risorsa dalla politica DAC. Si veda a tal proposito la seguente figura tratta da [1]. 9

10 Il modulo LSM, nel quale è implementato SELinux, è collegato al kernel grazie ad un insieme di hooks i quali agiscono solo se è stata superata la verifica di accesso da parte della politica discretionary: in altre parole la politica di controllo di SELinux non sostituisce quella DAC, ma ne rappresenta un complemento al fine di ottenere un controllo più efficiente. Un aspetto da sottolineare è quello riguardante la fase di auditing di SELinux: questa fase rappresenta un analisi a posteriori delle richieste di accesso e fornisce il supporto necessario per analizzare il comportamento di un utente nel sistema. Tuttavia se un soggetto non supera la verifica DAC, SELinux non agirà perché non sarà necessario, e di conseguenza l accesso negato non verrà riportato in quando l auditing non sarà proprio intervenuto. Ci si soffermi ora sul modulo LSM in figura tratta da [1]. Le tre componenti fondamentali di quest ultimo sono: Security Server, Kernel Object Managers e Access Vector Cache (AVC). La politica di access control è implementata come una serie di regole nel blocco Security Server, il quale viene caricato dall utente grazie alla Policy Management Interface. In questo modo è possibile cambiare la logica di controllo senza modificare il resto 10

11 dell architettura. Gli object managers, ovvero gli hooks dell LSM, sono responsabili di far rispettare le decisioni prese dalla politica specificata nel Security Server, concedendo o negando l accesso alle risorse del kernel. Infine si ha l Access Vector Cache il quale immagazzina le decisioni precedentemente valutate dal Security Server in modo da velocizzare analoghe richieste future. Inoltre l AVC rappresenta un interfaccia tra il Security Server e i kernel object managers. Una delle caratteristiche peculiari di SELinux è che la sua architettura può essere applicata sia alle risorse nello userspace che a quelle nel kernel space. È importante sottolineare questo aspetto a causa delle origini di SELinux dalle ricerche sui microkernel, nei quali la gestione delle risorse era governata da userspace server. Esistono due modi differenti per fornire un supporto agli userspace object managers: l utilizzo del kernel security server e l istituzione di un policy server. Per quanto concerne il primo metodo si faccia riferimento alla seguente figura tratta da [1]. 11

12 In questo caso lo userspace object manager si comporta similmente al kernel object managers, richiedendo l accesso ad una determinata risorsa direttamente al security server. Esistono però due differenze fondamentali tra l object manager dello userspace e quello del kernel space: la prima è che ogni userspace object manager deve avere un proprio AVC, le cui funzionalità sono implementate nella libreria libselinux; la seconda è che lo userspace object manager non possiede gli hooks, che sono un concetto strettamente legato al kernel. Il secondo metodo per supportare lo userspace object manager è quello di aggiungere un policy server nello userspace [1]. Esso è costituito da due server: userspace security server (USSS) e policy management server (PMS). Il PMS crea gli object classes che rappresentano le risorse e controlla che la politica adottata sia rispettata su quest'ultime. L USSS è utilizzato dallo userspace object manager per richiedere l accesso ad una determinata risorsa. 12

13 1.3.2 Cenni sul SELinux Policy Language Come si è visto nel sottoparagrafo precedente la politica di access control non è statica ma è definita da un utente (o più utenti) il quale, attraverso la Policy Management Interface, carica le specifiche nel Security Server del modulo LSM. Per creare un policy file è necessario compilare, tramite un programma detto checkpolicy, un policy source file (tipicamente chiamato policy.conf). Checkpolicy analizzerà sintassi e semantica del file sorgente e se tutto è scritto correttamente compilerà il file dando luogo ad un binary policy file leggibile dal loader del kernel. In figura tratta da [1] è presente la schematizzazione di un tipico policy source file. La prima sezione riguarda la definizione delle classi del Security Server e dei permessi specificati su ogni classe. La seconda sezione è quella in generale più ampia e contiene tutte le dichiarazioni di tipo, le regole TE, i ruoli e gli utenti usati nella politica. La successiva sezione contiene invece i vincoli, i quali limitano ulteriormente la politica TE. Si noti che, ad esempio, il MLS è definito come una serie di vincoli. L ultima sezione contiene invece le specifiche per la catalogazione di tutti gli oggetti perché, come è stato 13

14 già detto in precedenza, tutti gli oggetti devono avere un proprio security context. Tipicamente SELinux è implementato monoliticamente, ovvero checkpolicy dà luogo ad un unico file binario che sarà caricato nel kernel. Per rendere la politica modulare, è possibile utilizzare due metodologie differenti: sources modules e loadable modules. Nel primo caso si creano file sorgenti modulari i quali vengono collegati tra di loro tramite shell scripts, macro e makefile, come mostrato nella seguente figura complessiva tratta da [1]. Nel secondo caso invece, utilizzando una recente estensione di checkpolicy e un compilatore di moduli detto checkmodule, si costruiscono moduli caricabili nel kernel l uno indipendentemente dall altro. In altre parole si crea un modulo base monolitico e successivamente si creano dei loadable modules che andranno ad ampliare il modulo base secondo le esigenze. 14

15 Capitolo 2: Type Enforcement Type Enforcement è il meccanismo MAC adottato da SELinux. Esso è costituito da un insieme di regole che determinano quali soggetti possono accedere a determinate risorse. Esistono due tipologie di regole: Access Vector (AV), che garantisce l accesso ad una risorsa o l auditing, e le type rules che invece riguardano il labeling. Il Type Enforcement opera sui type identifier associati a ciascun soggetto e a ciascun oggetto del sistema. Si vuole sottolineare che gli eventuali accessi vengono concessi ai programmi e non agli utenti. Gli esempi e le figure che seguiranno in questo capitolo sono tratti da [1]. 2.1 Tipi, Attributi e Alias I tipi rappresentano la chiave di volta di tutto il meccanismo type enforcement: grazie ad essi è possibile specificare le regole che permettono l accesso alle risorse. Per semplificare l uso di questi elementi fondamentali del sistema, si fa ricorso ad attributi e alias: gli attributi permettono di riferirsi a più tipi grazie ad un unico nome (l attributo appunto), mentre un alias ne è semplicemente un sinonimo. Prima di utilizzare un tipo è necessario dichiararlo. La dichiarazione può essere fatta anteponendo al nome del tipo la parola type. La sintassi per la dichiarazione di un tipo è la seguente: type type_name [ alias alias_set ] [, attribute_set]; nella quale type_name può avere lunghezza arbitraria e contenere caratteri ASCII, numeri, un trattino basso o un punto. Gli alias_set devono soddisfare le stesse regole 15

16 sintattiche richieste per il nome del tipo, tuttavia è possibile specificare più di un alias utilizzando le parentesi graffe in questo modo: alias {aliasa_t aliasb_t}. Anche gli attribute_set, come gli alias_set, possono essere molteplici: in tal caso per indicarli nella dichiarazione del tipo basta elencarli separandoli con una virgola. L uso degli attributi rappresenta un notevole aiuto nella gestione dei tipi: infatti non bisogna dimenticare che ogni soggetto e ogni oggetto presente nel sistema ha un proprio tipo identificativo e dunque potremmo avere centinaia di migliaia di tipi. A scopo esemplificativo si supponga di voler concedere ad un programma di tipo backup_t, la possibilità di effettuare appunto il backup dei file di un sistema. Secondo la politica TE per ogni singolo file (ognuno con un proprio type identifier) si dovrebbe specificare la regola che ne permette l accesso al programma di tipo backup_t. Data la quantità di file in un sistema ciò si tradurrebbe in centinaia di regole allow. Per sopperire a questo problema si ricorre all uso degli attributi, i quali permettono di raggruppare diversi tipi. In questo modo infatti si potrebbe semplicemente definire un attributo file_type e scrivere una sola regola che garantisca l accesso del programma di tipo backup_t a tutti gli oggetti del sistema aventi attributo file_type. La sintassi per la dichiarazione di un attributo è la seguente: attribute attribute_name; dove attribute_name gode delle stesse specifiche sintattiche del type_name visto in precedenza. Si noti però che gli attributi e i tipi si trovano nello stesso namespace: di conseguenza non possono avere lo stesso nome. Inoltre è consuetudine scrivere alla fine del nome del tipo _t mentre non si usa posporre nulla al nome dell attributo proprio per permettere di distinguerli a prima vista. Per associare un attributo ad un tipo si usa la seguente sintassi: type type_name, attribute_name; Bisogna tuttavia prestare attenzione nell associare degli attributi ad un tipo, onde evitare accessi non desiderati. A questo proposito si consideri il seguente esempio: type httpd_t; type httpd_user_content_t; 16

17 type backup_t; type shadow_t; attribute file_type; attribute httpdcontent; type httpd_user_content_t, file_type, httpdcontent; type shadow_t, file_type; allow backup_t file_type : file read; allow httpd_t httpdcontent : file read; Le prime quattro righe rappresentano dichiarazioni di tipo, nello specifico con httpd_t si vuole indicare il tipo identificativo di un web server, con httpd_user_content_t il tipo identificativo di dati utente presenti sul web server, con backup_t il tipo di un programma che permette di effettuare il backup dei dati di un sistema e con shadow_t il tipo del file shadow di Linux (particolare file contenente tutte le password del sistema). La quinta e la sesta riga sono dichiarazioni di attributi. La settima e l ottava riga rappresentano l associazione degli attributi ai tipi, in particolare si associa al tipo identificativo dell utente che può accedere al web server gli attributi file_type e httpdcontent, mentre si associa al tipo shadow_t l attributo file_type. Le ultime due righe rappresentano infine le vere e proprie regole di accesso che permettono rispettivamente la lettura di oggetti aventi attributo file_type da parte del tipo backup_t, e la lettura di oggetti aventi attributo httpdcontent da parte del tipo httpd_t. In questo esempio l utilizzo di molteplici attributi si rivela di fondamentale importanza: se così non fosse e si avesse il solo attributo file_type associato sia al tipo shadow_t che al tipo httpd_user_content_t, quando si specifica la regola allow httpd_t file_type : file read non si permetterebbe solo la lettura al tipo httpd_t (che si ricorda rappresenta il web server nel presente esempio) di tutti i file aventi attributo file_type (e dunque ai dati utente presenti sul web server), ma si consentirebbe in questo modo anche l accesso al file shadow, cosa ovviamente indesiderata. È possibile associare degli attributi ad un tipo in maniera non contestuale alla 17

18 dichiarazione del tipo, utilizzando la seguente sintassi: typeattribute type_name attrib_names; In tal modo, in riferimento all esempio visto in precedenza, le seguenti righe: type httpd_user_content_t; typeattribute httpd_user_content_t file_type, httpdcontent; sono equivalenti alla formula: type httpd_user_content_t, file_type, httpdcontent; Ciò permette di migliorare la flessibilità e la modularità del linguaggio. Gli aliases invece, a differenza degli attributi, rappresentano dei sinonimi per i tipi. La sintassi per definire un alias associato ad un tipo è la seguente: typealias type_name alias alias_name; dove type_name è il nome del tipo a cui si vuole associare un alias_name, il quale deve soddisfare le stesse regole sintattiche di cui gode type_name (le quali sono state specificate precedentemente). È possibile associare ad un tipo più di un alias_name: in tal caso i vari alias verranno elencati all interno di parentesi graffe. 2.2 Access Vector Rules Le regole Access Vector consentono di effettuare quattro tipi di operazioni che riguardano sia la concessione (o la negazione) vera e propria di permessi, sia la possibilità o meno di effettuare auditing. In particolare la regola allow permette di definire quale soggetto può accedere ad un determinato oggetto con i permessi specificati nella regola (come si vedrà in seguito). Si ricorda che in SELinux non è concesso alcun accesso di default, di conseguenza ogni accesso può avvenire solo se esiste una regola allow che lo permette. Come si è visto in precedenza, l auditing è molto utile all amministratore di sistema per consentirgli di revisionare quali sono stati gli accessi negati ed eventualmente constatare possibili bug o tentativi di intrusione nel sistema. Di default vengono registrati tutti gli accessi negati, tuttavia può capitare che per alcuni di essi non sia necessaria l operazione di auditing. La regola dontaudit è quella che appunto specifica quali accessi negati non 18

19 devono essere registrati. Si ricordi però che SELinux opera dopo che è stato superato il controllo di sicurezza standard di Linux, dunque se quest ultimo nega l accesso SELinux non interverrà proprio e di conseguenza l accesso negato non verrà registrato. La regola auditallow invece specifica quali accessi concessi devono essere registrati: ciò può essere utile per monitorare accessi a risorse di particolare importanza, come ad esempio la richiesta di scrittura sul file shadow. Infine vi è la regola neverallow che specifica quale accesso tra due entità non deve essere mai accordato: essenzialmente quest ultima regola rappresenta un aiuto in più per colui che scrive la politica al fine di negare permessi indesiderati. Queste regole hanno tutte la stessa sintassi: rule source_type(s) target_type(s) : object_class(es) permission(s) Ad esempio, la seguente regola: allow user_t bin_t : file execute; garantisce che al soggetto di tipo user_t venga accordata l esecuzione del file di tipo bin_t. Source type, target type e object class costituiscono una key. Quando un processo vuole accedere ad una risorsa, come si è visto nella sezione relativa all architettura di SELinux, ne fa richiesta al modulo LSM sulla base di questa key. Nel caso in cui due regole AV hanno la stessa key, l effetto delle due è cumulativo. Ad esempio, si considerino le seguenti due regole allow: allow user_t bin_t : file execute; allow user_t bin_t : file read; in tal caso verrà concessa sia l esecuzione che la lettura. Si noti che nonostante esista una regola che conceda l accesso, non esiste alcuna regola che rimuova l accesso garantito da una regola precedente. È possibile utilizzare gli attributi nelle regole AV per evitare di scrivere troppe righe di permessi; si consideri il seguente esempio: allow user_t bin_t : file execute; allow user_t local_bin_t : file execute; allow user_t sbin_t : file execute; allow staff_t bin_t : file execute; 19

20 allow staff_t local_bin_t : file execute; allow staff_t sbin_t : file execute; se si definisse l attributo domain per i tipi user_t e staff_t e l attributo exec_type per i tipi bin_t, local_bin_t e sbin_t, potremmo scrivere la seguente regola al posto delle sei viste nell esempio sopracitato: allow domain exec_type : file execute; È possibile inoltre specificare più attributi e più tipi sia per il source type che per il target type, oltre a poter effettuare una loro combinazione, ad esempio: allow {user_t domain} {bin_t file_type sbin_t} : file execute; Esistono due tipi speciali: il tipo self e il tipo negazione. Il tipo self si usa nel campo target per riferirsi allo stesso tipo specificato nel campo source, ad esempio le seguenti regole sono equivalenti tra loro: allow user_t user_t : process signal; allow user_t self : process signal; Allo stesso modo le seguenti due regole: allow user_t user_t : process signal; allow staff_t staff_t : process signal; sono equivalenti alla regola: allow {user_t staff_t} self : process signal; L operatore di negazione è utile invece quando si ha a che fare con una regola con attributi e si vuole che questa effettui una determinata azione di tipo AV su tutti gli attributi tranne che ad un tipo specificato. Ad esempio: allow domain { exec_type sbin_t} : file execute; in questo caso si vuole che tutti i tipi con attributo domain eseguano tutti i tipi con attributo exec_type tranne sbin_t (che pure ha attributo exec_type). Per specificare la negazione basta anteporre un trattino alto al nome del tipo che non si vuole includere nella lista. L ordine di attributo e tipo negato è ininfluente, ovvero è possibile scrivere anche: { -sbin_t exec_type } 20

21 Nella sintassi delle regole AV è possibile specificare anche più object classes e permissions. Si considerino a questo proposito le seguenti regole: allow user_t bin_t : file { read getattr }; allow user_t bin_t : dir { read getattr }; Queste sono equivalenti alla seguente: allow user_t bin_t : { file dir } { read getattr }; Tuttavia bisogna prestare attenzione in questo caso alla validità dei permessi su determinate classi di oggetti; ad esempio, si consideri: allow user_t bin_t : { file dir } { read getattr search }; in questo caso la regola è illegale in quanto il permesso search non può essere applicato ad un oggetto di tipo file, ma solo ad oggetti di tipo dir (è infatti possibile cercare in una directory ma non in un file). In questo caso l unico espediente che è possibile utilizzare è quello di scrivere le due regole separatamente in questo modo: allow user_t bin_t : file { read getattr }; allow user_t bin_t : dir { read getattr search }; Infine esistono due operatori speciali comuni alle regole AV: l operatore asterisco (*) e la tilde (~). L asterisco si utilizza nel campo dei permessi per specificare che alle classi di oggetti definite nella regola devono essere applicati tutti i permessi. Un esempio di utilizzo è il seguente: allow user_t bin_t : { file dir } *; L operatore tilde invece si utilizza per specificare che bisogna applicare tutti i permessi a quella classe di oggetti specificata nella regola tranne quelli indicati dopo la tilde tra parentesi graffe. Di seguito un esempio: allow user_t bin_t : file ~{ write setattr ioctl }; 21

22 2.3 Type Rules Le type rules hanno una sintassi simile alle regole AV, tuttavia differiscono semanticamente da queste ultime: infatti mentre le regole AV riguardano permessi e auditing, le type rules operano nel campo del labeling. Esistono due tipi di type rules: type transition rules (default domain transition e default object transition) e type change rules. La sintassi per entrambe è la seguente: rule source_type(s) target_type(s) object class(es) default_type Le type transition rules nascono dall esigenza di risolvere il problema della transizione di dominio. Per spiegare questo problema si farà riferimento al programma passwd di Linux, ovvero il programma di gestione delle password che deve operare sul file /etc/shadow. Nella sicurezza standard di Linux è necessario che il programma passwd abbia i privilegi di root per poter effettuare queste operazioni. Tuttavia molti programmi possono avere i permessi di root e dunque si rende necessaria una maggior protezione, ovviata da SELinux. Come si può vedere dalla figura precedente il programma passwd può operare sul file shadow solo se gode dei privilegi di root (come in Linux standard) e contemporaneamente esiste una regola allow che lo permette. Sono dunque necessarie entrambe le condizioni. Il problema della transizione di dominio lo si può rappresentare con la seguente figura: 22

Security Enhanced Linux (SELinux)

Security Enhanced Linux (SELinux) 25/10/2002 Security Enhanced Linux 1 Cos è SELinux? Security Enhanced Linux (SELinux) a cura di: Michelangelo Magliari Loredana Luzzi Andrea Fiore Prototipo di Sistema Operativo Realizzato dalla National

Dettagli

SELinux. di Maurizio Pagani

SELinux. di Maurizio Pagani SELinux di Maurizio Pagani 1. Introduzione Il SELinux (Security-Enhanced Linux) è un prodotto di sicurezza creato dalla NSA (National Security Agency) che gira direttamente nel kernel, implementando così

Dettagli

Introduzione a SELinux. a cura di Giorgio Zanin Sicurezza dei dati e delle reti a.a. 2002/2003

Introduzione a SELinux. a cura di Giorgio Zanin Sicurezza dei dati e delle reti a.a. 2002/2003 Introduzione a SELinux a cura di Giorgio Zanin Sicurezza dei dati e delle reti a.a. 2002/2003 Introduzione I sistemi devono essere flessibili nel loro supporto alle security policy Flessibilità significa:

Dettagli

Ma il software open source è sicuro?

Ma il software open source è sicuro? Ma il software open source è sicuro? Alberto Ferrante ALaRI, Facoltà di Informatica Università della Svizzera italiana E-mail: ferrante@alari.ch Lugano Communication Forum, 3/4/2007 A. Ferrante Ma il software

Dettagli

Sistemi Operativi MECCANISMI E POLITICHE DI PROTEZIONE. D. Talia - UNICAL. Sistemi Operativi 13.1

Sistemi Operativi MECCANISMI E POLITICHE DI PROTEZIONE. D. Talia - UNICAL. Sistemi Operativi 13.1 MECCANISMI E POLITICHE DI PROTEZIONE 13.1 Protezione Obiettivi della Protezione Dominio di Protezione Matrice di Accesso Implementazione della Matrice di Accesso Revoca dei Diritti di Accesso Sistemi basati

Dettagli

MECCANISMI E POLITICHE DI PROTEZIONE 13.1

MECCANISMI E POLITICHE DI PROTEZIONE 13.1 MECCANISMI E POLITICHE DI PROTEZIONE 13.1 Protezione Obiettivi della Protezione Dominio di Protezione Matrice di Accesso Implementazione della Matrice di Accesso Revoca dei Diritti di Accesso Sistemi basati

Dettagli

Capitolo 3: Strutture dei sistemi operativi

Capitolo 3: Strutture dei sistemi operativi Capitolo 3: Strutture dei sistemi operativi Componenti del sistema Servizi di un sistema operativo Chiamate del sistema Programmi di sistema Struttura del sistema Macchine virtuali Progettazione e realizzazione

Dettagli

Protezione. Sistemi Operativi mod. B 16.1

Protezione. Sistemi Operativi mod. B 16.1 Protezione Scopi della Protezione Dominio di Protezione Matrice d Accesso Implementazione della Matrice d Accesso Revoca dei Diritti d Accesso Sistemi Basati su Abilitazioni Protezione basata sul linguaggio

Dettagli

Sicurezza dei sistemi e delle reti Introduzione

Sicurezza dei sistemi e delle reti Introduzione Sicurezza dei sistemi e delle reti Introduzione Damiano Carra Università degli Studi di Verona Dipartimento di Informatica Riferimenti! Cap. 8 di Reti di calcolatori e Internet. Un approccio topdown, J.

Dettagli

Protezione. Univ. Ferrara Laurea in Informatica Sistemi Operativi 1. Scopi della protezione. Autenticazione/Autorizzazione. Principi di protezione

Protezione. Univ. Ferrara Laurea in Informatica Sistemi Operativi 1. Scopi della protezione. Autenticazione/Autorizzazione. Principi di protezione Univ. Ferrara Laurea in Informatica Esame di Scopi della protezione Sistema operativo: un insieme di oggetti, hardware o software 12 alberto.gianoli@fe.infn.it nasce col multiprogramming: bisogna tenere

Dettagli

Configurare e Gestire le ACLs in oneye 0.8

Configurare e Gestire le ACLs in oneye 0.8 Configurare e Gestire le ACLs in oneye 0.8 Ti stai chiedendo come funzionano in Controlli di Accesso in oneye, ma non sai come utilizzarli? Continua a leggere. In questa guida, mostrerò come sia possibile

Dettagli

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL

Sistemi Operativi STRUTTURA DEI SISTEMI OPERATIVI 3.1. Sistemi Operativi. D. Talia - UNICAL STRUTTURA DEI SISTEMI OPERATIVI 3.1 Struttura dei Componenti Servizi di un sistema operativo System Call Programmi di sistema Struttura del sistema operativo Macchine virtuali Progettazione e Realizzazione

Dettagli

Permessi, utenti e gruppi

Permessi, utenti e gruppi Permessi, utenti e gruppi Daniele Venzano 9 novembre 2003 Indice 1 Introduzione 1 2 Concetti generali 2 2.1 Esempio..................................... 2 3 File importanti 2 3.1 /etc/group...................................

Dettagli

2. Strutture dei Sistemi Operativi

2. Strutture dei Sistemi Operativi 1 2. Strutture dei Sistemi Operativi Quali servizi un generico sistema operativo mette a disposizione degli utenti, e dei programmi che gli utenti vogliono eseguire? interfaccia col sistema operativo stesso

Dettagli

SISTEMI OPERATIVI DISTRIBUITI

SISTEMI OPERATIVI DISTRIBUITI SISTEMI OPERATIVI DISTRIBUITI E FILE SYSTEM DISTRIBUITI 12.1 Sistemi Distribuiti Sistemi operativi di rete Sistemi operativi distribuiti Robustezza File system distribuiti Naming e Trasparenza Caching

Dettagli

Guida all utilizzo. Rif. File: GuidaSi@dmin.pages Pag. 1 / 14

Guida all utilizzo. Rif. File: GuidaSi@dmin.pages Pag. 1 / 14 Guida all utilizzo Rif. File: GuidaSi@dmin.pages Pag. 1 / 14 Home page e panoramica delle funzionalità!... 3 La sezione Account!... 4 Creare un Account!... 5 Cambiare la password dell account!... 7 Eliminare

Dettagli

Modello di Controllo dell Accesso basato sui ruoli (RBAC)

Modello di Controllo dell Accesso basato sui ruoli (RBAC) Modello di Controllo dell Accesso basato sui ruoli (RBAC) POLITICHE RBAC Sistemi di tipo Role Based Access Control (RBAC) assegnano i privilegi non agli utenti, ma alla funzione che questi possono svolgere

Dettagli

Sistemi Operativi di Rete. Sistemi Operativi di rete. Sistemi Operativi di rete

Sistemi Operativi di Rete. Sistemi Operativi di rete. Sistemi Operativi di rete Sistemi Operativi di Rete Estensione dei Sistemi Operativi standard con servizi per la gestione di risorse in rete locale Risorse gestite: uno o più server di rete più stampanti di rete una o più reti

Dettagli

Software. Definizione, tipologie, progettazione

Software. Definizione, tipologie, progettazione Software Definizione, tipologie, progettazione Definizione di software Dopo l hardware analizziamo l altra componente fondamentale di un sistema di elaborazione. La macchina come insieme di componenti

Dettagli

Informatica Generale 1 - Esercitazioni Introduzione all uso della command-line shell

Informatica Generale 1 - Esercitazioni Introduzione all uso della command-line shell Informatica Generale 1 - Esercitazioni Introduzione all uso della command-line shell Daniele Pighin pighin@fbk.eu FBK Via Sommarive, 18 I-38050 Trento, Italy March 5, 2008 Outline 1 Sistema operativo e

Dettagli

CAPITOLO 1 I SISTEMI OPERATIVI

CAPITOLO 1 I SISTEMI OPERATIVI CAPITOLO 1 I SISTEMI OPERATIVI Introduzione ai sistemi operativi pag. 3 La shell pag. 3 Tipi di sistemi operativi pag. 4 I servizi del sistema operativo pag. 4 La gestione dei file e il file system Il

Dettagli

Il Sistema Operativo Linux

Il Sistema Operativo Linux Il Sistema Operativo Linux Sistema Linux storia Unix deriva da Unix open source software libero software open source GNU, GPL, LGPL storia Linux amministrazione struttura concetti base comandi shell Unix

Dettagli

Classificazione del software

Classificazione del software Classificazione del software Classificazione dei software Sulla base del loro utilizzo, i programmi si distinguono in: SOFTWARE Sistema operativo Software applicativo Sistema operativo: una definizione

Dettagli

L amministratore di dominio

L amministratore di dominio L amministratore di dominio Netbuilder consente ai suoi clienti di gestire autonomamente le caselle del proprio dominio nel rispetto dei vincoli contrattuali. Ciò è reso possibile dall esistenza di un

Dettagli

2.1 Introduzione ai linguaggi di marcatura

2.1 Introduzione ai linguaggi di marcatura Fondamenti di Informatica Sistemi di Elaborazione delle Informazioni Informatica Applicata 2.1 Introduzione ai linguaggi di marcatura Antonella Poggi Anno Accademico 2012-2013 DIPARTIMENTO DI SCIENZE DOCUMENTARIE

Dettagli

ASPETTI GENERALI DI LINUX. Parte 2 Struttura interna del sistema LINUX

ASPETTI GENERALI DI LINUX. Parte 2 Struttura interna del sistema LINUX Parte 2 Struttura interna del sistema LINUX 76 4. ASPETTI GENERALI DEL SISTEMA OPERATIVO LINUX La funzione generale svolta da un Sistema Operativo può essere definita come la gestione dell Hardware orientata

Dettagli

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it

Programmazione II. Lezione 4. Daniele Sgandurra 30/09/2011. daniele.sgandurra@iit.cnr.it Programmazione II Lezione 4 Daniele Sgandurra daniele.sgandurra@iit.cnr.it 30/09/2011 1/46 Programmazione II Lezione 4 30/09/2011 Sommario 1 Esercitazione 2 Panoramica della Programmazione Ad Oggetti 3

Dettagli

OGGETTO DELLA FORNITURA...4

OGGETTO DELLA FORNITURA...4 Gara d appalto per la fornitura di licenze software e servizi per la realizzazione del progetto di Identity and Access Management in Cassa Depositi e Prestiti S.p.A. CAPITOLATO TECNICO Indice 1 GENERALITÀ...3

Dettagli

Tecnologie Informatiche. security. Rete Aziendale Sicura

Tecnologie Informatiche. security. Rete Aziendale Sicura Tecnologie Informatiche security Rete Aziendale Sicura Neth Security è un sistema veloce, affidabile e potente per la gestione della sicurezza aziendale, la protezione della rete, l accesso a siti indesiderati

Dettagli

Acronis License Server. Manuale utente

Acronis License Server. Manuale utente Acronis License Server Manuale utente INDICE 1. INTRODUZIONE... 3 1.1 Panoramica... 3 1.2 Politica della licenza... 3 2. SISTEMI OPERATIVI SUPPORTATI... 4 3. INSTALLAZIONE DI ACRONIS LICENSE SERVER...

Dettagli

Il Sistema Operativo. Introduzione di programmi di utilità. Elementi di Informatica Docente: Giorgio Fumera

Il Sistema Operativo. Introduzione di programmi di utilità. Elementi di Informatica Docente: Giorgio Fumera CPU Memoria principale Il Sistema Operativo Elementi di Informatica Docente: Giorgio Fumera Corso di Laurea in Edilizia Facoltà di Architettura A.A. 2009/2010 ALU Unità di controllo Registri A indirizzi

Dettagli

Analisi dei Requisiti

Analisi dei Requisiti Analisi dei Requisiti Pagina 1 di 16 Analisi dei Requisiti Indice 1 - INTRODUZIONE... 4 1.1 - OBIETTIVO DEL DOCUMENTO...4 1.2 - STRUTTURA DEL DOCUMENTO...4 1.3 - RIFERIMENTI...4 1.4 - STORIA DEL DOCUMENTO...4

Dettagli

Windows Vista, il nuovo sistema operativo Microsoft che cerca le giuste risposte ai quesiti di sicurezza

Windows Vista, il nuovo sistema operativo Microsoft che cerca le giuste risposte ai quesiti di sicurezza Windows Vista, il nuovo sistema operativo Microsoft che cerca le giuste risposte ai quesiti di sicurezza Microsoft Windows è il sistema operativo più diffuso, ma paradossalmente è anche quello meno sicuro.

Dettagli

LICARUS LICENSE SERVER

LICARUS LICENSE SERVER UNIVERSITÀ DEGLI STUDI DI ROMA TOR VERGATA Facoltà di Ingegneria Corso di Laurea Specialistica in Ingegneria Informatica Progetto per il corso di Sicurezza dei Sistemi Informatici LICARUS LICENSE SERVER

Dettagli

introduzione alla sicurezza informatica 2006-2009 maurizio pizzonia sicurezza dei sistemi informatici e delle reti

introduzione alla sicurezza informatica 2006-2009 maurizio pizzonia sicurezza dei sistemi informatici e delle reti introduzione alla sicurezza informatica 1 principio fondamentale la sicurezza di un sistema informatico è legata molto al processo con cui il sistema viene gestito pianificazione, analisi dei rischi, gestione

Dettagli

11/02/2015 MANUALE DI INSTALLAZIONE DELL APPLICAZIONE DESKTOP TELEMATICO VERSIONE 1.0

11/02/2015 MANUALE DI INSTALLAZIONE DELL APPLICAZIONE DESKTOP TELEMATICO VERSIONE 1.0 11/02/2015 MANUALE DI INSTALLAZIONE DELL APPLICAZIONE DESKTOP TELEMATICO VERSIONE 1.0 PAG. 2 DI 38 INDICE 1. PREMESSA 3 2. SCARICO DEL SOFTWARE 4 2.1 AMBIENTE WINDOWS 5 2.2 AMBIENTE MACINTOSH 6 2.3 AMBIENTE

Dettagli

LABORATORIO DI TELEMATICA

LABORATORIO DI TELEMATICA LABORATORIO DI TELEMATICA COGNOME: Ronchi NOME: Valerio NUMERO MATRICOLA: 41210 CORSO DI LAUREA: Ingegneria Informatica TEMA: Analisi del protocollo FTP File Transfer Protocol File Transfer Protocol (FTP)

Dettagli

Protezione e Sicurezza

Protezione e Sicurezza Protezione e Sicurezza La protezione riguarda l insieme di attività volte a garantire il controllo dell accesso alle risorse logiche e fisiche da parte degli utenti all interno di un sistema di calcolo.

Dettagli

introduzione alla sicurezza informatica

introduzione alla sicurezza informatica introduzione alla sicurezza informatica 1 principio fondamentale la sicurezza di un sistema informatico è legata molto al processo con cui il sistema viene gestito pianificazione, analisi dei rischi, gestione

Dettagli

Il computer: primi elementi

Il computer: primi elementi Il computer: primi elementi Tommaso Motta T. Motta Il computer: primi elementi 1 Informazioni Computer = mezzo per memorizzare, elaborare, comunicare e trasmettere le informazioni Tutte le informazioni

Dettagli

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese

Introduzione al sistema operativo. Laboratorio Software 2008-2009 C. Brandolese Introduzione al sistema operativo Laboratorio Software 2008-2009 C. Brandolese Che cos è un sistema operativo Alcuni anni fa un sistema operativo era definito come: Il software necessario a controllare

Dettagli

TEORIA sulle BASI DI DATI

TEORIA sulle BASI DI DATI TEORIA sulle BASI DI DATI A cura del Prof. Enea Ferri Cos è un DATA BASE E un insieme di archivi legati tra loro da relazioni. Vengono memorizzati su memorie di massa come un unico insieme, e possono essere

Dettagli

TECNICHE DI CONTROLLO D ACCESSO

TECNICHE DI CONTROLLO D ACCESSO Università degli Studi di Bologna IIª Facoltà di Ingegneria - Cesena TECNICHE DI CONTROLLO D ACCESSO OUTLINE Introduzione alle tecniche di controllo d accesso Discretionary Access Control (DAC) Mandatory

Dettagli

Corso di Amministrazione di Reti A.A. 2002/2003

Corso di Amministrazione di Reti A.A. 2002/2003 Struttura di Active Directory Corso di Amministrazione di Reti A.A. 2002/2003 Materiale preparato utilizzando dove possibile materiale AIPA http://www.aipa.it/attivita[2/formazione[6/corsi[2/materiali/reti%20di%20calcolatori/welcome.htm

Dettagli

Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base

Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base Sistema operativo Definizione Parte del software che gestisce I programmi applicativi L interfaccia tra il calcolatore e i programmi applicativi Le funzionalità di base Architettura a strati di un calcolatore

Dettagli

PROTOTIPAZIONE DI UN TRADUTTORE DA SORGENTE PLC AD ASSEMBLY DI UNA MACCHINA VIRTUALE

PROTOTIPAZIONE DI UN TRADUTTORE DA SORGENTE PLC AD ASSEMBLY DI UNA MACCHINA VIRTUALE PROTOTIPAZIONE DI UN TRADUTTORE DA SORGENTE PLC AD ASSEMBLY DI UNA MACCHINA VIRTUALE Relatore: prof. Michele Moro Laureando: Marco Beggio Corso di laurea in Ingegneria Informatica Anno Accademico 2006-2007

Dettagli

SISM Sistema Informativo Salute Mentale

SISM Sistema Informativo Salute Mentale SISM Sistema Informativo Salute Mentale Manuale per la registrazione al sistema Versione 1.0 12/01/2012 NSIS_SSW.MSW_PREVSAN_SISM_MTR_Registrazione.doc Pagina 1 di 25 Scheda informativa del documento Versione

Dettagli

Gruppi, Condivisioni e Permessi. Orazio Battaglia

Gruppi, Condivisioni e Permessi. Orazio Battaglia Gruppi, Condivisioni e Permessi Orazio Battaglia Gruppi Un gruppo in Active Directory è una collezione di Utenti, Computer, Contatti o altri gruppi che può essere gestita come una singola unità. Usare

Dettagli

Analisi dei rischi della system call chroot e un valido sostituto: le jail. Marco Trentini mt@datasked.com

Analisi dei rischi della system call chroot e un valido sostituto: le jail. Marco Trentini mt@datasked.com Analisi dei rischi della system call chroot e un valido sostituto: le jail Marco Trentini mt@datasked.com 19 febbraio 2012 Prefazione Questa relazione tratta un aspetto di sicurezza presente nei sistemi

Dettagli

Windows XP - Account utente e gruppi

Windows XP - Account utente e gruppi Windows XP - Account utente e gruppi Cos è un account utente In Windows XP il controllo di accesso è essenziale per la sicurezza del computer e dipende in gran parte dalla capacità del sistema di identificare

Dettagli

Petra VPN 3.1. Guida Utente

Petra VPN 3.1. Guida Utente Petra VPN 3.1 Guida Utente Petra VPN 3.1: Guida Utente Copyright 1996, 2004 Link s.r.l. (http://www.link.it) Questo documento contiene informazioni di proprietà riservata, protette da copyright. Tutti

Dettagli

Progettaz. e sviluppo Data Base

Progettaz. e sviluppo Data Base Progettaz. e sviluppo Data Base! Introduzione ai Database! Tipologie di DB (gerarchici, reticolari, relazionali, oodb) Introduzione ai database Cos è un Database Cos e un Data Base Management System (DBMS)

Dettagli

Introduzione alla Progettazione per Componenti

Introduzione alla Progettazione per Componenti Introduzione alla Progettazione per Componenti Alessandro Martinelli 6 ottobre 2014 Obiettivo del Corso Il Progetto Software Reale Il Componente Software La Programmazione Ad Oggetti Fondamenti di Informatica

Dettagli

confinamento e virtualizzazione 2006-2009 maurizio pizzonia sicurezza dei sistemi informatici e delle reti

confinamento e virtualizzazione 2006-2009 maurizio pizzonia sicurezza dei sistemi informatici e delle reti confinamento e virtualizzazione 1 oltre i permessi dei file... nei sistemi operativi standard il supporto per il confinamento è abbastanza flessibile per quanto riguarda i files scarso per quanto riguarda

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: Eduard Roccatello eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

Dettagli

Concetti fondamentali dei database database Cos'è un database Principali database

Concetti fondamentali dei database database Cos'è un database Principali database Concetti fondamentali dei database Nella vita di tutti i giorni si ha la necessità di gestire e manipolare dati. Le operazioni possono essere molteplici: ricerca, aggregazione con altri e riorganizzazione

Dettagli

Benvenuti/e. www.dueville.linux.it 2vilug@gmail.com

Benvenuti/e. www.dueville.linux.it 2vilug@gmail.com Benvenuti/e www.dueville.linux.it 2vilug@gmail.com Piccolo glossario SOFTWARE: Tutto ciò che è immateriale. HARDWARE: Tutto ciò che si può prendere a calci. Sistema operativo Il sistema operativo è l'insieme

Dettagli

TEMPO X PRODURRE ARTICOLO QUANTITÀ LAVORAZIONE MACCHINA 1 PEZZO Taglio Seghetto 30 minuti. Tornitura Tornio 20 minuti

TEMPO X PRODURRE ARTICOLO QUANTITÀ LAVORAZIONE MACCHINA 1 PEZZO Taglio Seghetto 30 minuti. Tornitura Tornio 20 minuti PIANIFICAZIONE DELLA PRODUZIONE CON ACCESS E PROJECT 2007 In questo articolo esamineremo come una applicazione Access ed una applicazione Project 2007 possono interagire per creare un piano di produzione

Dettagli

E-mail: infobusiness@zucchetti.it. Gestione Filtri. InfoBusiness 2.8 Gestione Filtri Pag. 1/ 11

E-mail: infobusiness@zucchetti.it. Gestione Filtri. InfoBusiness 2.8 Gestione Filtri Pag. 1/ 11 Gestione Filtri InfoBusiness 2.8 Gestione Filtri Pag. 1/ 11 INDICE Indice...2 1. GESTIONE DEI FILTRI...3 1.1. Filtri fissi...3 1.2. Filtro parametrico...5 1.3. Funzione di ricerca...6 2. CONTESTI IN CUI

Dettagli

Maxpho Commerce 11. Gestione CSV. Data: 20 Settembre 2011 Versione : 1.1 Autore: Maxpho Srl

Maxpho Commerce 11. Gestione CSV. Data: 20 Settembre 2011 Versione : 1.1 Autore: Maxpho Srl Maxpho Commerce 11 Gestione CSV Data: 20 Settembre 2011 Versione : 1.1 Autore: Maxpho Srl Indice generale 1 - Introduzione... 3 1.1 - Il file CSV...3 1.2 - Modulo CSV su Maxpho... 3 1.3 - Modulo CSV Pro

Dettagli

Le Infrastrutture Software ed il Sistema Operativo

Le Infrastrutture Software ed il Sistema Operativo Le Infrastrutture Software ed il Sistema Operativo Corso di Informatica CdL: Chimica Claudia d'amato claudia.damato@di.uniba.it Il Sistema Operativo (S0) (Inf.) E' l'insieme dei programmi che consentono

Dettagli

Corso di Laurea in Informatica Reti e Sicurezza Informatica

Corso di Laurea in Informatica Reti e Sicurezza Informatica Corso di Laurea in Informatica Reti e Sicurezza Informatica Esercitazione 6 Autenticazione in Tomcat per lo sviluppo di Web Service. In questo documento si presentano i meccanismi fondamentali che consentono

Dettagli

Capitolo 3 Guida operativa del programma TQ Sistema

Capitolo 3 Guida operativa del programma TQ Sistema Capitolo 3 Guida operativa del programma TQ Sistema Panoramica delle funzionalità Questa guida contiene le informazioni necessarie per utilizzare il pacchetto TQ Sistema in modo veloce ed efficiente, mediante

Dettagli

Corso di Access. Prerequisiti. Modulo L2A (Access) 1.1 Concetti di base. Utilizzo elementare del computer Concetti fondamentali di basi di dati

Corso di Access. Prerequisiti. Modulo L2A (Access) 1.1 Concetti di base. Utilizzo elementare del computer Concetti fondamentali di basi di dati Corso di Access Modulo L2A (Access) 1.1 Concetti di base 1 Prerequisiti Utilizzo elementare del computer Concetti fondamentali di basi di dati 2 1 Introduzione Un ambiente DBMS è un applicazione che consente

Dettagli

Protezione. Protezione. Protezione. Obiettivi della protezione

Protezione. Protezione. Protezione. Obiettivi della protezione Protezione Protezione La protezione riguarda i meccanismi per il controllo dell accesso alle risorse in un sistema di calcolo da parte degli utenti e dei processi. Meccanismi di imposizione fissati in

Dettagli

2006-2011 maurizio pizzonia sicurezza dei sistemi informatici e delle reti. confinamento e virtualizzazione

2006-2011 maurizio pizzonia sicurezza dei sistemi informatici e delle reti. confinamento e virtualizzazione confinamento e virtualizzazione 1 oltre i permessi dei file... nei sistemi operativi standard il supporto per il confinamento è abbastanza flessibile per quanto riguarda i files scarso per quanto riguarda

Dettagli

Configuration of a distributed system as emerging behavior of autonomous agents

Configuration of a distributed system as emerging behavior of autonomous agents Configuration of a distributed system as emerging behavior of autonomous agents Configuration of a distributed system as emerging behavior of autonomous agents : Questo documento illustra la strategia

Dettagli

INFORMATICA 1 L. Mezzalira

INFORMATICA 1 L. Mezzalira INFORMATICA 1 L. Mezzalira Possibili domande 1 --- Caratteristiche delle macchine tipiche dell informatica Componenti hardware del modello funzionale di sistema informatico Componenti software del modello

Dettagli

Il software impiegato su un computer si distingue in: Sistema Operativo Compilatori per produrre programmi

Il software impiegato su un computer si distingue in: Sistema Operativo Compilatori per produrre programmi Il Software Il software impiegato su un computer si distingue in: Software di sistema Sistema Operativo Compilatori per produrre programmi Software applicativo Elaborazione testi Fogli elettronici Basi

Dettagli

Appunti di Sistemi Distribuiti

Appunti di Sistemi Distribuiti Appunti di Sistemi Distribuiti Matteo Gianello 27 settembre 2013 1 Indice 1 Introduzione 3 1.1 Definizione di sistema distribuito........................... 3 1.2 Obiettivi.........................................

Dettagli

Guida dell utente di RTAI LiveCD

Guida dell utente di RTAI LiveCD Guida dell utente di RTAI LiveCD La distribuzione RTAI LiveCD è una distribuzione live di Linux con kernel 2.6.13 ADEOSipipe RTAI 3.3. Tutti i pacchetti software presenti sono stati presi da una distribuzione

Dettagli

File system II. Sistemi Operativi Lez. 20

File system II. Sistemi Operativi Lez. 20 File system II Sistemi Operativi Lez. 20 Gestione spazi su disco Esiste un trade-off,tra spreco dello spazio e velocità di trasferimento in base alla dimensione del blocco fisico Gestione spazio su disco

Dettagli

LEZIONE 3. Il pannello di amministrazione di Drupal, configurazione del sito

LEZIONE 3. Il pannello di amministrazione di Drupal, configurazione del sito LEZIONE 3 Il pannello di amministrazione di Drupal, configurazione del sito Figura 12 pannello di controllo di Drupal il back-end Come già descritto nella lezione precedente il pannello di amministrazione

Dettagli

Università degli Studi di Verona. Linux Ubuntue ilcompilatorec. Dicembre 2014 - Sergio Marin Vargas. Dipartimento di Biotecnologie

Università degli Studi di Verona. Linux Ubuntue ilcompilatorec. Dicembre 2014 - Sergio Marin Vargas. Dipartimento di Biotecnologie Università degli Studi di Verona Dipartimento di Biotecnologie Laurea in Biotecnologie Corso di Informatica2014/2015 Linux Ubuntue ilcompilatorec Dicembre 2014 - Sergio Marin Vargas Caratteristiche di

Dettagli

Versione 1.0. La cartella di Excel contiene, di default, le seguenti schede: Classe, Criteri, 1,Riepilogo, Doc15 come si vede in figura:

Versione 1.0. La cartella di Excel contiene, di default, le seguenti schede: Classe, Criteri, 1,Riepilogo, Doc15 come si vede in figura: Versione 1.0 Premessa Dixit è la griglia per la definizione del voto d orale all esame di Stato; aiuta a mantenere un criterio unico e oggettivo nell assegnazione del voto. La cartella di Excel contiene,

Dettagli

Statistica 4038 (ver. 1.2)

Statistica 4038 (ver. 1.2) Statistica 4038 (ver. 1.2) Software didattico per l insegnamento della Statistica SERGIO VENTURINI, MAURIZIO POLI i Il presente software è utilizzato come supporto alla didattica nel corso di Statistica

Dettagli

MCTCNet2 FULLMCTCNet2

MCTCNet2 FULLMCTCNet2 cosa sono MCTCNet2 FULLMCTCNet2 novità già in atto tempi di attuazione come avverrà la migrazione dal vecchio al nuovo protocollo cosa cambierà Cosa sono MCTCNet2 e FULLMCTCNet MCTC-Net2 è un nuovo protocollo

Dettagli

Protezione. Introduzione multiprogrammazione. Possibili protezioni. Perchè è necessaria? Possibili protezioni. Possibili protezioni

Protezione. Introduzione multiprogrammazione. Possibili protezioni. Perchè è necessaria? Possibili protezioni. Possibili protezioni Protezione Cantiello Lara Amato Maurizio Introduzione multiprogrammazione possibilità di condividere tra gli utenti varie risorse necessità di proteggerle Processore Memoria Dispositivi di I/O Programmi

Dettagli

CORSO EDA Informatica di base. Sicurezza, protezione, aspetti legali

CORSO EDA Informatica di base. Sicurezza, protezione, aspetti legali CORSO EDA Informatica di base Sicurezza, protezione, aspetti legali Rischi informatici Le principali fonti di rischio di perdita/danneggiamento dati informatici sono: - rischi legati all ambiente: rappresentano

Dettagli

Programmi. Algoritmi scritti in un linguaggio di programmazione

Programmi. Algoritmi scritti in un linguaggio di programmazione Programmi Algoritmi scritti in un linguaggio di programmazione Sistema operativo:programma supervisore che coordina tutte le operazioni del calcolatore Programmi applicativi esistenti Sistemi di videoscrittura

Dettagli

Evasione. Evasione. Vendite. Magazzini Immagini

Evasione. Evasione. Vendite. Magazzini Immagini Schema di funzionamento del Carico da Ordini Ordine Archivio di Transito Univoco Evasione Codifica Controllo Articoli Generico Evasione Movimenti Documenti Giacenze Testata Scadenze Vendite Dettaglio Ingrosso

Dettagli

Università degli Studi di Cagliari Corso di Laurea Specialistica in Ingegneria Elettronica SISTEMI OPERATIVI STRUTTURE DEI SISTEMI OPERATIVI

Università degli Studi di Cagliari Corso di Laurea Specialistica in Ingegneria Elettronica SISTEMI OPERATIVI STRUTTURE DEI SISTEMI OPERATIVI Università degli Studi di Cagliari Corso di Laurea Specialistica in Ingegneria Elettronica SISTEMI OPERATIVI STRUTTURE DEI SISTEMI OPERATIVI SERVIZI DI UN SISTEMA OPERATIVO Panoramica dei servizi del sistema

Dettagli

Quaderni di formazione Nuova Informatica

Quaderni di formazione Nuova Informatica Quaderni di formazione Nuova Informatica Airone versione 6 - Funzioni di Utilità e di Impostazione Copyright 1995,2001 Nuova Informatica S.r.l. - Corso del Popolo 411 - Rovigo Introduzione Airone Versione

Dettagli

Il database management system Access

Il database management system Access Il database management system Access Corso di autoistruzione http://www.manualipc.it/manuali/ corso/manuali.php? idcap=00&idman=17&size=12&sid= INTRODUZIONE Il concetto di base di dati, database o archivio

Dettagli

Scadenziario e Rubrica

Scadenziario e Rubrica Scadenziario e Rubrica Breve panoramica Lo Scadenziario è un software creato con lo scopo di avere sempre sotto controllo i propri impegni e le proprie attività da svolgere. Quante volte ci si dimentica

Dettagli

2. I THREAD. 2.1 Introduzione

2. I THREAD. 2.1 Introduzione 2. I THREAD 2.1 Introduzione Il tipo di parallelismo che è opportuno avere a disposizione nelle applicazioni varia in base al grado di cooperazione necessaria tra le diverse attività svolte in parallelo:

Dettagli

Mon Ami 3000 Provvigioni agenti Calcolo delle provvigioni per agente / sub-agente

Mon Ami 3000 Provvigioni agenti Calcolo delle provvigioni per agente / sub-agente Prerequisiti Mon Ami 3000 Provvigioni agenti Calcolo delle provvigioni per agente / sub-agente L opzione Provvigioni agenti è disponibile per le versioni Vendite, Azienda Light e Azienda Pro. Introduzione

Dettagli

PORTALE PER GESTIONE REPERIBILITA Manuale e guida O.M. e ufficio distribuzione

PORTALE PER GESTIONE REPERIBILITA Manuale e guida O.M. e ufficio distribuzione PORTALE PER GESTIONE REPERIBILITA Manuale e guida O.M. e ufficio distribuzione Portale Numero Verde Vivisol pag. 1 di 31 INDICE 1. INTRODUZIONE...3 2. SCHERMATA PRINCIPALE...4 3. REPERIBILITÀ...5 4. RICERCA

Dettagli

Mac Application Manager 1.3 (SOLO PER TIGER)

Mac Application Manager 1.3 (SOLO PER TIGER) Mac Application Manager 1.3 (SOLO PER TIGER) MacApplicationManager ha lo scopo di raccogliere in maniera centralizzata le informazioni piu salienti dei nostri Mac in rete e di associare a ciascun Mac i

Dettagli

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi

Evoluzione dei sistemi operativi (5) Evoluzione dei sistemi operativi (4) Classificazione dei sistemi operativi Evoluzione dei sistemi operativi (4) Sistemi multiprogrammati! più programmi sono caricati in contemporaneamente, e l elaborazione passa periodicamente dall uno all altro Evoluzione dei sistemi operativi

Dettagli

Introduzione al TE/DTE. a cura di Giorgio Zanin Sistemi di Elaborazione:sicurezza a.a. 2002-2003

Introduzione al TE/DTE. a cura di Giorgio Zanin Sistemi di Elaborazione:sicurezza a.a. 2002-2003 Introduzione al TE/DTE a cura di Giorgio Zanin Sistemi di Elaborazione:sicurezza a.a. 2002-2003 2003 Introduzione Attualmente la sicurezza di Unix risiede in: Bit di protezione Utente root Meccanismi setuid/setgid

Dettagli

L UFFICIO WEB. Modulo online per la gestione del personale. Manuale di utilizzo. Versione 1.0.75.0. Pagina 1 di 33

L UFFICIO WEB. Modulo online per la gestione del personale. Manuale di utilizzo. Versione 1.0.75.0. Pagina 1 di 33 L UFFICIO WEB Modulo online per la gestione del personale Manuale di utilizzo Versione 1.0.75.0 Pagina 1 di 33 1. INTRODUZIONE L applicazione Ufficio Web permette una gestione semplificata e automatizzata

Dettagli

Manuale di KDE su Geert Jansen Traduzione del documento: Dario Panico Traduzione del documento: Samuele Kaplun Traduzione del documento: Daniele Micci

Manuale di KDE su Geert Jansen Traduzione del documento: Dario Panico Traduzione del documento: Samuele Kaplun Traduzione del documento: Daniele Micci Geert Jansen Traduzione del documento: Dario Panico Traduzione del documento: Samuele Kaplun Traduzione del documento: Daniele Micci 2 Indice 1 Introduzione 5 2 Usare KDE su 6 3 Funzionamento interno 8

Dettagli

DESIGNAZIONE: Rappresenta una relazione tra due entità di tipo 1 ad M. Esempio tipico è : REPARTO ------- IMPIEGATO

DESIGNAZIONE: Rappresenta una relazione tra due entità di tipo 1 ad M. Esempio tipico è : REPARTO ------- IMPIEGATO DESIGNAZIONE: Rappresenta una relazione tra due entità di tipo 1 ad M. Esempio tipico è : REPARTO ------- IMPIEGATO (designata) (designante) Viene rappresentata inserendo, nella tabella dell entità designante,

Dettagli

Il Software. Il software del PC. Il BIOS

Il Software. Il software del PC. Il BIOS Il Software Il software del PC Il computer ha grandi potenzialità ma non può funzionare senza il software. Il software essenziale per fare funzionare il PC può essere diviso nelle seguenti componenti:

Dettagli

AutoRun in Windows. R. Gallo ITIS A. VOLTA GUIDONIA. Ottobre 2009. Abstract

AutoRun in Windows. R. Gallo ITIS A. VOLTA GUIDONIA. Ottobre 2009. Abstract AutoRun in Windows R. Gallo ITIS A. VOLTA GUIDONIA Ottobre 2009 Abstract Costruire un Autorun in Windows. VERSIONE PRELIMINARE 1 Premessa Quando con l uscita di Windows95 gli utenti inserendo un cd nel

Dettagli

CAPITOLO 5 - Sistemi Operativi Moderni

CAPITOLO 5 - Sistemi Operativi Moderni CAPITOLO 5 - Sistemi Operativi Moderni PRESENTAZIONE DI INSIEME Vedremo ora come si è evoluta nel tempo la struttura di un sistema operativo, per passare dalle vecchie strutture di tipo normalmente modulari,

Dettagli

Mandatory Access Control Systems

Mandatory Access Control Systems Mandatory Access Control Systems Introduzione ai sistemi MAC su Linux con GRSecurity Marco Squarcina lavish@gmail.com Dipartimento di Scienze Ambientali, Informatica e Statistica SECGROUP @unive Università

Dettagli

NOTE OPERATIVE. Prodotto Inaz Download Manager. Release 1.3.0

NOTE OPERATIVE. Prodotto Inaz Download Manager. Release 1.3.0 Prodotto Inaz Download Manager Release 1.3.0 Tipo release COMPLETA RIEPILOGO ARGOMENTI 1. Introduzione... 2 2. Architettura... 3 3. Configurazione... 4 3.1 Parametri di connessione a Internet... 4 3.2

Dettagli