Re: General flags to turn things off (getrandom, pid lookup, etc)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jul 25, 2014 at 1:15 PM, Dave Jones <davej@xxxxxxxxxx> wrote:
> On Fri, Jul 25, 2014 at 11:30:48AM -0700, Andy Lutomirski wrote:
>
>  > There is recent interest in having a way to turn generally-available
>  > kernel features off.  Maybe we should add a good one so we can stop
>  > bikeshedding and avoid proliferating dumb interfaces.
>  >
>  > Things that might want to be turn-off-able include:
>  >  - getrandom with GRND_RANDOM [from the getrandom threads]
>  >  - Any lookup of a non-self pid [from the capsicum thread]
>  >  - Any lookup of a pid outside the caller thread group [capsicum]
>  >  - Various architectural things (personal wishlist), e.g.:
>  >     - RDTSC and userspace HPET access
>  >     - CPUID?
>  >     - 32-bit GDT code segments [huge attack surface]
>  >     - 64-bit GDT code segments [probably pointless]
>
> I'm not sure there's value in disabling cpuid dev interface,
> when the instruction is unprivileged.

I meant the CPUID instruction.  Some CPUs have a setting that turns
off the CPUID instruction for user code.  In principle, all VMs can do
this, too, if the hypervisor would be kind enough to help out.

I only mentioned the x86 stuff here to make the point that there are
quite a few possibilities along these lines.  There's actually already
a way to turn off RDTSC, but it's not currently very useful because it
doesn't do the right thing for the vDSO.  That could be fixed, but
there's certainly no reason to make any of the other stuff here wait
for that.

>
>  > I would propose a new syscall for this:
>  >
>  > long restrict_userspace(int mode, int type, int value, int flags);
>
> do the restrictions happen system-wide like in say SELinux,
> or only within the calling process, like seccomp ?
>

The calling process and children, like seccomp.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux