Re: The OpenBSD pledge

[Domagoj Stolfa]

On Mon, Jun 13, 2016 at 9:44 AM, Florian Ermisch <
florian.ermi...@alumni.tu-berlin.de> wrote:

>
>
> Am 11. Juni 2016 18:31:25 MESZ, schrieb Alan Somers :
> > On Sat, Jun 11, 2016 at 5:32 AM, Domagoj Stolfa
> >  wrote:
> > > Yes, it would maybe make sense to do so. I am not too familiar with
> > > capsicum(4), but glancing over it, it might be possible. If
> > anything, it
> > > would allow for code reuse from the OpenBSD ports and increased
> > portability
> > > in the future. Maybe the people who have worked with capsicum(4) or
> > have
> > > developed it could give some more insight on this.
> > >
> >
> > I don't see how it would be possible.  Capsicum is all about file
> > descriptors.  When you call cap_enter(), you give up the ability to
> > access global namespaces.  For example, you can no longer open files
> > (except using openat(2) for files in a subdirectory of a directory
> > which is already opened).  OTOH, pledge is all about sycalls.  When
> > you pledge, you give up the ability to use certain syscalls,
> > regardless of what file descriptors they might involve.  So for
> > example, a program that uses pledge(2) to prohibit networking syscalls
> > can't simply replace pledge(2) with cap_enter(2), because it may need
> > to open files after pledging.
> >
> > -Alan
>
> Thanks for the clarification, Alan.
> So pledge(2) would, if implemented in
> FreeBSD, complement capsicum.
> They would only overlap around file
> descriptors, where capsicum could
> enforce a processes pledge like to only
> ever write to one file which is its logfile.
>
> Florian
>

It indeed does seem like they could complement each other.
One could pledge the entire program and use capsicum(4)
to limit certain file descriptors even further, but not the rest
of the program, such as a TCP socket. This does seem like
increased simplicity in limiting the whole program using
pledge(2) and the additional benefit that capsicum(4) offers
in terms of file descriptors. The question remains though, how
would they interact with each other? A single pledge(2) call, as
Alan said could limit the operation of capsicum(4).

Domagoj
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The OpenBSD pledge

[Florian Ermisch]

Am 11. Juni 2016 18:31:25 MESZ, schrieb Alan Somers :
> On Sat, Jun 11, 2016 at 5:32 AM, Domagoj Stolfa
>  wrote:
> > Yes, it would maybe make sense to do so. I am not too familiar with
> > capsicum(4), but glancing over it, it might be possible. If
> anything, it
> > would allow for code reuse from the OpenBSD ports and increased
> portability
> > in the future. Maybe the people who have worked with capsicum(4) or
> have
> > developed it could give some more insight on this.
> >
> 
> I don't see how it would be possible.  Capsicum is all about file
> descriptors.  When you call cap_enter(), you give up the ability to
> access global namespaces.  For example, you can no longer open files
> (except using openat(2) for files in a subdirectory of a directory
> which is already opened).  OTOH, pledge is all about sycalls.  When
> you pledge, you give up the ability to use certain syscalls,
> regardless of what file descriptors they might involve.  So for
> example, a program that uses pledge(2) to prohibit networking syscalls
> can't simply replace pledge(2) with cap_enter(2), because it may need
> to open files after pledging.
> 
> -Alan

Thanks for the clarification, Alan.
So pledge(2) would, if implemented in
FreeBSD, complement capsicum.
They would only overlap around file
descriptors, where capsicum could 
enforce a processes pledge like to only
ever write to one file which is its logfile.

Florian
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The OpenBSD pledge

[Alan Somers]

On Sat, Jun 11, 2016 at 5:32 AM, Domagoj Stolfa
 wrote:
> Yes, it would maybe make sense to do so. I am not too familiar with
> capsicum(4), but glancing over it, it might be possible. If anything, it
> would allow for code reuse from the OpenBSD ports and increased portability
> in the future. Maybe the people who have worked with capsicum(4) or have
> developed it could give some more insight on this.
>

I don't see how it would be possible.  Capsicum is all about file
descriptors.  When you call cap_enter(), you give up the ability to
access global namespaces.  For example, you can no longer open files
(except using openat(2) for files in a subdirectory of a directory
which is already opened).  OTOH, pledge is all about sycalls.  When
you pledge, you give up the ability to use certain syscalls,
regardless of what file descriptors they might involve.  So for
example, a program that uses pledge(2) to prohibit networking syscalls
can't simply replace pledge(2) with cap_enter(2), because it may need
to open files after pledging.

-Alan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Fwd: The OpenBSD pledge

[Domagoj Stolfa]

Yes, it would maybe make sense to do so. I am not too familiar with
capsicum(4), but glancing over it, it might be possible. If anything, it
would allow for code reuse from the OpenBSD ports and increased portability
in the future. Maybe the people who have worked with capsicum(4) or have
developed it could give some more insight on this.

Domagoj
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The OpenBSD pledge

[Florian Ermisch]

Am 11. Juni 2016 12:38:34 MESZ, schrieb Wolfgang Zenker 
:
> Hi,
> 
> * Domagoj Stolfa  [160611 02:47]:
> > Has there been discussion on the OpenBSD's pledge going into the
> FreeBSD
> > kernel as an atomic syscall or as a MAC plugin?
> 
> I don't remember any discussions about this, but looking at OpenBSDs
> plege(2) manpage, isn't this something going in the same direction
> as the capsicum(4) framework, just with a much more simplistic
> interface?
> 
> Wolfgang
> 
One could argue it's a much easier to use
interface: "453 out of 707 base system 
binaries were adapted to use pledge [in
5.9]" [1]. The "Capsicum for FreeBSD" 
page at can.ac.uk lists 14 binaries in 
FreeBSD's base [2].

It might be possible to put a pledge 
compatible layer on top of capsicum to
reuse OpenBSD's patches for ports and
shared code in base but I know way too 
less about both mechanisms to even 
make an educated guess.

Regards, Florian

[1]: http://www.openbsd.org/59.html
[2]: https://www.cl.cam.ac.uk/research/security/capsicum/freebsd.html
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: The OpenBSD pledge

[Wolfgang Zenker]

Hi,

* Domagoj Stolfa  [160611 02:47]:
> Has there been discussion on the OpenBSD's pledge going into the FreeBSD
> kernel as an atomic syscall or as a MAC plugin?

I don't remember any discussions about this, but looking at OpenBSDs
plege(2) manpage, isn't this something going in the same direction
as the capsicum(4) framework, just with a much more simplistic interface?

Wolfgang
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

The OpenBSD pledge

[Domagoj Stolfa]

Has there been discussion on the OpenBSD's pledge going into the FreeBSD
kernel as an atomic syscall or as a MAC plugin?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"