Re: vnet jail and ipfw/nat on host - keep-state problem?

2014-07-12 Thread Ian Smith
On Sat, 12 Jul 2014 08:24:36 +0200, Kurt Jaeger wrote:
 > Hi!
 > 
 > > > On Sat, Jul 12, 2014 at 1:33 AM, Fbsd8  > > > wrote:
 > [...]
 > > Here is a list of some of the vnet/vimage outstanding PR's
 > >
 > > 143808, 147950, 148155, 152148, 160496, 160541, 161094, 164763, 165252, 
 > > 176112, 176929, 178480, 178482, 179264, 182350, 185092, 188010, 191468
 > 
 > 188010 was committed 2014-03-27 -- why is it still outstanding ?

185092 was also fixed and merged back to stable/10 and stable/9 in May.

I'm not about to check all of them .. we're used to these sour grapes.

cheers, Ian
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"


[Bug 133265] [jail] is there a solution how to run nfs client in jail environment?

2014-07-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133265

jo...@a1poweruser.com changed:

   What|Removed |Added

 CC||jo...@a1poweruser.com

--- Comment #5 from jo...@a1poweruser.com ---
Close this pr.
In kernel ntfs has been removed from 10.0 base see
http://svnweb.freebsd.org/base/head/sbin/Makefile?view=log&pathrev=247665

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"


[Bug 133265] [jail] is there a solution how to run nfs client in jail environment?

2014-07-12 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133265

Lukasz Wasikowski  changed:

   What|Removed |Added

 CC||luk...@wasikowski.net

--- Comment #6 from Lukasz Wasikowski  ---
ntfs is something completely different than nfs, this PR stands valid.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"


Re: vnet jail and ipfw/nat on host - keep-state problem?

2014-07-12 Thread Fbsd8

Sham on you Peter Toth.
Slander and calling names about someone who does not agree with you is 
childish and something I would expect from a 10 year old.


This foolish post only shows how unprofessional your behavior is.
Sham on you.

Every thing stated by me is the truth and verified by the outstanding 
pr's. If you can't trust the PR system as credible, then what can you trust.


I don't disagree that you may have a working vnet/vimage configuration 
running on your hobby host system or that your foolishly exposing your 
hobby host system to public network attack and host system takeover. 
There is a very big difference between software that does not crash when 
started and software that performs within its design parameters. I think 
just because your configuration does not crash means to you its working 
as expected. This is foolish in light of all the negative warnings about 
vimage.


vimage is experimental and nothing you say can change that fact. Readers 
don't believe me or Peter Toth and review the listed pr numbers and do 
your own search of bugzilla on keyword vnet or vimage and make up your 
own mind.



Peter Toth wrote:
Dear Joe Barbish (alias  fb...@a1poweruser.com 
),


When you going to stop trolling the FreeBSD mailing list and spread 
disinformation? 

People come to this place to learn, share information, help out other 
folks and most importantly to have a constructive debate! (obviously 
some would rather divert this effort)


The PR number's mentioned are mostly outdated from the 8.x and 9.x 
series - some of them are completely irrelevant (like ACPI) or for a 
i386 system.
Beyond this I am categorically refusing to waste any energy and time on 
answering any trolling/diversion attempts by Joe Barbish.


I am not going to burn time on dissecting each PR one-by-one but rather 
share my experience with VNET.


Over the last year and a half have deployed numerous production systems 
based on amd64 10-RELEASE with VNET enabled and PF running on the host.
Encountered 0 instability issues! Details on how to do this are 
here: http://iocage.readthedocs.org/en/latest/real-world.html


As I mentioned before IPFW works in a jail and PF only works on the host.

Back to the original issue though, Peter could you please share your 
IPFW config with me (maybe just send it directly to me), would be very 
interested to get it going in my lab setup and add a howto page to share 
this with others.


Cheers,
Peter


On Sat, Jul 12, 2014 at 1:16 PM, Fbsd8 > wrote:


Peter Toth wrote:

On Sat, Jul 12, 2014 at 1:33 AM, Fbsd8 mailto:fb...@a1poweruser.com> >__> wrote:

Peter Toth wrote:

Have not used natd with IPFW much as always preferred PF
to do
everything
on the host.

I have only a wild guess - the "me" keyword in IPFW is
substituted only to
the host's IPs known to itself.
The host's IPFW firewall most likely doesn't know
anything about IPs
assigned to vnet interfaces inside the jail.

Vnet jails behave more like separate physical hosts.

Internet ---> [host] --- (10.0.10.0 LAN) -->
[vnet jail]

The PF issue inside a jail is a separate problem, PF is
not fully
VIMAGE/VNET aware as far as I know.

Can someone comment on these or correct me?

P



On Fri, Jul 11, 2014 at 7:11 PM, Peter Ross
mailto:peter.r...@alumni.tu-__berlin.de
>>

wrote:

On Thu, 10 Jul 2014, Peter Toth wrote:

 Hi Peter,

Try to make these changes:

net.inet.ip.forwarding=1   # Enable IP
forwarding
between interfaces
net.link.bridge.pfil_onlyip=0  # Only pass IP
packets
when pfil is enabled
net.link.bridge.pfil_bridge=0  # Packet filter
on the
bridge interface
net.link.bridge.pfil_member=0  # Packet filter
on the
member interface

You can find some info
here
   
http://iocage.readthedocs.org/en/latest/help-no-internet.html



   
>

I've had these issues before with PF and IPFW, by
 

Re: vnet jail and ipfw/nat on host - keep-state problem?

2014-07-12 Thread Łukasz Wąsikowski
W dniu 2014-07-12 16:52, Fbsd8 pisze:

> Sham on you Peter Toth.
> Slander and calling names about someone who does not agree with you is
> childish and something I would expect from a 10 year old.
> 
> This foolish post only shows how unprofessional your behavior is.
> Sham on you.

And this came from person who stole someone else work [1] and then call
original author paranoid, mentally ill and demential [2]

Shame on you Joe Barbish. We remember what you did.

Anyway, it's not your business to decide for others what they should run
on production. It's their choice and their risk.

[1] Claiming copyright on others work is stealing for me:
http://lists.freebsd.org/pipermail/freebsd-jail//2013-March/002147.html

[2] http://lists.freebsd.org/pipermail/freebsd-jail//2013-March/002149.html

-- 
best regards,
Lukasz Wasikowski
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"


Re: vnet jail and ipfw/nat on host - keep-state problem?

2014-07-12 Thread Peter Toth
Unfortunately you don't even grasp what the meaning of the words like:
shame, truth, childish or professional is - and that's the bottom line
mate.




On Sun, Jul 13, 2014 at 2:52 AM, Fbsd8  wrote:

> Sham on you Peter Toth.
> Slander and calling names about someone who does not agree with you is
> childish and something I would expect from a 10 year old.
>
> This foolish post only shows how unprofessional your behavior is.
> Sham on you.
>
> Every thing stated by me is the truth and verified by the outstanding
> pr's. If you can't trust the PR system as credible, then what can you trust.
>
> I don't disagree that you may have a working vnet/vimage configuration
> running on your hobby host system or that your foolishly exposing your
> hobby host system to public network attack and host system takeover. There
> is a very big difference between software that does not crash when started
> and software that performs within its design parameters. I think just
> because your configuration does not crash means to you its working as
> expected. This is foolish in light of all the negative warnings about
> vimage.
>
> vimage is experimental and nothing you say can change that fact. Readers
> don't believe me or Peter Toth and review the listed pr numbers and do your
> own search of bugzilla on keyword vnet or vimage and make up your own mind.
>
>
> Peter Toth wrote:
>
>> Dear Joe Barbish (alias  fb...@a1poweruser.com > fb...@a1poweruser.com>),
>>
>>
>> When you going to stop trolling the FreeBSD mailing list and spread
>> disinformation?
>> People come to this place to learn, share information, help out other
>> folks and most importantly to have a constructive debate! (obviously some
>> would rather divert this effort)
>>
>> The PR number's mentioned are mostly outdated from the 8.x and 9.x series
>> - some of them are completely irrelevant (like ACPI) or for a i386 system.
>> Beyond this I am categorically refusing to waste any energy and time on
>> answering any trolling/diversion attempts by Joe Barbish.
>>
>> I am not going to burn time on dissecting each PR one-by-one but rather
>> share my experience with VNET.
>>
>> Over the last year and a half have deployed numerous production systems
>> based on amd64 10-RELEASE with VNET enabled and PF running on the host.
>> Encountered 0 instability issues! Details on how to do this are here:
>> http://iocage.readthedocs.org/en/latest/real-world.html
>>
>> As I mentioned before IPFW works in a jail and PF only works on the host.
>>
>> Back to the original issue though, Peter could you please share your IPFW
>> config with me (maybe just send it directly to me), would be very
>> interested to get it going in my lab setup and add a howto page to share
>> this with others.
>>
>> Cheers,
>> Peter
>>
>>
>> On Sat, Jul 12, 2014 at 1:16 PM, Fbsd8 > fb...@a1poweruser.com>> wrote:
>>
>> Peter Toth wrote:
>>
>> On Sat, Jul 12, 2014 at 1:33 AM, Fbsd8 >  >
>> >__> wrote:
>>
>> Peter Toth wrote:
>>
>> Have not used natd with IPFW much as always preferred PF
>> to do
>> everything
>> on the host.
>>
>> I have only a wild guess - the "me" keyword in IPFW is
>> substituted only to
>> the host's IPs known to itself.
>> The host's IPFW firewall most likely doesn't know
>> anything about IPs
>> assigned to vnet interfaces inside the jail.
>>
>> Vnet jails behave more like separate physical hosts.
>>
>> Internet ---> [host] --- (10.0.10.0 LAN) -->
>> [vnet jail]
>>
>> The PF issue inside a jail is a separate problem, PF is
>> not fully
>> VIMAGE/VNET aware as far as I know.
>>
>> Can someone comment on these or correct me?
>>
>> P
>>
>>
>>
>> On Fri, Jul 11, 2014 at 7:11 PM, Peter Ross
>> > >
>> >>
>>
>> wrote:
>>
>> On Thu, 10 Jul 2014, Peter Toth wrote:
>>
>>  Hi Peter,
>>
>> Try to make these changes:
>>
>> net.inet.ip.forwarding=1   # Enable IP
>> forwarding
>> between interfaces
>> net.link.bridge.pfil_onlyip=0  # Only pass IP
>> packets
>> when pfil is enabled
>> net.link.bridge.pfil_bridge=0  # Packet filter
>> on the
>> bridge interface
>> net.link.bridge.pfil_member=0  # Packet filter
>> on the
>> member interface
>>
>> You can f

mergemaster and better support for ezjails

2014-07-12 Thread Warren Block

A couple of patches to make mergemaster work better with ezjails.

These are only very superficially tested.  Feedback welcome.

1. If /etc/mergemaster.rc exists in the jail, it is sourced.  This
   allows IGNORE_FILES to be set in the jail.  And other settings, but
   that's the one I wanted.

2. If /etc/localtime in the jail is a plain file, as when tzsetup has
   been run in the jail, tzsetup reinstalls the same file.  It will come
   from the host, but at first glance this does not seem to be a
   problem, seeing that jails should be updated after the host has been
   updated.  Because /usr/share/zoneinfo does not exist in the jail, I
   did not see a clean way to use tzsetup -C.  A link could be created
   to the basejail's /usr/share/zoneinfo, then deleted after
   tzsetup -C has run, or maybe there is a better way.--- /usr/src/usr.sbin/mergemaster/mergemaster.sh2014-06-03 
06:16:06.0 -0600
+++ /usr/sbin/mergemaster   2014-07-12 19:40:22.0 -0600
@@ -251,16 +251,29 @@
 #
 TEMPROOT='/var/tmp/temproot'
 
