[ge-talk] Security services provided by OS

Adrian Sanabria adrian.sanabria at gmail.com
Sun Jan 7 21:52:09 EST 2007


Speaking of security, going to http://glasselevator.sourceforge.net yields a
pretty insecure error message (though it appears to be Sourceforge's
problem, because it is their error message):

An error has been encountered in accessing this page.

1. *Server:* glasselevator.sourceforge.net
2. *URL path:* /
3. *Error notes:* File does not exist:
/home/groups/g/gl/glasselevator/htdocs/
4. *Error type:* 404
5. *Request method:* GET
6. *Request query string:*
7. *Time:* 2007-01-07 18:47:40 PST (1168224460)

*Reporting this problem:* The problem you have encountered is with a project
web site hosted by SourceForge.net. This issue should be reported to the
SourceForge.net-hosted project (not to SourceForge.net).

*If this is a severe or recurring/persistent problem,* please do one of the
following, and provide the error text (numbered 1 through 7, above):

   1. Contact the project via their designated support
resources<http://sourceforge.net/support/prweb-lookup.php?host=glasselevator.sourceforge.net&support=1>.

   2. Contact the project administrators of this project via email (see
   the upper right-hand corner of the Project Summary
page<http://sourceforge.net/support/prweb-lookup.php?host=glasselevator.sourceforge.net>for
their usernames) at
   *user-name*@users.sourceforge.net

If you are a member of the project that maintains this web content, please
refer to the Site Documentation regarding the project web
service<https://sourceforge.net/docs/E07/>for further assistance.


--Adrian




On 1/7/07, Michael Phipps <mphipps1 at rochester.rr.com> wrote:
>
> Paul van Nugteren wrote:
> > Are you sure? Seems a pretty obvious idea...
> >
> >> Protection #2 (prevent application from destroying files) actually has
> a
> >> very simple solution which no OS really uses, which is quite puzzling.
> >> Simply restrict the application from only modifying files in its
> current
> >> directory or lower, but never higher.  ie. an application in
> >> /boot/apps/Sandbox  can only modify files in the Sandbox directory and
> >> lower
> >> (and obviously ~/config/settings/Sandbox).  If an application needs to
> do
> >> anything outside it's boundaries, pop up an alert asking for permission
> /
> >> password.  There is also a third directory which we will allow access
> to,
> >> and that is wherever the user open/saved a file to.  This approach
> allows
> >> audio players to access my MP3 directory, but never /boot/beos/system).
> >> Spawned applications inherit directory restrictions.
> >
> >
> > Still the mp3 player needs to write to '/dev/audio'. I think the system
> > should never allow it too read anything else than music files, but what
> > about private voice recordings? It could read those and secretly upload.
>
> That's a security issue, though. Or, at the very least, a sharing issue.
> I would hope that no one would ever write a Haiku mp3 player that doesn't
> use the media kit. Even if only to say "I need exclusive access to the
> audio for a while".
> _______________________________________________
> glasselevator-talk mailing list
> glasselevator-talk at bug-br.org.br
> http://www.bug-br.org.br/mailman/listinfo/glasselevator-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.bug-br.org.br/pipermail/glasselevator-talk/attachments/20070107/413e46c8/attachment-0001.html 


More information about the glasselevator-talk mailing list