l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sysadmins


From: Leonardo Lopes Pereira
Subject: Re: Sysadmins
Date: Wed, 2 Nov 2005 22:24:04 -0300

On Wed, 2 Nov 2005 18:43:48 -0600
William Grim <address@hidden> wrote:

> On 11/2/05, Leonardo Lopes Pereira <address@hidden> wrote:
> >
> > After a quick discuss with marco_g on IRC, i started to thing about Why we
> > need a sysadmin. And I realize that only small options on the system need
> > the admin interference. I saw that many people here are very fanatic about
> > security, but what about a system with a admin that put backdoors on
> > programs?
> 
>  As you mention later in this post, you need to trust the software that is
> installed to make use of it. If you don't trust the software, don't use it.
> I'll get back to this in just a few moments.
> 
> > So, if we will design a system where people can fell secure, we need to
> > create a system where the admin has less power as possible.
> 
>  This particular idea is still new to me. We definitely do need to discuss
> this to give me a better idea of how it would work in real life.
I am not an security paranoic. But I cannot trust in someone that I do not know 
who is. I am the sysadmin of my computer, I trust on myself. My brother is the 
sysadmin of the other computer that I have, I trust him. But I do not know who 
is the sysadmin of the computer of my university. How can I know if it will not 
put backdoors on the programs? How can I know if there is no spyware on the 
computer? I _CANNOT_ trust on it.

So, I will only be safe in a system that I am _SURE_ that it have almost the 
same power that I have on the system. I will be safe only in a system where it 
only can configure some small things, like the disk quote, cpu quote, boot 
manager...

> > In my opinion, the admin is a user that will be able ONLY to configure some
> > parts of the system that cannot be configured by a user. All other things
> > that the admin needs to do, like run a server, will be done by a common user
> > with no more power than other users.
> 
>  Again, this idea is new to me. We need to discuss it more. Any papers that
> talk about this topic would be welcome.
I do not know if someone have writen something about that, but, to me, It seens 
easy to understand, the sysadmin has no power to change things that can damage 
me. Only a small list of special things can be done only by him and his actions 
are not more safe than an anonymous actions in the system.
 
> > To install programs we can create a mechanism that every user can install
> > programs that will be avaliable to every users. but all programs would be
> > signed on their origin, and if the user trust on that origin, this program
> > will be able to work perfectly, if the user doesn't trust on the origin of
> > the program it will be alerted about that and will choose how this program
> > will run.
> 
>  That is definitely one idea. There are probably other ideas on how we could
> do this as well, but I haven't thought about it much. My head has been
> wrapped around the talks of persistent design and a device driver framework.
> I'll be interested in seeing more about this.

I am sure that we will have betters idea in the future, I only thought 15 
minutes about it. If you are thinking about a Device driver framework, I think 
that the user need the right do load their own drivers.

Example: I bought a new USB device and There is no driver on the system do it. 
I wrote the driver to it. Why I need to ask to the Sysadmin to load this 
driver? I think that the user need the right to load their own drivers. I am 
sure that this will require many mechanisms to turn this secure, but this is a 
good goal, IMHO.

> 
> > With no access to FS, with a read-only access to FS or if the user will
> > start to trust on that origin.
> >
> You are using acronyms like "FS", which I believe you to mean as
> "filesystems". If we are going to move forward with a totally persistent OS
> (i.e. a single-level-store[1] for all data), then we need to start talking
> about the "filesystem" as a data store that has objects and capabilities
> associated with those objects and get rid of the classical concept of
> filesystems. I'm not griping with you, but if we use old terms, we are going
> to get them confused with new ideas.
>  [1]: <a href=http://www.eros-os.org/papers/storedesign2002.pdf>Design
> Evolution of the EROS Single-Level Store</a>

My idea is almost generic in the case of filesystem access. I do not know 
another term to talk about filesystem in a persistent and capability-based 
system, so, I will still using the term filesystem, sorry.

I will try to rewrite it with others terms, but i think that it will become 
more confuse than it was.

If you have a program installed on the system, the first stage of the system 
will be check if the origin of the binary is on the list of trusted origins. If 
it is, it will have access to all capabilities that is configured to have. If 
it isn't, the system will show to the user what is the origin of the binary and 
will ask what to do: *1* Add this origin to the trusted origins list and you 
will have the same of the previou, *2* Run as a trusted program but without add 
the origin to the trusted list (if you run the program more on time it will ask 
more on time what to do), *3* Run in a secure space, with no access to 
capabilities to edit or read the files (we could create a special place where 
this program can create and edit files)
> 
> --
> William M. Grim
> Computer Science Master's Student, Southern Illinois University at
> Edwardsville
> Unix Network Administrator, SIUE, CS. Dept.
> 


-- 
leonardolopespereira at gmail.com

GNU Privacy Guard (GPG)
ID da chave: 83E8AFBF | servidor: keys.indymedia.org
gpg --keyserver keys.indymedia.org --recv-keys 83E8AFBF

Attachment: pgp1XLCSLGCKO.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]