+# Options string for getopts
+OPT_STR=":ascrvhipCPm:t:du:w:A:D:FU"
+
+# if -D DESTDIR is set, process it first
+DESTDIR=""
+while getopts "${OPT_STR}" COMMAND_LINE_ARGUMENT ; do
+  case "${COMMAND_LINE_ARGUMENT}" in
+  D)
+DESTDIR=${OPTARG}
+;;
+  esac
+done
+
 # Read /etc/mergemaster.rc first so the one in $HOME can override
 #
 if [ -r /etc/mergemaster.rc ]; then
-  . /etc/mergemaster.rc
+  . "${DESTDIR}/etc/mergemaster.rc"
 fi
 
 # Read .mergemasterrc before command line so CLI can override
 #
 if [ -r "$HOME/.mergemasterrc" ]; then
-  . "$HOME/.mergemasterrc"
+  . "${DESTDIR}/$HOME/.mergemasterrc"
 fi
 
 for var in "$@" ; do
@@ -279,7 +292,8 @@
 
 # Check the command line options
 #
-while getopts ":ascrvhipCPm:t:du:w:D:A:FU" COMMAND_LINE_ARGUMENT ; do
+OPTIND=1
+while getopts "${OPT_STR}" COMMAND_LINE_ARGUMENT ; do
   case "${COMMAND_LINE_ARGUMENT}" in
   A)
 ARCHSTRING='TARGET_ARCH='${OPTARG}
@@ -344,7 +358,7 @@
 SCREEN_WIDTH=${OPTARG}
 ;;
   D)
-DESTDIR=${OPTARG}
+# has already been processed
 ;;
   *)
 display_usage
@@ -1335,10 +1349,20 @@
 
 if [ -e "${DESTDIR}/etc/localtime" -a ! -L "${DESTDIR}/etc/localtime" -a -z 
"${PRE_WORLD}" ]; then # Ignore if TZ == UTC
   echo ''
-  [ -n "${DESTDIR}" ] && tzs_args="-C ${DESTDIR}"
-  if [ -f "${DESTDIR}/var/db/zoneinfo" ]; then
-echo "*** Reinstalling `cat ${DESTDIR}/var/db/zoneinfo` as 
${DESTDIR}/etc/localtime"
-tzsetup $tzs_args -r
+  if [ -n "${DESTDIR}" ]; then
+SHARE="${DESTDIR}/usr/share"
+ZONE_INFO="${SHARE}/zoneinfo"
+if [ -L "${SHARE}" -a ! -e "${ZONE_INFO}" ]; then
+  # /usr/share is a link, /usr/share/zoneinfo does not exist, this is an 
ezjail
+  tzs_args="-r \"${DESTDIR}\""
+else
+  # this is a full jail
+  tzs_args="-r -C \"${DESTDIR}\""
+fi
+if [ -f "${DESTDIR}/var/db/zoneinfo" ]; then
+  echo "*** Reinstalling `cat ${DESTDIR}/var/db/zoneinfo` as 
${DESTDIR}/etc/localtime"
+  tzsetup $tzs_args
+fi
   else
 echo "*** There is no ${DESTDIR}/var/db/zoneinfo file to update 
${DESTDIR}/etc/localtime."
 echo 'You should run tzsetup'
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

Re: mergemaster and better support for ezjails

2014-07-12 Thread Mateusz Guzik
On Sat, Jul 12, 2014 at 08:08:52PM -0600, Warren Block wrote:
> A couple of patches to make mergemaster work better with ezjails.
> 
> These are only very superficially tested.  Feedback welcome.
> 
> 1. If /etc/mergemaster.rc exists in the jail, it is sourced.  This
>allows IGNORE_FILES to be set in the jail.  And other settings, but
>that's the one I wanted.
> 

How exactly does it work?

Is jailed root allowed to create /etc/mergemaster.rc?

If so, that would be a jail escape vector - an attacker puts commands they
want to execute inside and mergemaster sourcing the file will trigger
executing them.

In fact running mergemaster from "outside" on an untrusted jail seems
like a security weakness even without jailed-root controlled rc file
since they can try to do something fishy with symlinks which now resolve
to stuff on the host.

The following should be safe enough:
- have a dedicated RO jail
- mount to-be-updated jail under /mnt/jail or whatever
- mount sources/whatever RO under /usr/src or whatever
- run update process from inside dedicated RO jail

