Re: Building OpenBSD 6.0 -stable - Error

2016-09-03 Thread STeve Andre'

On 09/03/16 11:32, Harald Dunkel wrote:

On 09/03/16 12:40, Ted Unangst wrote:

Teno Deuter wrote:

installed a fresh 6.0 AMD64 and tried to build 'stable' from source.

Here is what I did as 'root' (as described in:
http://www.openbsd.org/stable.html):

export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs
cd /usr; cvs checkout -P -rOPENBSD_6_0 src

there's some repo surgery in progress. it should be fixed eventually.


What exactly does this mean?



It means that something went wrong, and steps were being taken

to fix it.  Not very often, cvs has problems and getting good copies

of stuff doesn't work.  This is always noticed and repaired fairly quickly.


Also, if a repository is down, people have noticed it and are working

on it, so messages to @misc such as "I can't update from xxx" are

somewhat useless.


The ecosystem for distributing software is not perfect.  When you find

a problem, wait, and try again.  Repeat if needed.


--STeve Andre'



Re: rdomain incompatible with NSD ? (OpenBSD 6)

2016-09-03 Thread Sebastian Benoit
Bob Jones(r.a.n.d.o.m.d.e.v.4+openbsdm...@gmail.com) on 2016.09.03 19:11:41 
+0100:
> Hi,
> 
> Not sure if its a feature or a bug.  ;-)
> 
> OpenBSD my.example.com 6.0 GENERIC.MP#2319 amd64
> 
> Relevant bit of /var/nsd/etc/nsd.conf:
> ip-address: 10.1.2.3
> 
> 
> $ cat /etc/hostname.vmx1
> rdomain 1
> inet 10.1.2.3 255.255.255.224
> !route -T1 add default 10.1.2.65
> 
> The above yields :
> Sep  3 18:35:40 my nsd[35324]: nsd starting (NSD 4.1.10)
> Sep  3 18:35:40 my nsd[35324]: can't bind udp socket: Can't assign
> requested address
> Sep  3 18:35:40 my nsd[35324]: server initialization failed, nsd could
> not be started
> 
> Commenting out or removing the rdomain and route lines yields:
> Sep  3 18:40:05 my nsd[40514]: nsd starting (NSD 4.1.10)
> Sep  3 18:40:05 my nsd[36692]: nsd started (NSD 4.1.10), pid 17346

Relevant bit of a solution:

set

  nsd_rtable=1

in /etc/rc.conf.local



Re: not exactly (Re: systrace removed? Why?)

2016-09-03 Thread Michal Bozon
if someone's interested, here a list of fs differences
between 6.0 upgraded from 5.9, and 6.0 install, i found,
with some obvious differences like smtpd spool or sysmerge
backups removed (amd64/qemu):

http://pastebin.com/raw/VPkdbvxy (text/plain)

(not pasting because of long lines)

hth



Re: Removal of old libraries

2016-09-03 Thread Ax0n
Thank you very much, all! Giving it a shot now.

On Sat, Sep 3, 2016, 16:35 Juan Francisco Cantero Hurtado 
wrote:

> On Sat, Sep 03, 2016 at 03:12:53PM -0500, Ax0n wrote:
> > I've got a Toshiba NB305 netbook that's been my daily-use laptop for more
> > than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in
> > early May 2011. I've been quite happy with how it works, and I've been
> > doing bsd.rd upgrades and M:Tier binary updates ever since.
> >
> > There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with
> an
> > atime of my last level 0 dump several months ago.   Looks like pkg_add -u
> > left a bunch of stuff behind. Is there a recommended way to clean this
> > stuff up, or should I just start chopping away with something like:
> >
> > find /usr/local/lib -type f -atime +90 | doas xargs rm
> >
> > (after a new level 0 dump, obviously...)
> >
>
> pkg_add sysclean
>
> man sysclean
>
> --
> Juan Francisco Cantero Hurtado http://juanfra.info



Re: Removal of old libraries

2016-09-03 Thread Juan Francisco Cantero Hurtado
On Sat, Sep 03, 2016 at 03:12:53PM -0500, Ax0n wrote:
> I've got a Toshiba NB305 netbook that's been my daily-use laptop for more
> than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in
> early May 2011. I've been quite happy with how it works, and I've been
> doing bsd.rd upgrades and M:Tier binary updates ever since.
> 
> There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an
> atime of my last level 0 dump several months ago.   Looks like pkg_add -u
> left a bunch of stuff behind. Is there a recommended way to clean this
> stuff up, or should I just start chopping away with something like:
> 
> find /usr/local/lib -type f -atime +90 | doas xargs rm
> 
> (after a new level 0 dump, obviously...)
> 

