~misterio/IC

989aa6006efa5e95b4c4ad23d4977a0c5308fdf1 — Gabriel Fontes 1 year, 9 months ago ae5ed0c
revisão 2

- Retrabalhar três critérios na introdução
- Explicar as duas diferentes classes de solução
- Trocar o foco do trabalho em integrar diferentes sistemas existentes
- Unir estudo de caso com objetivo e metodologia
- Expandir metodologia, incluindo atividades e aplicação
- Adicionar planejamento de atividades/mês
2 files changed, 147 insertions(+), 80 deletions(-)

M project/notes.md
M project/project.md
M project/notes.md => project/notes.md +2 -0
@@ 1,5 1,7 @@
# Notas de estudo

- Agradecer a prof por clarificar o significado de metodologia

- Roteiro:
    - Não permitir nenhuma maneira de escrita no hardware, mesmo com root
        - Travar setup, bootar apenas do netboot

M project/project.md => project/project.md +145 -80
@@ 1,4 1,4 @@
# A safe, flexible computer science laboratory backed by free software
# Safe, flexible, and reproductible free software backed computer science laboratories

Student: Gabriel Silva Fontes



@@ 10,7 10,7 @@ Advisors: Dr. Elisa Yumi Nakagawa; Dr. Francisco José Monaco
**Keywords**: computer laboratory, configuration management, higher education,
learning environments, free software

## 1. Introduction
## 1. Introduction and motivation

Computer laboratories are an essential piece of public infrastructure, even
more so for high education institutions focused on computing fields. Having


@@ 19,104 19,169 @@ for extracurricular activities, plays an important role in computer sciences
learning[1], particularly for students who can't afford a computer of their
own.

Building these environments are not simple tasks, however. Laboratories, like
most IT systems shared between people, can't be considered trusted
environments; they must have a high degree of protection and isolation, as to
prevent users' actions from compromising their peers' safety and privacy.
Building this kind of environment is not a simple task, however. Laboratories,
like most shared IT systems, can't be considered trusted environments; they
must have a high degree of protection and isolation, as to prevent users'
actions from compromising their peers' safety and privacy.

Specially in the aforementioned computer-related institutions, flexibility is
even more important: each student might prefer to use different software
tooling, and each class or subject might require completely different software
stacks.
Specially in the aforementioned computer-related institutions, flexibility is a
crucial aspect: each student might prefer to use different software tooling,
and each class or subject might require completely different software stacks.

It is visible that administrators thus have to strike a careful balance between
user security and flexibility, while keeping maintenance burden under control.
When both high security and flexibility are required, IT maintenance burden
usually increases quickly, as these teams are met with constant software
installation requests. It is visible that administrators thus have to strike a
careful balance between security, flexibility, and maintainability.

### 1.1 Existing solutions

Security usually requires denying superuser privileges to users. Most computer
operating systems do not natively support unprivileged software management,
forcing IT administrators to fully handle installing and maintaining (a
specific subset of) packages.
All security enforcement solutions can be understood as a process of making
users' state ephemeral and/or isolated from one another.

All solutions boil down to some sort of isolation between different users'
state: be it enforced by the operational system, for example Microsoft's Active
Directory; or by lower level resources, such as virtual machines or
network-boot images.
Userspace software, such as Microsoft's industry-standard Active Directory,
can't enforce its policies without restricting flexibility, including
user-driven software installation. This limitation forces IT administrators to
fully handle installing and maintaining (a specific subset of) packages.

Each of these bring different advantages and issues to laboratories, some
haven't been previously formally applied to the computer lab issue. Thorough
investigation and research is required to provide the best possible solution.
Lower level resources, such as user-managed virtual machines or network-imaged
systems, have their own set of limitations; it's difficult to offer
functionalities that require specific userspace software (network-based data
persistence and authentication), guarantee performance and hardware
integration, as well as maintaining ease of use.

## 2. Objective

With this work, the author aims to research, build, and evaluate a computer lab
system that will help increase user software freedom, enforce tight security,
and decrease IT management burden; all simultaneously.