-- 
Mateusz Guzik 
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"


Re: mergemaster and better support for ezjails

2014-07-12 Thread Warren Block

On Sun, 13 Jul 2014, Mateusz Guzik wrote:


On Sat, Jul 12, 2014 at 08:08:52PM -0600, Warren Block wrote:

A couple of patches to make mergemaster work better with ezjails.

These are only very superficially tested.  Feedback welcome.

1. If /etc/mergemaster.rc exists in the jail, it is sourced.  This
   allows IGNORE_FILES to be set in the jail.  And other settings, but
   that's the one I wanted.



How exactly does it work?

Is jailed root allowed to create /etc/mergemaster.rc?


Yes.  Or at least I don't know of anything preventing that.


If so, that would be a jail escape vector - an attacker puts commands they
want to execute inside and mergemaster sourcing the file will trigger
executing them.


Ouch.  Seems obvious now that you mention it.  Probably mergemaster.rc 
should have a defined format rather than being sourced anyway.


Another way to implement ignored files would be to extend the 
definitions in (the host's) /etc/mergemaster.rc to include ignored files 
by jail name or full path.


Full paths do not work presently because IGNORE_FILES just deletes the 
temporary file so it is not compared.



In fact running mergemaster from "outside" on an untrusted jail seems
like a security weakness even without jailed-root controlled rc file
since they can try to do something fishy with symlinks which now resolve
to stuff on the host.

The following should be safe enough:
- have a dedicated RO jail
- mount to-be-updated jail under /mnt/jail or whatever
- mount sources/whatever RO under /usr/src or whatever
- run update process from inside dedicated RO jail


Thank you!
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"


Re: mergemaster and better support for ezjails

2014-07-12 Thread Ian Smith

On Sat, 12 Jul 2014 20:08:52 -0600, Warren Block wrote:
> A couple of patches to make mergemaster work better with ezjails.
> 
> These are only very superficially tested.  Feedback welcome.
> 
> 1. If /etc/mergemaster.rc exists in the jail, it is sourced.  This

>allows IGNORE_FILES to be set in the jail.  And other settings, but
>that's the one I wanted.

# Read /etc/mergemaster.rc first so the one in $HOME can override
#
if [ -r /etc/mergemaster.rc ]; then
-  . /etc/mergemaster.rc
+  . "${DESTDIR}/etc/mergemaster.rc"
fi

# Read .mergemasterrc before command line so CLI can override
#
if [ -r "$HOME/.mergemasterrc" ]; then
-  . "$HOME/.mergemasterrc"
+  . "${DESTDIR}/$HOME/.mergemasterrc"
fi

Maybe a dumb question, but ..

In both cases, don't we need to test the readability of those files with 
${DESTDIR} prepended, rather than the originals, before sourcing them?  
Or can we here safely assume that they will exist? Or doesn't it matter?


cheers, Ian--- /usr/src/usr.sbin/mergemaster/mergemaster.sh2014-06-03 
06:16:06.0 -0600
+++ /usr/sbin/mergemaster   2014-07-12 19:40:22.0 -0600
@@ -251,16 +251,29 @@
 #
 TEMPROOT='/var/tmp/temproot'
 
+# Options string for getopts
+OPT_STR=":ascrvhipCPm:t:du:w:A:D:FU"
+
+# if -D DESTDIR is set, process it first
+DESTDIR=""
+while getopts "${OPT_STR}" COMMAND_LINE_ARGUMENT ; do
+  case "${COMMAND_LINE_ARGUMENT}" in
+  D)
+DESTDIR=${OPTARG}
+;;
+  esac
+done
+
 # Read /etc/mergemaster.rc first so the one in $HOME can override
 #
 if [ -r /etc/mergemaster.rc ]; then
-  . /etc/mergemaster.rc
+  . "${DESTDIR}/etc/mergemaster.rc"
 fi
 
 # Read .mergemasterrc before command line so CLI can override
 #
 if [ -r "$HOME/.mergemasterrc" ]; then
-  . "$HOME/.mergemasterrc"
+  . "${DESTDIR}/$HOME/.mergemasterrc"
 fi
 
 for var in "$@" ; do
@@ -279,7 +292,8 @@
 
 # Check the command line options
 #
-while getopts ":ascrvhipCPm:t:du:w:D:A:FU" COMMAND_LINE_ARGUMENT ; do
+OPTIND=1
+while getopts "${OPT_STR}" COMMAND_LINE_ARGUMENT ; do
   case "${COMMAND_LINE_ARGUMENT}" in
   A)
 ARCHSTRING='TARGET_ARCH='${OPTARG}
@@ -344,7 +358,7 @@
 SCREEN_WIDTH=${OPTARG}
 ;;
   D)
-DESTDIR=${OPTARG}
+# has already been processed
 ;;
   *)
 display_usage
@@ -1335,10 +1349,20 @@
 
 if [ -e "${DESTDIR}/etc/localtime" -a ! -L "${DESTDIR}/etc/localtime" -a -z 
"${PRE_WORLD}" ]; then # Ignore if TZ == UTC
   echo ''
-  [ -n "${DESTDIR}" ] && tzs_args="-C ${DESTDIR}"
-  if [ -f "${DESTDIR}/var/db/zoneinfo" ]; then
-echo "*** Reinstalling `cat ${DESTDIR}/var/db/zoneinfo` as 
${DESTDIR}/etc/localtime"
-tzsetup $tzs_args -r
+  if [ -n "${DESTDIR}" ]; then
+SHARE="${DESTDIR}/usr/share"
+ZONE_INFO="${SHARE}/zoneinfo"
+if [ -L "${SHARE}" -a ! -e "${ZONE_INFO}" ]; then
+  # /usr/share is a link, /usr/share/zoneinfo does not exist, this is an 
ezjail
+  tzs_args="-r \"${DESTDIR}\""
+else
+  # this is a full jail
+  tzs_args="-r -C \"${DESTDIR}\""
+fi
+if [ -f "${DESTDIR}/var/db/zoneinfo" ]; then
+  echo "*** Reinstalling `cat ${DESTDIR}/var/db/zoneinfo` as 
${DESTDIR}/etc/localtime"
+  tzsetup $tzs_args
+fi
   else
 echo "*** There is no ${DESTDIR}/var/db/zoneinfo file to update 
${DESTDIR}/etc/localtime."
 echo 'You should run tzsetup'
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"

Re: securelevel in VNET jails using ipfw(8)

2014-07-12 Thread Ian Smith
On Sun, 13 Jul 2014 07:42:42 +1200, Peter Toth wrote:
 > Hi Ian,
 > 
 > This is for the jail's securelevel option. If you set it to the highest
 > number 3 it will fail to load IPFW rules in a jail during startup.
 > 
 > Snip from "man securelevel":
 > Network secure mode - same as highly secure mode, plus IP packet
 > filter rules (see ipfw(8), ipfirewall(4) and pfctl(8)) cannot be
 > changed and dummynet(4) or pf(4) configuration cannot be adjusted.
 >
 > Cheers,
 > Peter

I understood why 3 wouldn't work.  What I hadn't realised was that you 
were defaulting iocage jails to securelevel 3, which just shows that I 
hadn't read the manual :)

ezjail has tests for securelevel > 0 re installing or updating, but I 
assumed that to refer to the host's securelevel.

Thanks, Ian

 > On Sun, Jul 13, 2014 at 4:08 AM, Ian Smith  wrote:
 > 
 > > Hi Peter,
 > >
 > > from your FAQ at http://iocage.readthedocs.org/en/latest/faq.html
 > >
 > > "If you plan on using IPFW inside a jail make sure securelevel is set to 2"
 > >
 > > Unless this is also a FAQ you can point me to, can you explain why this
 > > is needed?  Reading security(7) leaves me unclear on how securelevels
 > > apply in a jail, or what it may be about ipfw(8) particularly that could
 > > compromise jail (or host?) security, that other services could not?
 > >
 > > cheers, Ian
___
freebsd-jail@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-jail
To unsubscribe, send any mail to "freebsd-jail-unsubscr...@freebsd.org"