Quoting Adrian Chadd (from Mon, 10 Feb 2014
17:24:09 -0800):
On 10 February 2014 17:07, James Gritton wrote:
So is it worthwhile to add a new jail parameter called "insecure" (or
somesuch)? That way you could easily add the encapsulation without
any of the security. The other vibe I'm g
On 10 February 2014 17:07, James Gritton wrote:
> On 2/5/2014 12:05 PM, John Baldwin wrote:
>
>> I think having a "kmem" flag for jails is a hack and not the right
>> approach.
>> It does make a jail useless security-wise, but by masquerading as a flag,
>> it
>> implies that it is only partially v
On 2/5/2014 12:05 PM, John Baldwin wrote:
> I think having a "kmem" flag for jails is a hack and not the right
approach.
> It does make a jail useless security-wise, but by masquerading as a
flag, it
> implies that it is only partially violating security which gives a
false sense
> of securit
Wiadomość napisana przez James Gritton w dniu 4 lut 2014, o godz. 14:49:
> On 2/4/2014 6:23 AM, Julian Elischer wrote:
>> On 2/4/14, 3:40 PM, Robert N. M. Watson wrote:
>>> On 3 Feb 2014, at 23:53, Doug Ambrisko wrote:
>>>
It's unfortunate that vimage requires jail. I want to use vimage but
On Thursday, February 06, 2014 3:53:00 pm Alexander Leidinger wrote:
> On Wed, 05 Feb 2014 14:05:29 -0500
> John Baldwin wrote:
>
> > I think having a "kmem" flag for jails is a hack and not the right
> > approach. It does make a jail useless security-wise, but by
> > masquerading as a flag, it i
On Wed, 05 Feb 2014 14:05:29 -0500
John Baldwin wrote:
> I think having a "kmem" flag for jails is a hack and not the right
> approach. It does make a jail useless security-wise, but by
> masquerading as a flag, it implies that it is only partially
> violating security which gives a false sense o
On 5 Feb 2014, at 19:05, John Baldwin wrote:
> A short term solution that would permit non-security jails without having to
> do the longer term work that Robert would like might be to add a new per-jail
> flag that in effect means "no security at all". You would then modify one
> place (pri
On Wed, Feb 05, 2014 at 02:05:29PM -0500, John Baldwin wrote:
| On Monday, February 03, 2014 03:53:36 PM Doug Ambrisko wrote:
| > On Fri, Jan 31, 2014 at 06:28:27PM -0700, James Gritton wrote:
| > | On 1/31/2014 2:30 PM, Alexander Leidinger wrote:
| > | > On Fri, 31 Jan 2014 12:34:48 + (GMT)
|
On Monday, February 03, 2014 03:53:36 PM Doug Ambrisko wrote:
> On Fri, Jan 31, 2014 at 06:28:27PM -0700, James Gritton wrote:
> | On 1/31/2014 2:30 PM, Alexander Leidinger wrote:
> | > On Fri, 31 Jan 2014 12:34:48 + (GMT)
> | >
> | > Robert Watson wrote:
> | >> On Wed, 29 Jan 2014, Alexander
On 4 Feb 2014, at 13:23, Julian Elischer wrote:
> On 2/4/14, 3:40 PM, Robert N. M. Watson wrote:
>> On 3 Feb 2014, at 23:53, Doug Ambrisko wrote:
>>
>>> It's unfortunate that vimage requires jail. I want to use vimage but
>>> not have the security restrictions of a jail. To do this I patched
On 2/4/2014 6:23 AM, Julian Elischer wrote:
On 2/4/14, 3:40 PM, Robert N. M. Watson wrote:
On 3 Feb 2014, at 23:53, Doug Ambrisko wrote:
It's unfortunate that vimage requires jail. I want to use vimage but
not have the security restrictions of a jail. To do this I patched
jail to basically
On 2/4/14, 3:40 PM, Robert N. M. Watson wrote:
On 3 Feb 2014, at 23:53, Doug Ambrisko wrote:
It's unfortunate that vimage requires jail. I want to use vimage but
not have the security restrictions of a jail. To do this I patched
jail to basically let everything through. It would be nice to
On 4 Feb 2014, at 10:05, Ivan Voras wrote:
> On 31 January 2014 18:28, James Gritton wrote:
>> On 1/31/2014 5:34 AM, Robert Watson wrote:
>
>>> Frankly, I'd like to see this backed out and not reintroduced. If it must
>>> be retained, then it needs a much more clear warning that enabling this
On 31 January 2014 18:28, James Gritton wrote:
> On 1/31/2014 5:34 AM, Robert Watson wrote:
>> Frankly, I'd like to see this backed out and not reintroduced. If it must
>> be retained, then it needs a much more clear warning that enabling this
>> feature disables Jail's security model. Don't us
On 4 Feb 2014, at 07:53, Adrian Chadd wrote:
> I really would rather see Xorg gain whatever abstraction is necessary
> to probe/attach/interface with a DRI API supported graphics card.
>
> So, this then becomes a question of whether this is needed for DRI API
> supported graphics cards, or whet
On 31 January 2014 17:28, James Gritton wrote:
> I second the documentation route. Yes, it's true that this option
> makes a totally insecure jail - at least one lacking the expected jail
> security additions. But I think that while security is one of the
> primary purposes of jails, it's not
On 3 Feb 2014, at 23:53, Doug Ambrisko wrote:
> It's unfortunate that vimage requires jail. I want to use vimage but
> not have the security restrictions of a jail. To do this I patched
> jail to basically let everything through. It would be nice to be
> able to run jail in an insecure mode w
On Fri, Jan 31, 2014 at 06:28:27PM -0700, James Gritton wrote:
| On 1/31/2014 2:30 PM, Alexander Leidinger wrote:
| > On Fri, 31 Jan 2014 12:34:48 + (GMT)
| > Robert Watson wrote:
| >> On Wed, 29 Jan 2014, Alexander Leidinger wrote:
| It does. I included a warning in jail.8 that this wil
On 1/31/2014 2:30 PM, Alexander Leidinger wrote:
> On Fri, 31 Jan 2014 12:34:48 + (GMT)
> Robert Watson wrote:
>> On Wed, 29 Jan 2014, Alexander Leidinger wrote:
It does. I included a warning in jail.8 that this will pretty
much undo jail security. There are still reasons some may
On Fri, 31 Jan 2014 12:34:48 + (GMT)
Robert Watson wrote:
> On Wed, 29 Jan 2014, Alexander Leidinger wrote:
>
> >> It does. I included a warning in jail.8 that this will pretty
> >> much undo jail security. There are still reasons some may want to
> >> do this, but it's definitely not for
On 1/31/2014 5:34 AM, Robert Watson wrote:
On Wed, 29 Jan 2014, Alexander Leidinger wrote:
It does. I included a warning in jail.8 that this will pretty much
undo jail security. There are still reasons some may want to do
this, but it's definitely not for everyone or even most people.
It o
On Wed, 29 Jan 2014, Alexander Leidinger wrote:
It does. I included a warning in jail.8 that this will pretty much undo
jail security. There are still reasons some may want to do this, but it's
definitely not for everyone or even most people.
It only "unjails" (= basically the same security
Hi Jamie:
As these privileges basically allows root processes in jail to break out of
jail, I think this needs a much more clear signpost that this is a very unsafe
thing to turn on. I can imagine scenarios where this might be useful, but
can't really imagine any where it is 'safe' with resp
On Wed, 29 Jan 2014 06:49:01 -0700
James Gritton wrote:
> On 1/29/2014 6:43 AM, Gleb Smirnoff wrote:
> > Doesn't this allow to easily unjail self? :)
> It does. I included a warning in jail.8 that this will pretty much
> undo jail security. There are still reasons some may want to do this,
>
It does. I included a warning in jail.8 that this will pretty much
undo jail security. There are still reasons some may want to do this,
but it's definitely not for everyone or even most people.
- Jamie
On 1/29/2014 6:43 AM, Gleb Smirnoff wrote:
On Wed, Jan 29, 2014 at 01:41:13PM +, Jamie
On Wed, Jan 29, 2014 at 01:41:13PM +, Jamie Gritton wrote:
J> Author: jamie
J> Date: Wed Jan 29 13:41:13 2014
J> New Revision: 261266
J> URL: http://svnweb.freebsd.org/changeset/base/261266
J>
J> Log:
J> Add a jail parameter, allow.kmem, which lets jailed processes access
J> /dev/kmem and
Author: jamie
Date: Wed Jan 29 13:41:13 2014
New Revision: 261266
URL: http://svnweb.freebsd.org/changeset/base/261266
Log:
Add a jail parameter, allow.kmem, which lets jailed processes access
/dev/kmem and related devices (i.e. grants PRIV_IO and PRIV_KMEM_WRITE).
This in conjunction with c
27 matches
Mail list logo
