Re: creating virtual users
On Fri, Feb 7, 2014 at 3:54 AM, <berenger.morel@neutralite.org> wrote:
> The idea may seems, and probably is, quite strange.
Not as strange as it used to seem, I think. More and more, you don't
have to be extremely paranoid to see these kinds of things.
> But I have seen for now 2 uses for it (there probably are more than those
> ones).
> _ Building a DE which would be a complete IDE, even for command line users
> as me.
This one is actually a really old one. I think every systems vendor
has wanted to provide (ergo, control) their customers' entire
application stack.
> Those of you which have written more than 500 lines of code knows
> that there exists tools which re-implement most of the system's features, to
> provide to the user an unified environment dedicated to programming.
As you notice below, even Unix was originally a unified environment.
In theory.
Anyway, the guys at Bell labs had a vision of a unified environment in
which basically everything in the system existed within the file
system, and in which all processes communicated by pipes. That vision
is a large part of the reason OSses which inherit their structure from
Unix are so stable.
> Examples for a generic IDE[1]: text edition,
I think you mean text editing?
But, then, what is text, in the broadest sense?
> file browsing, window
> management, project management, and a lot of other tasks. Some could say
> that even vim and emacs reimplements such things (does text editors needs to
> implement window management? file locking? is not their task to simply write
> text?
The question you seem to be asking is where to cut the boundaries
between application and system, is it not?
> I could go deeper there, but my ideas are all except conventional so I
> won't.
Not as unconventional as you seem to think, if you can learn to ignore
the mis-information rays emitted from Redmond.
> Flame wars are useless when you can't prove that your ideas are
> possible.).
Oh, come on. Flame wars erupt precisely when people argue about things
they don't understand.
Well, at least, in my experience and according to the way I see things. ;-)
> The problem being that, when a tool reimplement environment's
> features, it does not integrate with the look and feel of the global
> environment, in a portable manner (yes, this assertion includes windows. I
> said: portable.).
Unless the tool implementer has bought into the vendor's vision and
paid to attend the vendor's summer camps and somehow still seen
through the hype. If you know what I mean.
> _ now, I am reading documentation about TOR and TAIL[2] and am thinking that
> if it was possible to start programs with temporary virtual user or even
> system, it may make things a lot more simple to do secured[3] tasks.
Absolutely. That was supposed to be part of what sandboxes were all
about, by the way, but they seem to have been sidetracked by the sales
department and the accounting department.
> For now, I only had my 1st idea in mind, which is not very very important,
> but, my current readings ( about security and being anonymous when using a
> hotel's wifi connection ) makes me think that this issue may finally be an
> important one,
Definitely.
> which make me needing to learn the hows and whys ( other
> things it made me think about:
And Microsoft and the NSA think they need you to forget that need. And
let their software handle it all for you.
> my laptop computer is absolutely not secured,
> and by not being hidden I avoid other people to be hidden, for example. And,
> yes, I think that being able to hide himself is an ability to freedom, but
> the problems freedom may imply are not worse than the ones that the lack of
> freedom will prove. I am becoming more and more paranoid it seem.... )
Some people think freedom is about being freed of things that are hard
to think about and hard to do. By which, I mean to say, the
theoretical average customer is believed to not want to have to be
bothered. That theoretical average customer is the sales department's
best friend, according to the sales department.
> So, do anyone knows if there exist a desktop-usable ( windows, mac OS,
> linux, unix, and 'some'BSD are the only OSes that I've hear about which I
> can think to be usable) OS which allows a user to create a user, and if yes,
> which one and how?
It's not impossible.with present systems, you just need a bit of glue,
and some way to restrict how many and what kinds of user accounts
ordinary users are allowed to make. Just think of user ids as one more
kind of system resource.
> For example, when we run linux, we have a root user which is the creator of
> the system (uid=0 IIRC). He
> effectively creates a bootable system, and is the only one to have rights to
> create other users.
> If he gave to some of those users the rights to create other users, he needs
> to give them a total control on the system[4].
Well, you say you don't want to mess with sudo, and sudo could provide
one way to do this.
But you don't need sudo if you build a tool to allocate and manage
user ids as a system resource.
> This is a problem not only about creating users, and so home environment
> (sub-users) dedicated to some applications, but also about installing
> (non-system-wide-)software as a simple user, or installing a printer or even
> shutting down the computer (when you have physical access to it, indeed.
> linux is so server-centered that common sense is very often forgotten when
> you use it as a laptop system.
In one definition of a computer system, the system is a collection of
servers. That's why a server-centric OS is actually quite suited to
desktop use, once you start building the necessary servers into the
system.
> I accept those limitations happily when I see
> the system customization it gave me, however.). This problem led some of us
> to build tools like dbus, for example. But I think this is only "simple"
> workaround and that working around a problem simple makes things badder and
> badder.
Wel, dbus is one way of approaching the problem, but there are more
optimal ways.
> There is currently no way, in any OS, at least that I've heard about, to
> have such a "rights'tree", something which would allow any user to create
> other users which would only have at maximum their parent's rights.
Be careful of seeing every problem as a hierarchy to solve. That's
another old trap from way back.
> I guess that it would be complex to make such kind of recursive right
> system, but I still do not understand the reasons about why it would be
> complex.
Recursive solutions are great as long as recursion is shallow. It
doesn't take too many levels of recursion to go unbounded.
> I may seem... hum... pretentious and/or naive...
Naive is not necessarily a bad thing.
> but I wonder if it would be
> possible to build something like a virtual ring[5] system. Or I should say a
> bubble system, since in the (probably stupid, since I am not at all a
> security guy) idea I have, every user would be able to create users with
> less rights than they have.
> So:
> _root:
> _foo
> _foo_app1
> _foo_app2
> _bar
> _bar_app1
> _bar_app2
> _bar_app2_app1
> Would be possible. In this hypothetical structure, all root's children would
> be able to use root's tools[6], all bar's children would be able to use
> bar's tools.
And the problem is that my web browser is a child of my login manager,
and a sibling of my mail browser, and wants to connect with the mail
browser without having to go up to the login manager.
But, yeah, nested sandboxes are interesting.
> Currently, with the few information I have about user's management in
> Debian, I were able to simulate a virtual user's environment[1], which is
> not very hard. But it have a lot of security and functionnality issues: for
> example, bar_app2_app1 would be able to delete files belongings to bar_app1,
> because for the kernel, it is the same thing. The only interest I had was
> that the $HOME and $PATH could be changed independently[1]. It is ok for my
> first needs since a programmer should me someone which is responsible for
> his own files, but it does not fix the problem in [2].
> Also, using "$aptitude install libfoo-dev" will end nowhere, when it should
> install libfoo-dev only for current user... and so, only for the project the
> user currently works on.
>
> Sorry for that long, unordered read, given that it will probably lead us
> nowhere...
>
>
> 1: I've got some very strange ideas about building enough tools to transform
> a normal DE into an IDE for OOP programmers, but since I still have nothing
> to show I won't speak more about it... I would not be considered as as
> stupid than I am ;) so I'll try to realize bases myself before.
>
> 2: and an entry in tail says something which is obvious, but that I was
> never able to see myself: programs in the same session can share
> information! With all security problems that it can make.
Without the lateral connections, the system quickly reaches its
boundaries of usefulnes
> 3: security means a lot of things for me.
I think it means different things to just about everyone.
> Making it impossible to identify
> the author of a document, by any mean, is one of those. Being able to
> transmit something and that the receiver have the exact copy is another one.
> And lot more. Here, I am speaking about virtual temporary system and user.
> Being anonymous when you do not want to be known. Think as something like
> C++'s philosophy: you do not pay for something you did not explicitly
> mention you want to pay for.
>
> 4: I am speaking about systems without sudo. sudo makes things much more
> complex, by giving to a simple user the identity of root under certain
> circumstances only. But in the end, it's still root which does those action,
> plus an automate which log some actions. Am I right?
Not quite, unless you are aware of the -u option to sudo.
And, incidentally, if I have a user, bobex and a user bob and set sudo
up right, I can leave bobex with login disabled and either allow bob
to sudo to bobex without a password, or with bob's own password.
This is the advantage (and disadvantage) of sudo over su.
> 5: this mail is probably very messy, but it is because I am trying to think
> about that in the same time that I am writing it, plus to check my wording
> to make it as close as possible to an hypothetical technical solution.
> Here is the kind of rings I am thinking about:
> https://en.wikipedia.org/wiki/Ring_%28computer_security%29
>
> 6: except the tools root decided to not share. This is valid for all root's
> leafusers too. So, we have for each user a private tool library and a public
> one, with the public one which is only public for it's children... like in
> Oriented Object Programming for private and protected members ( each object
> can use any protected member of it's parent, in cascading style )
There is (was?) a distro that puts every app in its own directory and
sets the login users' path to point to a /home/user/bin directory that
only has links to the executables the user is allowed to run. I forget
what it was called.
--
Joel Rees
Be careful where you see conspiracy.
Look first in your own heart.
Reply to: