rcctl: un-hardcode /etc/rc.conf{.local}

2014-10-11 Thread Craig R. Skinner

Some notes to demo the diff below:


# -=-=-=-=-=-=-= Assignment:

me$ _STATIC_RCCONF='/etc/rc.conf'
me$ _RCCONF=${_STATIC_RCCONF}.local


# -=-=-=-=-=-=-= Test 1:

me$ print ${_STATIC_RCCONF} ${_RCCONF}
/etc/rc.conf /etc/rc.conf.local

me$ print ${_RCCONF%/*} ${_RCCONF##*/}
/etc rc.conf.local


# -=-=-=-=-=-=-= Test 2:

me$ _TMP_RCCONF=$(mktemp -p ${_RCCONF%/*} -t ${_RCCONF##*/}.XX) || 
print $?
mktemp: cannot make temp file /etc/rc.conf.local.luzxGjy18I: Permission denied
1


# -=-=-=-=-=-=-= Reassignment:

me$ _STATIC_RCCONF='/tmp/rc.conf'
me$ _RCCONF=${_STATIC_RCCONF}.local


# -=-=-=-=-=-=-= Test 3:

me$ _TMP_RCCONF=$(mktemp -p ${_RCCONF%/*} -t ${_RCCONF##*/}.XX) || 
print $?
me$ ls ${_TMP_RCCONF}
/tmp/rc.conf.local.ZLyVBCNMtk





Index: rcctl.sh
===
RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
retrieving revision 1.41
diff -u -p -r1.41 rcctl.sh
--- rcctl.sh10 Oct 2014 15:59:36 -  1.41
+++ rcctl.sh11 Oct 2014 12:41:22 -
@@ -18,7 +18,9 @@
 # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
 
 _special_services=accounting check_quotas ipsec multicast_host 
multicast_router pf spamd_black
-readonly _special_services
+_STATIC_RCCONF='/etc/rc.conf'
+_RCCONF=${_STATIC_RCCONF}.local
+readonly _special_services _STATIC_RCCONF _RCCONF
 
 # get local functions from rc.subr(8)
 FUNCS_ONLY=1
@@ -38,21 +40,21 @@ needs_root()
 
 rcconf_edit_begin()
 {
-   _TMP_RCCONF=$(mktemp -p /etc -t rc.conf.local.XX) || exit 1
-   if [ -f /etc/rc.conf.local ]; then
+   _TMP_RCCONF=$(mktemp -p ${_RCCONF%/*} -t ${_RCCONF##*/}.XX) || 
exit
+   if [ -f ${_RCCONF} ]; then
# only to keep permissions (file content is not needed)
-   cp -p /etc/rc.conf.local ${_TMP_RCCONF} || exit 1
+   cp -p ${_RCCONF} ${_TMP_RCCONF} || exit 1
else
-   touch /etc/rc.conf.local || exit 1
+   touch ${_RCCONF} || exit 1
fi
 }
 
 rcconf_edit_end()
 {
sort -u -o ${_TMP_RCCONF} ${_TMP_RCCONF} || exit 1
-   mv ${_TMP_RCCONF} /etc/rc.conf.local || exit 1
-   if [ ! -s /etc/rc.conf.local ]; then
-   rm /etc/rc.conf.local || exit 1
+   mv ${_TMP_RCCONF} ${_RCCONF} || exit 1
+   if [ ! -s ${_RCCONF} ]; then
+   rm ${_RCCONF} || exit 1
fi
 }
 
@@ -62,7 +64,7 @@ svc_default_enabled()
[ -n ${_svc} ] || return
local _ret=1
 
-   _rc_parse_conf /etc/rc.conf
+   _rc_parse_conf ${_STATIC_RCCONF}
svc_is_enabled ${_svc}  _ret=0
_rc_parse_conf
 