pkg_add sysclean

man sysclean

-- 
Juan Francisco Cantero Hurtado http://juanfra.info



Re: Removal of old libraries

2016-09-03 Thread Ulises M. Alvarez
pkg_delete -a El 3 sept. 2016 3:12 PM, Ax0n  escribió:
>
> I've got a Toshiba NB305 netbook that's been my daily-use laptop for more 
> than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in 
> early May 2011. I've been quite happy with how it works, and I've been 
> doing bsd.rd upgrades and M:Tier binary updates ever since. 
>
> There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an 
> atime of my last level 0 dump several months ago.   Looks like pkg_add -u 
> left a bunch of stuff behind. Is there a recommended way to clean this 
> stuff up, or should I just start chopping away with something like: 
>
> find /usr/local/lib -type f -atime +90 | doas xargs rm 
>
> (after a new level 0 dump, obviously...) 



Removal of old libraries

2016-09-03 Thread Ax0n
I've got a Toshiba NB305 netbook that's been my daily-use laptop for more
than 6 years now. The last fresh install I did was OpenBSD 4.9-RELEASE in
early May 2011. I've been quite happy with how it works, and I've been
doing bsd.rd upgrades and M:Tier binary updates ever since.

There is a lot of seemingly unused cruft in /usr/local/lib -- stuff with an
atime of my last level 0 dump several months ago.   Looks like pkg_add -u
left a bunch of stuff behind. Is there a recommended way to clean this
stuff up, or should I just start chopping away with something like:

find /usr/local/lib -type f -atime +90 | doas xargs rm

(after a new level 0 dump, obviously...)



Re: rdomain incompatible with NSD ? (OpenBSD 6)

2016-09-03 Thread Uwe Werler
You have to start nsd in rdomain 1.


Von meinem Samsung Galaxy Smartphone gesendet.

 Ursprüngliche Nachricht 
Von: Bob Jones  
Datum: 03.09.16  20:13  (GMT+01:00) An: misc@openbsd.org 
Betreff: rdomain incompatible with NSD ? (OpenBSD 6) 




rdomain incompatible with NSD ? (OpenBSD 6)

2016-09-03 Thread Bob Jones
Hi,

Not sure if its a feature or a bug.  ;-)

OpenBSD my.example.com 6.0 GENERIC.MP#2319 amd64

Relevant bit of /var/nsd/etc/nsd.conf:
ip-address: 10.1.2.3


$ cat /etc/hostname.vmx1
rdomain 1
inet 10.1.2.3 255.255.255.224
!route -T1 add default 10.1.2.65

The above yields :
Sep  3 18:35:40 my nsd[35324]: nsd starting (NSD 4.1.10)
Sep  3 18:35:40 my nsd[35324]: can't bind udp socket: Can't assign
requested address
Sep  3 18:35:40 my nsd[35324]: server initialization failed, nsd could
not be started

Commenting out or removing the rdomain and route lines yields:
Sep  3 18:40:05 my nsd[40514]: nsd starting (NSD 4.1.10)
Sep  3 18:40:05 my nsd[36692]: nsd started (NSD 4.1.10), pid 17346



Re: not exactly (Re: systrace removed? Why?)

2016-09-03 Thread Edgar Pettijohn
Sent from my iPhone

On Sep 3, 2016, at 12:46 PM, Michal Bozon  wrote:

>> good(?) news: sysmerge is gone in 6.0
>> but not removed by 5.9 to 6.0 uprade process.
> 
> s/sysmerge/systrace/
> 

pledge()



Re: not exactly (Re: systrace removed? Why?)

2016-09-03 Thread Michal Bozon
> > good(?) news: sysmerge is gone in 6.0
> > but not removed by 5.9 to 6.0 uprade process.
> > 
> 
> I really have a hard time understanding what you're trying to point out.
> 
> Yes, systrace is gone, but it's an ordinary binary that does no harm,
> feel free to remove it if it makes you feel better.
> 
> sysmerge isn't gone, but it is executed automatically if you use a
> bsd.rd upgrade, hence it's only mentioned in the manual upgrade process.

ok, never mind,
i have just spotted it when comparing fs trees of
freshly installed 6.0 and
freshly installed/upgraded 5.9/6.0

.. and made sure to report it immediately,
since the removal of systrace is advertised
as a security enhancement :)



Re: not exactly (Re: systrace removed? Why?)

2016-09-03 Thread Michal Bozon
> good(?) news: sysmerge is gone in 6.0
> but not removed by 5.9 to 6.0 uprade process.

s/sysmerge/systrace/



Re: not exactly (Re: systrace removed? Why?)

2016-09-03 Thread Theo Buehler
On Sat, Sep 03, 2016 at 05:37:22PM +, Michal Bozon wrote:
> > Why?
> 
> good(?) news: sysmerge is gone in 6.0
> but not removed by 5.9 to 6.0 uprade process.
> 

I really have a hard time understanding what you're trying to point out.

Yes, systrace is gone, but it's an ordinary binary that does no harm,
feel free to remove it if it makes you feel better.

sysmerge isn't gone, but it is executed automatically if you use a
bsd.rd upgrade, hence it's only mentioned in the manual upgrade process.



not exactly (Re: systrace removed? Why?)

2016-09-03 Thread Michal Bozon
> Why?

good(?) news: sysmerge is gone in 6.0
but not removed by 5.9 to 6.0 uprade process.



Re: Building OpenBSD 6.0 -stable - Error

2016-09-03 Thread Peter Hessler
Yes, the repos should be done with their surgery now.  Please let us
know if you still see issues.

On 2016 Sep 03 (Sat) at 13:11:42 +0200 (+0200), Teno Deuter wrote:
:meaning I shall try at a later time?
:
:Thank you
:
:On Sat, Sep 3, 2016 at 12:40 PM, Ted Unangst  wrote:
:> Teno Deuter wrote:
:>> installed a fresh 6.0 AMD64 and tried to build 'stable' from source.
:>>
:>> Here is what I did as 'root' (as described in:
:>> http://www.openbsd.org/stable.html):
:>>
:>> export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs
:>> cd /usr; cvs checkout -P -rOPENBSD_6_0 src
:>
:> there's some repo surgery in progress. it should be fixed eventually.
:

-- 
Hofstadter's Law:
It always takes longer than you expect, even when you take
Hofstadter's Law into account.



Re: Building OpenBSD 6.0 -stable - Error

2016-09-03 Thread Harald Dunkel
On 09/03/16 12:40, Ted Unangst wrote:
> Teno Deuter wrote:
>> installed a fresh 6.0 AMD64 and tried to build 'stable' from source.
>>
>> Here is what I did as 'root' (as described in:
>> http://www.openbsd.org/stable.html):
>>
>> export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs
>> cd /usr; cvs checkout -P -rOPENBSD_6_0 src
> 
> there's some repo surgery in progress. it should be fixed eventually.
> 
What exactly does this mean?



Re: Building OpenBSD 6.0 -stable - Error

2016-09-03 Thread R0me0 ***
Hello Teno,

I have successfully updated five OpenBSD 5.9 to 6.0 on release day ,
following https://www.openbsd.org/faq/upgrade60.html

After, I rebuilt all them to stable branch from:

$ cd /usr
$ cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs get -rOPENBSD_6_0 -P src


Was magical as expected.

Regards,








2016-09-03 8:11 GMT-03:00 Teno Deuter :

> meaning I shall try at a later time?
>
> Thank you
>
> On Sat, Sep 3, 2016 at 12:40 PM, Ted Unangst  wrote:
> > Teno Deuter wrote:
> >> installed a fresh 6.0 AMD64 and tried to build 'stable' from source.
> >>
> >> Here is what I did as 'root' (as described in:
> >> http://www.openbsd.org/stable.html):
> >>
> >> export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs
> >> cd /usr; cvs checkout -P -rOPENBSD_6_0 src
> >
> > there's some repo surgery in progress. it should be fixed eventually.



Re: might it be better to have three paths lists

2016-09-03 Thread ludovic coues
Split your program. Stricter privilege separation.
Replace thread with fork, you will have self contained program unit.
An overflow in one won't affect the other. And each piece will have
tighter pledge.



2016-09-03 12:37 GMT+02:00 Luke Small :
> If a program requires studio, wpath, rpath, dns, and inet. It spawns
> multiple threads. The socket binding thread is taken over, runs arbitrary
> code that overflows a buffer of the thread listening to a pipe with rpath
> and stdio permissions it reads the binary of an executable the company wants
> to remain private, but is on the paths list, which gives the process
> unintentional read permissions and sends it to the attacker.
> Because we know everybody writes perfect code. With finer grained paths
> permissions, it is possible to gain even better control amidst really well
> pledged and privilege separated programs(even if they are imperfectly
> bounded), it may be possible to have a slightly more complicated paths setup
> with less privilege separation, written by programmers that spend a bit less
> time with privilege separation, to meet deadlines and achieve comparable
> results.
>
>
> On Sat, Sep 3, 2016, 04:41 ludovic coues  wrote:
>>
>> 2016-09-03 11:04 GMT+02:00 Luke Small :
>> >
>> >
>> > Sorry  I was in the middle of something, but pledge can be a broad
>> > brush,
>> > unless you are dealing with one file, whether it is executed, read, or
>> > written and giving per process file permissions sounds pretty neat, and
>> > it
>> > might just be a little simpler than making new users for each subset of
>> > privileges, populating each chrooted home folder with a specific set of
>> > permissions (as is what appears to me to have happened with pkg_add).
>> > Since
>> > pledge's promises can make it where you can execute a file without read
>> > permission, it seems ideal to continue that tradition with the paths
>> >
>> >   On Sat, Sep 3, 2016, 03:07 Luke Small  wrote:
>> >>
>> >> In pledge, presumably there will be an accessible paths list. Maybe you
>> >> grant a process root access, and you need to read a file which is only
>> >> granted by root access, and you need write access for another file, so
>> >> the
>> >> pledge permissions reflect that. On the presumed current path, you
>> >> would
>> >> leave write access for the first file and maybe you don't need the
>> >> process
>> >> to have read permissions on an execl() program. You can prohibit your
>> >> process from reading your software or binary, even if it may have
>> >> permissions to do so.
>> >>
>>
>> That's not a specific use case.
>> Either you should provide a patch or an exemple of a real program that
>> is limited by the current design of pledge.
>>
>> Currently, if you want a program that can only read a file, you pledge
>> rpath. If you want the ability to exec file, you pledge exec.
>>
>> If you want a program that can exec a set of file and write in
>> another, either you run your program as a user and group that can't
>> write the set of file you want to exec (W^X) or you write two program,
>> one pledging for write the other for read.
>>
>> There following paper have an exemple of how the second design can be
>> done.
>> http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html
>>
>>
>> --
>>
>> Cordialement, Coues Ludovic
>> +336 148 743 42



-- 

Cordialement, Coues Ludovic
+336 148 743 42



Re: might it be better to have three paths lists

2016-09-03 Thread Theo de Raadt
Wow, Luke you are the man.

> Probably right, if they were pushing strong release dates, they'd go with
> freebsd or linux
> 
> On Sat, Sep 3, 2016, 05:44 Theo de Raadt  wrote:
> 
> > Not a strong requirement.
> >
> > > If a program requires studio, wpath, rpath, dns, and inet. It spawns
> > > multiple threads. The socket binding thread is taken over, runs arbitrary
> > > code that overflows a buffer of the thread listening to a pipe with rpath
> > > and stdio permissions it reads the binary of an executable the company
> > > wants to remain private, but is on the paths list, which gives the
> > process
> > > unintentional read permissions and sends it to the attacker.
> > > Because we know everybody writes perfect code. With finer grained paths
> > > permissions, it is possible to gain even better control amidst really
> > well
> > > pledged and privilege separated programs(even if they are imperfectly
> > > bounded), it may be possible to have a slightly more complicated paths
> > > setup with less privilege separation, written by programmers that spend a
> > > bit less time with privilege separation, to meet deadlines and achieve
> > > comparable results.
> > >
> > > On Sat, Sep 3, 2016, 04:41 ludovic coues  wrote:
> > >
> > > > 2016-09-03 11:04 GMT+02:00 Luke Small :
> > > > >
> > > > >
> > > > > Sorry  I was in the middle of something, but pledge can be a broad
> > brush,
> > > > > unless you are dealing with one file, whether it is executed, read,
> > or
> > > > > written and giving per process file permissions sounds pretty neat,
> > and
> > > > it
> > > > > might just be a little simpler than making new users for each subset
> > of
> > > > > privileges, populating each chrooted home folder with a specific set
> > of
> > > > > permissions (as is what appears to me to have happened with pkg_add).
> > > > Since
> > > > > pledge's promises can make it where you can execute a file without
> > read
> > > > > permission, it seems ideal to continue that tradition with the paths
> > > > >
> > > > >   On Sat, Sep 3, 2016, 03:07 Luke Small 
> > wrote:
> > > > >>
> > > > >> In pledge, presumably there will be an accessible paths list. Maybe
> > you
> > > > >> grant a process root access, and you need to read a file which is
> > only
> > > > >> granted by root access, and you need write access for another file,
> > so
> > > > the
> > > > >> pledge permissions reflect that. On the presumed current path, you
> > would
> > > > >> leave write access for the first file and maybe you don't need the
> > > > process
> > > > >> to have read permissions on an execl() program. You can prohibit
> > your
> > > > >> process from reading your software or binary, even if it may have
> > > > >> permissions to do so.
> > > > >>
> > > >
> > > > That's not a specific use case.
> > > > Either you should provide a patch or an exemple of a real program that
> > > > is limited by the current design of pledge.
> > > >
> > > > Currently, if you want a program that can only read a file, you pledge
> > > > rpath. If you want the ability to exec file, you pledge exec.
> > > >
> > > > If you want a program that can exec a set of file and write in
> > > > another, either you run your program as a user and group that can't
> > > > write the set of file you want to exec (W^X) or you write two program,
> > > > one pledging for write the other for read.
> > > >
> > > > There following paper have an exemple of how the second design can be
> > done.
> > > > http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html
> > > >
> > > >
> > > > --
> > > >
> > > > Cordialement, Coues Ludovic
> > > > +336 148 743 42
> > >
> >
> >
> 
> --94eb2c07d10429a200053b98ce09
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> Probably right, if they were pushing strong release dates, t=
> heyd go with freebsd or linux
> On Sat, Sep 3, 2016, 05:44 =
> Theo de Raadt mailto:dera...@openbsd.org;>dera...@openbsd.or=
> g wrote: :0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not a strong requi=
> rement.
> 
>  If a program requires studio, wpath, rpath, dns, and inet. It 

Re: Building OpenBSD 6.0 -stable - Error

2016-09-03 Thread Teno Deuter
meaning I shall try at a later time?

Thank you

On Sat, Sep 3, 2016 at 12:40 PM, Ted Unangst  wrote:
> Teno Deuter wrote:
>> installed a fresh 6.0 AMD64 and tried to build 'stable' from source.
>>
>> Here is what I did as 'root' (as described in:
>> http://www.openbsd.org/stable.html):
>>
>> export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs
>> cd /usr; cvs checkout -P -rOPENBSD_6_0 src
>
> there's some repo surgery in progress. it should be fixed eventually.



Re: might it be better to have three paths lists

2016-09-03 Thread Theo de Raadt
Not a strong requirement.

> If a program requires studio, wpath, rpath, dns, and inet. It spawns
> multiple threads. The socket binding thread is taken over, runs arbitrary
> code that overflows a buffer of the thread listening to a pipe with rpath
> and stdio permissions it reads the binary of an executable the company
> wants to remain private, but is on the paths list, which gives the process
> unintentional read permissions and sends it to the attacker.
> Because we know everybody writes perfect code. With finer grained paths
> permissions, it is possible to gain even better control amidst really well
> pledged and privilege separated programs(even if they are imperfectly
> bounded), it may be possible to have a slightly more complicated paths
> setup with less privilege separation, written by programmers that spend a
> bit less time with privilege separation, to meet deadlines and achieve
> comparable results.
> 
> On Sat, Sep 3, 2016, 04:41 ludovic coues  wrote:
> 
> > 2016-09-03 11:04 GMT+02:00 Luke Small :
> > >
> > >
> > > Sorry  I was in the middle of something, but pledge can be a broad brush,
> > > unless you are dealing with one file, whether it is executed, read, or
> > > written and giving per process file permissions sounds pretty neat, and
> > it
> > > might just be a little simpler than making new users for each subset of
> > > privileges, populating each chrooted home folder with a specific set of
> > > permissions (as is what appears to me to have happened with pkg_add).
> > Since
> > > pledge's promises can make it where you can execute a file without read
> > > permission, it seems ideal to continue that tradition with the paths
> > >
> > >   On Sat, Sep 3, 2016, 03:07 Luke Small  wrote:
> > >>
> > >> In pledge, presumably there will be an accessible paths list. Maybe you
> > >> grant a process root access, and you need to read a file which is only
> > >> granted by root access, and you need write access for another file, so
> > the
> > >> pledge permissions reflect that. On the presumed current path, you would
> > >> leave write access for the first file and maybe you don't need the
> > process
> > >> to have read permissions on an execl() program. You can prohibit your
> > >> process from reading your software or binary, even if it may have
> > >> permissions to do so.
> > >>
> >
> > That's not a specific use case.
> > Either you should provide a patch or an exemple of a real program that
> > is limited by the current design of pledge.
> >
> > Currently, if you want a program that can only read a file, you pledge
> > rpath. If you want the ability to exec file, you pledge exec.
> >
> > If you want a program that can exec a set of file and write in
> > another, either you run your program as a user and group that can't
> > write the set of file you want to exec (W^X) or you write two program,
> > one pledging for write the other for read.
> >
> > There following paper have an exemple of how the second design can be done.
> > http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html
> >
> >
> > --
> >
> > Cordialement, Coues Ludovic
> > +336 148 743 42



Re: Building OpenBSD 6.0 -stable - Error

2016-09-03 Thread Ted Unangst
Teno Deuter wrote:
> installed a fresh 6.0 AMD64 and tried to build 'stable' from source.
> 
> Here is what I did as 'root' (as described in:
> http://www.openbsd.org/stable.html):
> 
> export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs
> cd /usr; cvs checkout -P -rOPENBSD_6_0 src

there's some repo surgery in progress. it should be fixed eventually.



Re: might it be better to have three paths lists

2016-09-03 Thread Luke Small
If a program requires studio, wpath, rpath, dns, and inet. It spawns
multiple threads. The socket binding thread is taken over, runs arbitrary
code that overflows a buffer of the thread listening to a pipe with rpath
and stdio permissions it reads the binary of an executable the company
wants to remain private, but is on the paths list, which gives the process
unintentional read permissions and sends it to the attacker.
Because we know everybody writes perfect code. With finer grained paths
permissions, it is possible to gain even better control amidst really well
pledged and privilege separated programs(even if they are imperfectly
bounded), it may be possible to have a slightly more complicated paths
setup with less privilege separation, written by programmers that spend a
bit less time with privilege separation, to meet deadlines and achieve
comparable results.

On Sat, Sep 3, 2016, 04:41 ludovic coues  wrote:

> 2016-09-03 11:04 GMT+02:00 Luke Small :
> >
> >
> > Sorry  I was in the middle of something, but pledge can be a broad brush,
> > unless you are dealing with one file, whether it is executed, read, or
> > written and giving per process file permissions sounds pretty neat, and
> it
> > might just be a little simpler than making new users for each subset of
> > privileges, populating each chrooted home folder with a specific set of
> > permissions (as is what appears to me to have happened with pkg_add).
> Since
> > pledge's promises can make it where you can execute a file without read
> > permission, it seems ideal to continue that tradition with the paths
> >
> >   On Sat, Sep 3, 2016, 03:07 Luke Small  wrote:
> >>
> >> In pledge, presumably there will be an accessible paths list. Maybe you
> >> grant a process root access, and you need to read a file which is only
> >> granted by root access, and you need write access for another file, so
> the
> >> pledge permissions reflect that. On the presumed current path, you would
> >> leave write access for the first file and maybe you don't need the
> process
> >> to have read permissions on an execl() program. You can prohibit your
> >> process from reading your software or binary, even if it may have
> >> permissions to do so.
> >>
>
> That's not a specific use case.
> Either you should provide a patch or an exemple of a real program that
> is limited by the current design of pledge.
>
> Currently, if you want a program that can only read a file, you pledge
> rpath. If you want the ability to exec file, you pledge exec.
>
> If you want a program that can exec a set of file and write in
> another, either you run your program as a user and group that can't
> write the set of file you want to exec (W^X) or you write two program,
> one pledging for write the other for read.
>
> There following paper have an exemple of how the second design can be done.
> http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html
>
>
> --
>
> Cordialement, Coues Ludovic
> +336 148 743 42



Building OpenBSD 6.0 -stable - Error

2016-09-03 Thread Teno Deuter
installed a fresh 6.0 AMD64 and tried to build 'stable' from source.

Here is what I did as 'root' (as described in:
http://www.openbsd.org/stable.html):

export CVSROOT=anon...@anoncvs1.ca.openbsd.org:/cvs
cd /usr; cvs checkout -P -rOPENBSD_6_0 src

# cd /usr/src/sys/arch/$(uname -m)/conf
# config GENERIC.MP
# cd /usr/src/sys/arch/$(uname -m)/compile/GENERIC.MP
# make clean && make

# cd /usr/src/sys/arch/$(uname -m)/compile/GENERIC.MP
# make install
# reboot

# rm -rf /usr/obj/*
# cd /usr/src
# make obj

and I get following error message:

===> lib
===> lib/csu
/usr/src/lib/csu/obj -> /usr/obj/lib/csu
===> lib/libarch
===> lib/libarch/alpha
/usr/src/lib/libarch/alpha/obj -> /usr/obj/lib/libarch/alpha
===> lib/libarch/amd64
/usr/src/lib/libarch/amd64/obj -> /usr/obj/lib/libarch/amd64
===> lib/libarch/arm
/usr/src/lib/libarch/arm/obj -> /usr/obj/lib/libarch/arm
===> lib/libarch/i386
/usr/src/lib/libarch/i386/obj -> /usr/obj/lib/libarch/i386
===> lib/libarch/mips64
/usr/src/lib/libarch/mips64/obj -> /usr/obj/lib/libarch/mips64
===> lib/libc
/usr/src/lib/libc/obj -> /usr/obj/lib/libc
===> lib/libcrypto
make: don't know how to make obj
Stop in lib/libcrypto
*** Error 2 in lib (:48 'obj')
*** Error 1 in /usr/src (:48 'obj')

Thank you for your support.



Re: Trying to find/install msgfmt(1) from gettext

2016-09-03 Thread Stuart Henderson
On 2016-09-02, Nick Gonella  wrote:
> I'm currently trying to port some code from Linux and within the
> Makefile, there is a reference to the utility msgfmt(1). After some
> Googling, I found that this should come as a part of gettext(1), but I
> can't seem to find how to get msgfmt(1) on OpenBSD. Any advice you have
> would be appreciated. Regards,

$ pkg_add pkglocatedb
..
$ pkg_locate bin/msgfmt
gettext-tools-0.19.7p1:devel/gettext-tools:/usr/local/bin/msgfmt
mailman-2.1.22:mail/mailman:/usr/local/lib/mailman/bin/msgfmt.py



Re: OpenBSD 6.0 panic

2016-09-03 Thread Stuart Henderson
On 2016-09-03, Bastien Durel  wrote:
> Le 02/09/2016 à 23:28, Ryan Freeman a écrit :
>> On Fri, Sep 02, 2016 at 06:25:15PM +0200, Bastien Durel wrote:
>>> Hello.
>>>
>>> I upgraded my router to 6.0 yesterday, and now I got a panic each time
>>> I reboot it.
>>
>> Hi,
>>
>> Did you happen to forget to do your pkg_add -u to upgrade packages?  I
>> suspect it might be openvpn not updated yet throwing the error?
>>
>> Cheers!
>> -ryan
>>
> Hello,
>
> I did ran pkg_add -u, but there's a mess in my package database, and 
> some packages was not registered

I would do this: run pkg_check, let it finish, run pkg_add -u, run pkg_check 
again.
But I don't think it's related to the panic.

> But upgrading it did not solved the panic (I would have been surprised 
> if an application crash made the kernel panic)

It's a bug obviously, but it can happen sometimes.



Re: might it be better to have three paths lists

2016-09-03 Thread Stuart Henderson
On 2016-09-03, ludovic coues  wrote:
> What is the use case ?

More than "what is the use case" is needed here - a good start would be
a diff for 3 or 4 examples of existing programs in base showing how it would
be used to improve things.



Re: System monitor in base?

2016-09-03 Thread Stuart Henderson
On 2016-09-02, Martijn van Duren  wrote:
> On 09/03/16 00:46, Aioi Yuuko wrote:
>> Hi,
>> 
>> I'm trying to wean myself off external packages as much as possible. Is 
>> there a common, accepted way of viewing, for instance, battery life, with 
>> only included programs?
>> 
>
> It depends upon your precise needs, but you could look into sensorsd(8)
> and snmpd(8), or just run apm(8) if you want the current status.
>
>

I like "systat sensors" if I'm watching temperatures etc.



Re: might it be better to have three paths lists

2016-09-03 Thread ludovic coues
2016-09-03 11:04 GMT+02:00 Luke Small :
>
>
> Sorry  I was in the middle of something, but pledge can be a broad brush,
> unless you are dealing with one file, whether it is executed, read, or
> written and giving per process file permissions sounds pretty neat, and it
> might just be a little simpler than making new users for each subset of
> privileges, populating each chrooted home folder with a specific set of
> permissions (as is what appears to me to have happened with pkg_add). Since
> pledge's promises can make it where you can execute a file without read
> permission, it seems ideal to continue that tradition with the paths
>
>   On Sat, Sep 3, 2016, 03:07 Luke Small  wrote:
>>
>> In pledge, presumably there will be an accessible paths list. Maybe you
>> grant a process root access, and you need to read a file which is only
>> granted by root access, and you need write access for another file, so the
>> pledge permissions reflect that. On the presumed current path, you would
>> leave write access for the first file and maybe you don't need the process
>> to have read permissions on an execl() program. You can prohibit your
>> process from reading your software or binary, even if it may have
>> permissions to do so.
>>

That's not a specific use case.
Either you should provide a patch or an exemple of a real program that
is limited by the current design of pledge.

Currently, if you want a program that can only read a file, you pledge
rpath. If you want the ability to exec file, you pledge exec.

If you want a program that can exec a set of file and write in
another, either you run your program as a user and group that can't
write the set of file you want to exec (W^X) or you write two program,
one pledging for write the other for read.

There following paper have an exemple of how the second design can be done.
http://quigon.bsws.de/papers/2014/asiabsdcon/mgp00010.html


-- 

Cordialement, Coues Ludovic
+336 148 743 42



Re: System monitor in base?

2016-09-03 Thread Reyk Floeter
On Fri, Sep 02, 2016 at 05:02:07PM -0700, Aioi Yuuko wrote:
> Sorry, I was vague in my original email: What I meant was, I'm aware that 
> there are ways of getting it off the command line; I'm mostly curious about 
> getting it on my desktop so it's easy to glance at. Would my best bet be 
> running a script like that in a particular xterm, and marking that xterm as 
> sticky in fvwm?On 2 Sep 2016 16:22, Raf Czlonka  wrote:
> >

$ systat vm

Reyk

> > On Fri, Sep 02, 2016 at 11:46:27PM BST, Aioi Yuuko wrote: 
> > > Hi, 
> > > 
> > > I'm trying to wean myself off external packages as much as possible. 
> > > Is there a common, accepted way of viewing, for instance, battery 
> > > life, with only included programs? 
> >
> > Hi Aioi, 
> >
> > There's the already mentioned apm(8) (i.e. -l, -m options) or you 
> > could run something like this: 
> >
> > #!/bin/sh 
> >
> > sysctl -n hw.sensors.acpiac0.indicator0 \ 
> > hw.sensors.acpibat0.watthour0 \ 
> > hw.sensors.acpibat0.watthour3 | awk 'NR == 1 { ac = $1 } 
> > NR == 2 { full = $1 } 
> > NR == 3 { remaining = $1 } 
> > END { if ( ac == "On" ) 
> > state = "charging" 
> > else 
> > state = "discharging" 
> > printf("%s %d%s %s%s\n", "Remaining battery life is", 
> > remaining/full*100, "% and it is", state, "\.") }' 
> >
> > Regards, 
> >
> > Raf 
> 

-- 



Re: might it be better to have three paths lists

2016-09-03 Thread Luke Small
In pledge, presumably there will be an accessible paths list. Maybe you
grant a process root access, and you need to read a file which is only
granted by root access, and you need write access for another file, so the
pledge permissions reflect that. On the presumed current path, you would
leave write access for the first file and maybe you don't need the process
to have read permissions on an execl() program. You can prohibit your
process from reading your software or binary, even if it may have
permissions to do so.

On Sat, Sep 3, 2016, 02:34 ludovic coues  wrote:

> What is the use case ?
>
> 2016-09-03 4:15 GMT+02:00 Luke Small :
> > wouldn't it be more secure to have a write, read, and execute capable
> paths
> > lists in pledge()
> >
>
>
>
> --
>
> Cordialement, Coues Ludovic
> +336 148 743 42



Re: OpenBSD 6.0 panic

2016-09-03 Thread Bastien Durel

Le 02/09/2016 à 23:28, Ryan Freeman a écrit :

On Fri, Sep 02, 2016 at 06:25:15PM +0200, Bastien Durel wrote:

Hello.

I upgraded my router to 6.0 yesterday, and now I got a panic each time
I reboot it.


Hi,

Did you happen to forget to do your pkg_add -u to upgrade packages?  I
suspect it might be openvpn not updated yet throwing the error?

Cheers!
-ryan


Hello,

I did ran pkg_add -u, but there's a mess in my package database, and 
some packages was not registered


# pkg_add openvpn
quirks-2.241 signed on 2016-07-26T16:56:10Z
Collision in openvpn-2.3.11: the following files already exist
/usr/local/include/openvpn/openvpn-plugin.h from openvpn-2.3.11 
(different checksum)
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.a from 
openvpn-2.3.11 (different checksum)
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.la from 
openvpn-2.3.11 (same checksum)
/usr/local/lib/openvpn/plugins/openvpn-plugin-down-root.so from 
openvpn-2.3.11 (different checksum)
/usr/local/man/man8/openvpn.8 from openvpn-2.3.11 (different 
checksum)

/usr/local/sbin/openvpn from openvpn-2.3.11 (different checksum)
[...]

wide-dhcpc6 was affected too.

But upgrading it did not solved the panic (I would have been surprised 
if an application crash made the kernel panic)


--
Bastien



Re: might it be better to have three paths lists

2016-09-03 Thread ludovic coues
What is the use case ?

2016-09-03 4:15 GMT+02:00 Luke Small :
> wouldn't it be more secure to have a write, read, and execute capable paths
> lists in pledge()
>



-- 

Cordialement, Coues Ludovic
+336 148 743 42