On 10/21/14, Stuart Henderson <st...@openbsd.org> wrote:
> On 2014/10/21 13:32, Amit Kulkarni wrote:
>> On Tue, Oct 21, 2014 at 12:18 PM, patrick keshishian <pkesh...@gmail.com>
>> wrote:
>>
>> > On 10/21/14, Stuart Henderson <st...@openbsd.org> wrote:
>> > > On 2014/10/21 10:58, Amit Kulkarni wrote:
>> > >> On Tue, Oct 21, 2014 at 10:28 AM, Stuart Henderson
>> > >> <st...@openbsd.org>
>> > >> > I'm fetching distfiles as my normal uid, then doing builds as
>> > >> > pbuild.
>> > >> > pf.conf:
>> > >> >
>> > >> > "block quick log proto {tcp udp} user pbuild"
>> > >> >
>> > >> >
>> > >> This can be disabled by user and bypassed,
>> > >
>> > > If you're aware of a way in which an unprivileged user can change PF
>> > > rules, it's probably best if you let me (or security@) know in
>> > > private
>> > > mail.
>> >
>> > I read that comment as: the system admin, may not
>> > (forgets to?) enable such a rule. Also, the pf rule route
>> > seems a bit "clunky" and disjointed from the ports process.
>> >
>>
>>
>> Somebody might disable the default PF rules and overwrite with their own,
>> and forget about it. If it isn't caught by anybody else port might get
>> committed. In that case, it will be caught in a bulk build by someone.
>> Generally, people don't touch systrace enable/disable, but they usually
>> fiddle with PF rules. But yes, this is immaterial. Patrick got the drift
>> of
>> this, sorry for not explaining clearly in the initial email.
>
> Exact opposite on most machines I use for ports work I hardly ever
> touch PF rules there, but before we had build-as-nonroot I was often
> doing 'make USE_SYSTRACE=Yes' when working on a new port or testing
> a submission.
>
> systrace is not without problems, it can make some syscalls fail which
> people don't expect or check for, so can have an impact on how the build
> works (another issue is that it's very noticably slower).
>
>> > >> you can't bypass systrace during ports build. Also, it would be
>> > >> possible to place files in FAKE /etc i.e in places other than
>> > /usr/local?
>> > >
>> > > I'm confused. It's ok if the port build puts things in directories
>> > > writable by the user doing port builds, because that user only has
>> > > filesystem permissions to write to a limited number of places
>> > > (mostly the build dir).
>> >
>> > Consider a wip port, which may write files in $HOME, or
>> > worse yet, delete files or directories from $HOME.
>> >
>> > I always felt more at ease, knowing systrace would "slap"
>> > the hand that attempted that, whether maliciously or
>> > erroneously.
>
> Yes that is a problem if you do builds as your normal userid.I don't mean to split hairs on this. You guys know better. But, are you suggesting a $PORTUSER that the ports's infrastructure will automatically sudo to for all make commands? This I like! Otherwise, as an example, I maintain a notes.txt for ports I work on, contents of which includes a fair amount of output from `make SHOW=this-and-that'. It would be a bit of PITA to maintain that file as my everyday user. OK, said my piece, thanks for considering it. --patrick > >> > --patrick >> > >> >> +1 >> >> I am asking if user can create /etc/sysctl.conf in a port, that port >> overwrites the real /etc/sysctl.conf because a port has superuser >> privileges during install. If systrace is not there to catch it, would it >> get installed? > > It does not, not any more - this whole mail thread probably makes > little sense if you missed that change. > http://undeadly.org/cgi?action=article&sid=20141003132339 > > >> Or as Patrick says in another email: what about add/delete >> in $HOME? Systrace protects us here. Is there any way to solve this >> problem >> and the arbitrary net download problem during port building? > > Using a separate UID for builds protects against this too. > >