@@ -166,7 +168,7 @@ append_to_pkg_scripts()
if [ -z ${pkg_scripts} ]; then
echo pkg_scripts=${_svc} ${_TMP_RCCONF}
elif ! echo ${pkg_scripts} | grep -qw ${_svc}; then
-   grep -v ^pkg_scripts.*= /etc/rc.conf.local ${_TMP_RCCONF}
+   grep -v ^pkg_scripts.*= ${_RCCONF} ${_TMP_RCCONF}
echo pkg_scripts=${pkg_scripts} ${_svc} ${_TMP_RCCONF}
fi
rcconf_edit_end
@@ -182,7 +184,7 @@ rm_from_pkg_scripts()
rcconf_edit_begin
sed /^pkg_scripts[[::]]/{s/[[::]]${_svc}[[::]]//g
s/['\]//g;s/ *= */=/;s/   */ /g;s/ $//;/=$/d;} \
-   /etc/rc.conf.local ${_TMP_RCCONF}
+   ${_RCCONF} ${_TMP_RCCONF}
rcconf_edit_end
 }
 
@@ -193,7 +195,7 @@ add_flags()
 
if svc_is_special ${_svc}; then
rcconf_edit_begin
-   grep -v ^${_svc}.*= /etc/rc.conf.local ${_TMP_RCCONF}
+   grep -v ^${_svc}.*= ${_RCCONF} ${_TMP_RCCONF}
if ! svc_default_enabled ${_svc}; then
echo ${_svc}=YES ${_TMP_RCCONF}
fi
@@ -219,7 +221,7 @@ add_flags()
fi
 
rcconf_edit_begin
-   grep -v ^${_svc}_flags.*= /etc/rc.conf.local ${_TMP_RCCONF}
+   grep -v ^${_svc}_flags.*= ${_RCCONF} ${_TMP_RCCONF}
if [ -n ${_flags} ] || \
   ( svc_is_base ${_svc}  ! svc_default_enabled ${_svc} ); then
echo ${_svc}_flags=${_flags} ${_TMP_RCCONF}
@@ -234,12 +236,12 @@ rm_flags()
 
rcconf_edit_begin
if svc_is_special ${_svc}; then
-   grep -v ^${_svc}.*= /etc/rc.conf.local ${_TMP_RCCONF}
+   grep -v ^${_svc}.*= ${_RCCONF} ${_TMP_RCCONF}
if svc_default_enabled ${_svc}; then
echo ${_svc}=NO ${_TMP_RCCONF}
fi
else
-   grep -v ^${_svc}_flags.*= /etc/rc.conf.local ${_TMP_RCCONF}
+   grep -v ^${_svc}_flags.*= ${_RCCONF} ${_TMP_RCCONF}
if svc_default_enabled ${_svc}; then
echo ${_svc}_flags=NO ${_TMP_RCCONF}
fi



Re: rcctl: un-hardcode /etc/rc.conf{.local}

2014-10-11 Thread Ingo Schwarze
Hi Craig,

i consider system code easier to understand, more predictable,
and hence easier to keep correct and secure when system files
and directories are not configurable.

Consequently, i don't like the direction you are taking here.

Yours,
  Ingo


Craig R. Skinner wrote on Sat, Oct 11, 2014 at 01:57:32PM +0100:

[...]
 Index: rcctl.sh
 ===
 RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
 retrieving revision 1.41
 diff -u -p -r1.41 rcctl.sh
 --- rcctl.sh  10 Oct 2014 15:59:36 -  1.41
 +++ rcctl.sh  11 Oct 2014 12:41:22 -
[...]
 @@ -62,7 +64,7 @@ svc_default_enabled()
   [ -n ${_svc} ] || return
   local _ret=1
  
 - _rc_parse_conf /etc/rc.conf
 + _rc_parse_conf ${_STATIC_RCCONF}
   svc_is_enabled ${_svc}  _ret=0
   _rc_parse_conf
  
[...]



Re: rcctl: un-hardcode /etc/rc.conf{.local}

2014-10-11 Thread Theo de Raadt
 i consider system code easier to understand, more predictable,
 and hence easier to keep correct and secure when system files
 and directories are not configurable.
 
 Consequently, i don't like the direction you are taking here.

Hell yes.   It is dangerously confusing abstraction.

Only purpose it serves is to make simple stuff look magic.

 [...]
  Index: rcctl.sh
  ===
  RCS file: /cvs/src/usr.sbin/rcctl/rcctl.sh,v
  retrieving revision 1.41
  diff -u -p -r1.41 rcctl.sh
  --- rcctl.sh10 Oct 2014 15:59:36 -  1.41
  +++ rcctl.sh11 Oct 2014 12:41:22 -
 [...]
  @@ -62,7 +64,7 @@ svc_default_enabled()
  [ -n ${_svc} ] || return
  local _ret=1
   
  -   _rc_parse_conf /etc/rc.conf
  +   _rc_parse_conf ${_STATIC_RCCONF}
  svc_is_enabled ${_svc}  _ret=0
  _rc_parse_conf
   
 [...]
 



[SOLVED]: no respone on Passphrase after first boot on -current

2014-10-11 Thread Jiri Navratil
Thu, Oct 09, 2014 at 11:54:12AM CEST, s...@stsp.name napsal(a):
 On Thu, Oct 09, 2014 at 06:23:17AM +0200, Jiri Navratil wrote:
  Hello,
  
  I bought acer TravelMate notebook TMB115-M-COEA to follow -current and
  partitipate on LibreSSL.
  
  I installed system from snapshot and used softraid0 crypto on whole sd0.
  
  After first boot I have Passsphrase prompt and I can't contine. It looks
  like keyboard is not working. No response after Enter. I assume, that
  I'm providing same password as during install. There is no response at
  all.
  
  Can I debug this somehow?
  
  I may install the machine again without crypto and then try to use 
  softraid0 crypto on external drive, but not sure, if this can be helpfull 
  for debuging and reporting.
  
  Is there something next I can experiment with and provide something valuable
  here?
  
  Thank you,
  Jiri
  
  -- 
  Jiri Navratil, http://kouc.navratil.cz, +420 222 767 131
 
 Did you try booting into the install media, select 'shell', and then
 attaching your softraid crypto disk with bioctl? Does that work?
 
 Can you provide a dmesg?

Thank you Bio and Stefan for responses.

I can boot now from installed system. Not sure, which step helped. The
BIOS looks not fully ok for me.

I did these steps

Based on https://www.mail-archive.com/misc@openbsd.org/msg132652.html I
looked in to BIOS and did the only thing possible with USB. I switched Boot
Mode from Legacy to UEFI, which lead into error - no boot device. Then I
switched back to legacy and booted USB stick with miniroot56.fs and
attached softraid crypto disk just fine. Then I halted system. New boot
directly from harddrive worked fine. (I wass able to answer Passphrase
question and system booted fine).

So thank you for your help. It's working now.

I'm attaching first boot dmesg and dmesg from compiled kernel. They are
already on dm...@openbsd.org. May be this can have value for someone.

I noticed in dmesg this error:
RTC BIOS diagnostic error 80clock_battery
Can clock battery be dead on new machine? Or the BIOS is not good schape?

WiFi is not working. I see Intel Dual Band Wireless AC 7260 in dmesg.

Screen stay blank after resume from suspend (both console and X blank,
machine accessible via network).

Best regards,
Jiri




Re: Shadow TCP stacks

2014-10-11 Thread Ian Grant
On Sat, Oct 11, 2014 at 5:45 AM, Joachim Schipper
joac...@joachimschipper.nl wrote:
 moved to misc@; it's still not on-topic, but this message may be
 somewhat interesting

Moved back to tech for just this message:

I am going to implement this inBSD, so I would still appreciate
pointers and helpful tech advice, but please don't CC the list, just
mail me privately.

To prevent a flame war, please don't refute anything on the list
without giving carefully considered, clear reasons why I and everyone
else should agree with you, otherwise I will be obliged to respond to
the list because I won't leave a falsehood uncontested on a public
forum.

 The application is electronic democracy. I want to demonstrate how it
 is possible to do secure comms. over untrusted networks and hardware.

 But it *isn't* possible to do secure comms from/to compromised hardware;
 that is what compromised means.

That's why I used the term untrusted: to make a distinction between
the unknown status of security of the underlying media and
compromised meaning definite knowledge that the hardware affects a
compromise of privacy/integrity.

 Note that the thesis above merely aims at cryptographic port knocking; a
 global adversary can still just read the unencrypted traffic

No, the pre-shared keys are communicated over the VPN, as are the
keys which encrypt the VPN's own data as it appears in the actual TCP
packets which carry the tunnel through which the VPN operates.

This is not a common idea: that such a thing a thing is possible, so
people should not be too quick to dismiss it solely on account of
never having heard of the idea before. Dismiss it only when you have
convinced yourself that it definitely won't work. Because otherwise
you are rejecting something very valuable: perfectly secure
communications.

 Also, note that securely pre-sharing keys is a pain even in a small
 group of friends;

The purpose of the VPN is to provide this mechanism and make it
automatic, that point should be fairly clear in my description.

 there is no way you can scale that to every human in
 the world.

No, and that is certainly not the plan. The verification of the voting
is as I explain in that document: it is that each voter certifies the
votes of three others, and because people know this, they know that
their own vote is only represented if the others certified theirs. So
the knowledge doesn't exist in any one person's mind, it only exists
in the combined minds of all the people. And the same principle
applies to the knowledge of the VPN keys: that knowledge will be
shared between four independent orthogonal VPNs and that information
will simply not exist, so could never be compromised.

Please don't be too quick to dismiss this. The idea is not an obvious
one, but people who can think about systems are typically better at
grasping this sort of thing that people who who work with systems of
formal proof which work by symbolic substitution.  This is not
something you can make obvious by symbolic substitution because it is
based on human knowledge, not concrete representation in some
language: that knowledge is the knowledge that these really are three
other independent VPNs that are providing the information I need to
encrypt my traffic when it sending to this other machine..

 I hope to be able do this by carrying out a global referendum. See

  http://livelogic.blogspot.com/2014/10/the-foundation-parts-iii-iii.html

 A very quick read shows that you want to do, roughly, electronic voting.
 A number of proposals exists to achieve secure (or verifiable)
 electronic voting; I believe you should be able to find fairly
 accessible introductions to the cryptographic scheme proposed by Ron
 Rivest (of RSA fame).

 No proposal that I'm aware of even contemplates using compromised
 hardware, though, and all proposals assume a functioning census.

Well, now you _are_ aware of at least one: which is this one :-)

And I am not the only one who believes that this is possible. Roger
Schell (cc'ed), who was very influential in the development of the
NSA's TCSEC wrote in
https://www.acsac.org/invited-essay/essays/2001-schell.pdf:

The science of computer and network information security has for some
time given us the ability to purchase an information system from a
mortal enemy and then assess its ability to enforce a well defined
security policy,
gaining sufficient assurance to confidently use the system to protect
against massive loss and grave damage, and this has been actually been
put into practice. This astonishing capability is known as “verified
protection”.

 My plan is to use a virtual interface which magically shows behind the
 physical interface when connections are made with the right ISN key in
 the SYN packet. If the ISN is not one of the 'knocks' then the
 connection sees the ordinary physical interface.

 Then I want to make a connection between applications and the TCP
 stack so that the knocks can be determined only by data from