I see two different situations when
permissions/capabilities are concerned: the first is
when one tries to run untrusted code, modules or parts
of code and needs some kind of sanboxing mechanism.
Safe has been built with this situation in mind,
mostly.
The second is when one builds a perl system w
On Wed, Jan 29, 2003 at 09:20:33AM +, Thomas Whateley wrote:
> one more quick question.. would it be possible to play linker games
> to redirect syscalls (from compiled c) to wrapper functions that check
> permissions? Would that allow us to secure dynamicly linked libs??
When I said "as soo
* Dan Sugalski <[EMAIL PROTECTED]> [030128 19:30]:
> Ah, I've been hoping to avoid this for a while for sheer, screaming
> lack of tuits, but... Here's the deal for 'safe mode'. (For
> background, as everyone in the Unix world seems to be happy
> reinventing security wheels,
Hey! I wasn't try
On Tue, Jan 28, 2003 at 02:26:14PM -0500, Dan Sugalski wrote:
> *) There'll be a set of 'privileges' of some sort (call 'em
> capabilities or whatever) and to do various tasks will require that
> you have an appropriate privilege
Please don't use "capabilities" for this. The term "capability" is
At 11:41 AM + 1/28/03, Thomas Whateley wrote:
Hi,
I've been thinking about how to run un-trusted code,
without having to audit every line, or use some sort of sandbox,
and was wondering if Parrot could provide a Mandator Access
Control mechanism (ala SE Linux/Flask).
Ah, I've been hoping to
> "Brent" == Brent Dax <[EMAIL PROTECTED]> writes:
> I don't see why Parrot couldn't do much of this. It can
> certainly audit allocations made through its own
> memory-allocation system, and with only a little help from the
> system it should be able to audit its processor u
> "Matthew" == Matthew Byng-Maddick <[EMAIL PROTECTED]> writes:
>> I guess what I'm saying is, sure, you can't stop a native
>> function (which was called from parrot code) from doing
>> whatever it wants, but you can still prevent the parrot code
>> from using that function in
> On Tue, Jan 28, 2003 at 10:39:33AM -0600, Joseph Guhlin wrote:
> > Pardon my ignorance on the whole issue but I'm just a lurker trying to
> > understand enough to help out. =)
> > I know security on parrot like this would be difficult, and this thread
> > is specifically about securing PASM, but
On Tue, Jan 28, 2003 at 04:15:41PM +, Matthew Byng-Maddick wrote:
> On Tue, Jan 28, 2003 at 11:04:43AM -0500, Christopher Armstrong wrote:
> > Hrm, maybe I just don't know what's going on, but I'm not sure why
> > this is a problem. Couldn't "call out to native functions" or perhaps
> > "call o
On Tue, Jan 28, 2003 at 09:24:20AM -0800, Brent Dax wrote:
> Christopher Armstrong:
> # One other thing to think about is resource limits. It'd be nice to not
> # require `ulimit' or whatever system-specific resource limitation
> # mechanism, but rather rely on the parrot interpreter to
> # baby-si
Matthew Byng-Maddick:
# It seems to me that the linking with native code is going to
# end up being one that most people switch on, because it will
# be necessary and/or useful in getting anything done.
Then make sure that "link in native code" isn't a permission--"link in
native code library X"
Christopher Armstrong:
# One other thing to think about is resource limits. It'd be nice to not
# require `ulimit' or whatever system-specific resource limitation
# mechanism, but rather rely on the parrot interpreter to
# baby-sit. Also, it'd make catching these resource-limit violations
# much mo
On Tue, Jan 28, 2003 at 10:39:33AM -0600, Joseph Guhlin wrote:
> Pardon my ignorance on the whole issue but I'm just a lurker trying to
> understand enough to help out. =)
> I know security on parrot like this would be difficult, and this thread
> is specifically about securing PASM, but what abo
Pardon my ignorance on the whole issue but I'm just a lurker trying to
understand enough to help out. =)
I know security on parrot like this would be difficult, and this thread
is specifically about securing PASM, but what about something like
FreeBSD's 'jail' command built in? That way, even un
> I've been thinking about how to run un-trusted code,
> without having to audit every line, or use some sort of sandbox,
> and was wondering if Parrot could provide a Mandator Access
> Control mechanism (ala SE Linux/Flask).
I think that this is a great idea.
> When assembling Parrot, the assemb
On Tue, Jan 28, 2003 at 11:04:43AM -0500, Christopher Armstrong wrote:
> On Tue, Jan 28, 2003 at 02:11:39PM +, Matthew Byng-Maddick wrote:
> > What happens when you link in some module that's written natively?
> > Basically, my conclusion was that this was, unfortunately, still
> Hrm, maybe I j
On Tue, Jan 28, 2003 at 02:11:39PM +, Matthew Byng-Maddick wrote:
> On Tue, Jan 28, 2003 at 11:41:14AM +, Thomas Whateley wrote:
> > I've been thinking about how to run un-trusted code,
> > without having to audit every line, or use some sort of sandbox,
> [snip]
> > block to audit and be c
On Tue, Jan 28, 2003 at 11:41:14AM +, Thomas Whateley wrote:
> I've been thinking about how to run un-trusted code,
> without having to audit every line, or use some sort of sandbox,
[snip]
> block to audit and be certain of what a module/program could
> do to my system.
As author of http://de
On Tue, Jan 28, 2003 at 11:41:14AM +, Thomas Whateley wrote:
> Hi,
>
> I've been thinking about how to run un-trusted code,
> without having to audit every line, or use some sort of sandbox,
> and was wondering if Parrot could provide a Mandator Access
> Control mechanism (ala SE Linux/Flask)
19 matches
Mail list logo