## 3. Methodology

This project will be worked on with a smaller scale laboratory, backed by
existing infrastructure provided by ICMC's *Open Source Competence Center*
(CCOS), steered by the work's advisors; while involving contributions from the
*Free and Open Source Extension Group* (GELOS), whom the author is the current
student lead of.

Desirable side-effects from the partnership include: more exhaustive knowledge
of technological options, exposing newer members to system configuration
practices, as well as helping develop the group's newly acquired physical
space.

**Obs: faz sentido relatar isso?**

Results will be measured by three benefit groups the solution must provide to
its users: software and workflow flexibility, safety and privacy, and universal
ease of use.
Making those systems reproductible should also be a priority, as to help with
scaling, easy (re)deployment, software updates and rollbacks, as well as
testing and validating. This attribute is not usually met, adding complicated
and error-prone deployment processes to the already extensive list of tasks.

Two kinds of evaluation methods will be employed: acceptance testing with
different user groups to evaluate workflows and ease of use, and well as
penetration testing to evaluate the system's security.

## 4. Case study and expected outcomes

University of São Paulo's Institute of Math and Computer Sciences (ICMC/USP),
the executing institution, is currently facing a prime example of the problem.

Recently, due to ever higher maintenance burden, the IT team had no choice but
to decrease the amount of software offered: making only Microsoft Windows
available to students, who previously could choose between it and Ubuntu Linux.

This situation affects classes that are better ministrated with Unix-like
systems, as well as students with (free) software preferences. Making this a
case where software flexibility is severely limited.
## 2. Objective

This project aims to research, design, and implement a solution that is both
more secure and flexible than any of the previous implemented at ICMC.
The main goal of this work is to research and integrate different types of
isolation and configuration solutions into a freely licensed, complete,
reproductible, extendable, highly secure, and user-centric computer laboratory
management system.

The results might thus have an immediate application: presenting solutions to
the IT team and potentially helping improve the institution's laboratories.
With reproductibility, extendability, and free licensing being requirements,
the work will hopefully be easily reused by different institutions, potentially
helping IT teams solve those commonly faced challenges. An immediate potential
application, which will serve as basis for the main use cases, is decribed in
the next section (2.1).

**Obs: É ruim colocar um estudo de caso tão específico? Pode dar problema?**
### 2.1 Practical application

## 5. Work plan and schedule
There is an immediate situation where the work could be applied to. University
of São Paulo's *Institute of Math and Computer Sciences* (ICMC/USP), the
executing institution, is currently facing an instance of the problem
described.

The project is scheduled to be conducted, at most, over the course of a year,
but plans on having relevant results in time for SICUSP (USP's Scientific
Initiation Symposium), which happens in november.
Due to ever increasing maintenance, the IT team was forced to decrease the
software offerings on the institution's laboratories: making only Microsoft
Windows available to students, who could previously choose between it and
Ubuntu Linux. This situation is an example of how burden and flexibility
relate.

**Obs: O "at most" é ruim?**
Lack of Linux operating system offerings, specifically, affects classes that
are ministrated with Unix-like systems in mind, reduces students' software
choices, and even threatens widespread free software adoption within ICMC.

A broad schedule is:
- About 2 months of study and evaluation of literature and existing solutions
- Between 2 and 3 months for implementing an initial version of the solution
- Between 2 and 3 months for evaluating and polishing the solution
- Between 2 and 4 months for writing and submitting the work
## 3. Methodology

**Obs: Faz sentido? O último em especial.**
With the practical application (2.1) in mind, this project will be worked on as
a more secure, flexible, and easier to maintain alternative than previous
laboratory managements system implementations.

The work will be initially conducted within a smaller scale laboratory, backed
by existing infrastructure provided by ICMC's *Open Source Competence Center*
(CCOS), steered by the work's advisors; we will also encourage contributions by
members of the *Free and Open Source Extension Group* (GELOS), whom the author
is the current student lead of.

Activities can be grouped in four distinct phases: (i) researching solution
pieces and use cases, (ii) integrating the systems together and building a
stable and fitting release, (iii) final polishing and workflow/security
testing, (iv) evaluating the finished solution.

It should be noted that the author has some previous experience with the
problem domain, and has already briefly researched a small subset of the
possible solution components.

The first phase will consist in studying existing solutions further and how to
integrate them, through literature research and experimentation with select
subsets of the intended features. It will also include investigating possible
use cases and their priorities, through surveys and literature. A promising
stack will be eventually chosen, as well as which use cases to contemplate and
prioritize.

During the second phase, the system itself will be developed: through means of
integrating existing pieces, as well as potentially writing new software for
missing gaps; use cases will be further refined. The process will go through
agile development cycles, with constant evaluation conducted with assistance
from GELOS members: helping validate, polish, walking torwards a release
candidate. The project will go through continous (and automated) testing and
deployment.

For the third phase, the release will be further polished by running two
different evaluations: acceptance tests with a wide variety of user groups, to
determine if the system fits their workflows and has intuitive usage; extensive
penetration testing, to guarantee the system's (critical) security.

During the fourth (and last) phase, the final system will be evaluated with
criteria similar to the third phase, but in a potentially different
infrastructure and without suffering any further major changes. This will serve
the purpose of evaluating the ease of deployment and overall success of the
finished project.

Desirable side-effects from the promoted GELOS student contributions include:
obtaining more exhaustive awareness of existing solutions; introducing less
experienced members to system configuration, automated deployment, and free
software development practices; helping develop the group's newly acquired
physical space.

Results from this work will be submitted to relevant scientific initiation
conferences, such as SIICUSP (USP's International Symposium of Scientific and
Technological Initiation).

While not officially affiliated with ICMC's IT team in any way, the finished
project will be proposed to them as a potentially helpful basis to contribute
with solving the currently faced problems.

## 4. Work plan and schedule

The planned activities are listed below, followed by a table presenting their
forecasted timeframes.

1. Software components study, use case investigation
2. Development iterations with continuous testing and feedback loops
3. Community acceptance and penetration testing
4. Polishing and fixes based on community tests
5. Final full system evaluation
6. Evaluation analysis
7. Writing reports
8. Applying results to case studies

+-------------------------+---+---+---+---+---+---+---+---+---+----+----+----+
| Activities\\Month       | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 |
+=========================+===+===+===+===+===+===+===+===+===+====+====+====+
| 1                       | x |   |   |   |   |   |   |   |   |    |    |    |
+-------------------------+---+---+---+---+---+---+---+---+---+----+----+----+
| 2                       |   | x | x |   |   |   |   |   |   |    |    |    |
+-------------------------+---+---+---+---+---+---+---+---+---+----+----+----+
| 3                       |   |   |   | x |   |   |   |   |   |    |    |    |
+-------------------------+---+---+---+---+---+---+---+---+---+----+----+----+
| 4                       |   |   |   | x |   |   |   |   |   |    |    |    |
+-------------------------+---+---+---+---+---+---+---+---+---+----+----+----+
| 5                       |   |   |   |   | x | x |   |   |   |    |    |    |
+-------------------------+---+---+---+---+---+---+---+---+---+----+----+----+
| 6                       |   |   |   |   |   | x | x |   |   |    |    |    |
+-------------------------+---+---+---+---+---+---+---+---+---+----+----+----+
| 7                       |   |   |   |   |   | x | x | x | x |    |    |    |
+-------------------------+---+---+---+---+---+---+---+---+---+----+----+----+
| 8                       |   |   |   |   |   |   |   |   | x | x  | x  | x  |
+-------------------------+---+---+---+---+---+---+---+---+---+----+----+----+

## References

**TODO: embasar afirmações com mais referências**
**TODO**

1. Newby, M & Fisher, D. _A Model of the Relationship between University
   Computer Laboratory Environment and Student Outcomes_. Learning Environments