On Mon, 13 Feb 2017, Kees Cook wrote:
> Okay, cool. Thanks. (Also, where does "setpriv" live? I must need a
> new set of util-linux or something?)
Indeed, a newer version of util-linux[0] should do, although
Debian/testing appears to have an extra package just for "setpriv":
https://packages.d
On Mon, Feb 13, 2017 at 11:01 AM, Andy Lutomirski wrote:
> On Fri, Feb 10, 2017 at 3:44 PM, Kees Cook wrote:
>> On Wed, Jan 18, 2017 at 3:35 PM, Andy Lutomirski wrote:
>>> On Wed, Jan 18, 2017 at 2:50 PM, Djalal Harouni wrote:
Andy I don't follow here, no_new_privs is never cleared right ?
On Fri, Feb 10, 2017 at 3:44 PM, Kees Cook wrote:
> On Wed, Jan 18, 2017 at 3:35 PM, Andy Lutomirski wrote:
>> On Wed, Jan 18, 2017 at 2:50 PM, Djalal Harouni wrote:
>>> Andy I don't follow here, no_new_privs is never cleared right ? I
>>> can't see the corresponding clear bit code for it.
>>
>>
On Wed, Jan 18, 2017 at 3:35 PM, Andy Lutomirski wrote:
> On Wed, Jan 18, 2017 at 2:50 PM, Djalal Harouni wrote:
>> Andy I don't follow here, no_new_privs is never cleared right ? I
>> can't see the corresponding clear bit code for it.
>
> I believe that unsharing userns clears no_new_privs.
Ser
On Fri, Feb 10, 2017 at 6:40 AM, Lafcadio Wluiki wrote:
> On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski wrote:
>
>> I agree that the kernel change to do it per task is very simple. But
>> this is an unfortunate slippery slope. What if you want to block off
>> everything in /proc that isn't a
On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski wrote:
> I agree that the kernel change to do it per task is very simple. But
> this is an unfortunate slippery slope. What if you want to block off
> everything in /proc that isn't associated with a PID? What if you
> want to suppress /sys acce
On Mon, Jan 23, 2017 at 9:07 PM, Andy Lutomirski wrote:
> On Mon, Jan 23, 2017 at 3:46 AM, Djalal Harouni wrote:
>> On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski wrote:
>>> I agree that the kernel change to do it per task is very simple. But
>>> this is an unfortunate slippery slope. What i
On Mon, Jan 23, 2017 at 3:46 AM, Djalal Harouni wrote:
> On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski wrote:
>> I agree that the kernel change to do it per task is very simple. But
>> this is an unfortunate slippery slope. What if you want to block off
>> everything in /proc that isn't asso
On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski wrote:
> On Fri, Jan 20, 2017 at 8:33 AM, Djalal Harouni wrote:
>> On Thu, Jan 19, 2017 at 8:52 PM, Andy Lutomirski wrote:
>>> On Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni wrote:
>> [...]
Sure, the hidepid mount option is old enough, and
On Fri, Jan 20, 2017 at 8:33 AM, Djalal Harouni wrote:
> On Thu, Jan 19, 2017 at 8:52 PM, Andy Lutomirski wrote:
>> On Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni wrote:
> [...]
>>> Sure, the hidepid mount option is old enough, and this per-task
>>> hidepid is clearly defined only for procfs an
On Thu, Jan 19, 2017 at 8:52 PM, Andy Lutomirski wrote:
> On Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni wrote:
[...]
>> Sure, the hidepid mount option is old enough, and this per-task
>> hidepid is clearly defined only for procfs and per task, we can't add
>> another switch that's relate to bot
On Thu, Jan 19, 2017 at 8:52 PM, Andy Lutomirski wrote:
>> Sure, the hidepid mount option is old enough, and this per-task
>> hidepid is clearly defined only for procfs and per task, we can't add
>> another switch that's relate to both a filesystem and pid namespaces,
>> it will be a bit complica
On Thu, Jan 19, 2017 at 12:35 AM, Andy Lutomirski wrote:
> And from that point on neither nginx itself, nor any of its child
> processes may see processes in /proc anymore that belong to a different
> user than "www-data". Other services running on the same system remain
> unaffec
On Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni wrote:
> On Thu, Jan 19, 2017 at 12:35 AM, Andy Lutomirski wrote:
>> On Wed, Jan 18, 2017 at 2:50 PM, Djalal Harouni wrote:
Also, this one-way thing seems wrong to me. I think it should roughly
follow the no_new_privs rules instead. IOW
On Thu, Jan 19, 2017 at 12:35 AM, Andy Lutomirski wrote:
> On Wed, Jan 18, 2017 at 2:50 PM, Djalal Harouni wrote:
[...]
>
> …
> prctl(PR_SET_HIDEPID, 2);
> …
>
> And from that point on neither nginx itself, nor any of its child
> processes may s
On Wed, Jan 18, 2017 at 2:50 PM, Djalal Harouni wrote:
> On Tue, Jan 17, 2017 at 9:33 PM, Andy Lutomirski wrote:
>> On Mon, Jan 16, 2017 at 9:15 AM, Djalal Harouni wrote:
>>> Cc linux-api
>>>
>>> On Mon, Jan 16, 2017 at 2:23 PM, Djalal Harouni wrote:
From: Djalal Harouni
Th
On Tue, Jan 17, 2017 at 9:33 PM, Andy Lutomirski wrote:
> On Mon, Jan 16, 2017 at 9:15 AM, Djalal Harouni wrote:
>> Cc linux-api
>>
>> On Mon, Jan 16, 2017 at 2:23 PM, Djalal Harouni wrote:
>>>
>>> From: Djalal Harouni
>>>
>>> This adds a new per-task hidepid= flag that is honored by procfs whe
Turning on the hidepid group thing for a tightly managed OS like
Android is much easier than doing that for an established distro,
without breaking compatibility. Moreover using groups for this kind of
sandboxing isn't that great anyway as group memberships are "sticky":
whenever some code had it,
> This should permit Linux distributions to more comprehensively lock
> down
> their services, as it allows an isolated opt-in for hidepid= for
> specific services. Previously hidepid= could only be set system-wide,
> and then specific services had to be excluded by group membership,
> essentially
From: Djalal Harouni
This adds a new per-task hidepid= flag that is honored by procfs when
presenting /proc to the user, in addition to the existing hidepid= mount
option. So far, hidepid= was exclusively a per-pidns setting. Locking
down a set of processes so that they cannot see other user's pr
20 matches
Mail list logo
