l4-hurd
[Top][All Lists]
Advanced

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

Re: Supporting POSIX *users*


From: Michal Suchanek
Subject: Re: Supporting POSIX *users*
Date: Fri, 28 Oct 2005 15:49:05 +0200

On 10/27/05, Alfred M. Szmidt <address@hidden> wrote:

>    >    Right, you want to secure your system by not making the wrong
>    >    syscalls in your code?  And why do you think a hostile application
>    >    is going to live by that rule?
>    >
>    > And by not implementing the `evil syscalls', as I have said repetedly!
>    > You cannot use a syscall if it doesn't exist.  That is what I mean by
>    > don't call it, don't use it, etc.
>
>    Cool. Please remove open(), socket(), [gs]etuid(), and fork() for
>    starters.
>
> There is nothing (fundamentally) wrong with open(), socket() or
> fork().  getuid/setuid are simple to work around, which is done on the
> Hurd (on Linux it is a syscall, we just wrap it around so auth is
> happy and provide something similar, a bit to similar...).
>
>    Seriously: I think you have not actually sat on a standards
>    committee if you can say this.
>
> And I think that you have missed the shalls/must bits in the standard.
> There are lots of optional bits in POSIX.
>
>    Alfred: you are simply wrong. And you have been pointed at the
>    formal results that conclusively, mathematically *prove* that you
>    are wrong, you have ignored them, and you persist in making this
>    wrong assertion.
>
> Sorry, but it is you who are wrong, you constantly refer to scientific
> `proofs' that have no realition to reality.  I really don't care about
> a 100% secure system, why? Because it isn't practical to implement.
> In theory it is all dandy, but in reality it is a pile of unusable
> crap.

In practice the POSIX system we have now are all crap. And since they
have been evolving for a  few tens of years at least I guess they have
reached their limits.
I haven't read the papers proving that.

In practice it *is* a great problem if you can only choose to let
unrusted code like browser plugins or java applets to either access
everything you can access, or not running them at all.  Whenever I
think about security of my system it makes me shiver. A single bug in
a single application allows the attacker access to the whole system.
In multiuser systems the attacker may only compromise one or few users
accounts. But from my point of view it is irrelevant if it was my
account. There is no way around this, except designing and
implementing a system that aids the users in limiting what an
application can do.
I was somewhat disappointed when I learned such design is possible but
the Hurd does not implement it. Now that such design is discussed I am
more interested in the Hurd again. But I am not a GNU fanatic. If a
free system provides better security and an usable set of applications
I will likely use that, be it GNU, GNU/EROS, or anything copletely
unrelated to GNU.

Thanks

Michal Suchanek


--
             Support the freedom of music!
Maybe it's a weird genre  ..  but weird is *not* illegal.
Maybe next time they will send a special forces commando
to your picnic .. because they think you are weird.
 www.music-versus-guns.org  http://en.policejnistat.cz

reply via email to

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