Student Introduction and Possible Proposal
Justin L. Harper
Good afternoon members of Parrot, my name is Justin Harper and I am an
undergraduate at Temple University from the Electrical Engineering
Department. Recently I contacted a Temple Alumni Mr. Whitworth after
he reached out to Temple's Engineering department about possible GSOC
candidates. Early on I proposed working on the "Improve Web UI of
app-parrot-create" or "New Assembly Language" projects. After further
talks with @whiteknight and @benabik I headed into the direction of
proposing the Security Sandboxing project. It is a project that can be
extended or shortened depending on time and possible constraints. The
over all goal of the project is to develop an interface that allows
the parent to set permissions on the child but not allow the child to
alter its own permissions. Right now it would allow bots in to execute
programs but keep users from coming in behind it and doing something
like create a delete all program as @whiteknight put it. I will be
working on the basic structure and interface that will allow for more
modules to be added in as time permits . If anyone has possible ideas
or suggestions towards this project I am open to any and all ideas. I
look forward to proposing and hopefully working on this project. Have
a great day!
--
Justin L. Harper
Electrical Engineering
Peer Partner Mentor
IEEE
Society of Automotive Engineer
Temple Taekwondo
Email: tuc4...@temple.edu
Cell: 215-866-6003
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
Moritz Lenz
welcome to the Parrot project, and thanks for your email.
Am 02.04.2012 18:47, schrieb Justin L. Harper:
> After further
> talks with @whiteknight and @benabik I headed into the direction of
> proposing the Security Sandboxing project. It is a project that can be
> extended or shortened depending on time and possible constraints.
As a developer of a downstream project (Rakudo), I'd be very interested
to see such a project implemented.
> The
> over all goal of the project is to develop an interface that allows
> the parent to set permissions on the child but not allow the child to
> alter its own permissions.
There's no reason the child wouldn't be allowed to tighten its own
security -- it just can't loosen it. In fact that's the model that UNIX
systems use for things such as process priority (the "nice" value)
> If anyone has possible ideas
> or suggestions towards this project I am open to any and all ideas.
PDD 18 [1] describes the high-level goals and mechanism. A GSoC project
surely isn't enough to implement all of it, but having *something* would
be a good start.
Another good source for inspiration is prior art in linux. There is the
ptrace mechanism for intercepting system calls [2], and selinux for
capability-based access control [3].
I haven't spent too much time thinking about the security system, so
take the following with a grain of salt.
I think the best approach to getting results fast is to implement
something like ptrace, where possibly dangerous operations (memory
allocations, IO, ...) trigger a callback, and that callback can then
allow or forbid the operation. For performance reasons it might make
sense to allow or forbid some operations right away without any
callback, but I guess that's only a second step.
Once such a system is in place, you can write a capability-based system
on top of that.
[1]
http://docs.parrot.org/parrot/devel/html/docs/pdds/pdd18_security.pod.html
[2] http://www.linuxjournal.com/article/6100
[3] https://en.wikipedia.org/wiki/Security-Enhanced_Linux
> I
> look forward to proposing and hopefully working on this project. Have
> a great day!
And I look forward to see the actual project proposal and the code :-).
Remember that the application deadline is the upcoming Friday, so don't
waste any time.
Cheers,
Moritz
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev