Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> > Which is the sudo case and why sudo uses a separate pty/tty pair as it's > > not just TIOCSTI that's an issue but there are a load of ioctls that do > > things like cause signals to the process or are just annoying - > > vhangup(), changing the speed etc > > > > (And for console changing the ke

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> open() what? As far as I know, for System-V PTYs, there is no path you can > open() that will give you the PTY master. Am I missing something? Sorry brain fade - no. > > >> > If I want to do the equvalent of the TIOCSTI attack then I fork a process > >> > and exit the parent. The child can now

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> Really? By "pty", are you referring to the master? If so, as far as I know, > to go from the slave to the master, you need one of: > > - ptrace access to a process that already has an FD to the master, via >ptrace() or so (/proc/$pid/fd/$fd won't work) > - for a BSD PTY (which AFAIK isn't

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, 25 Apr 2017 15:56:32 +0200 Jann Horn wrote: > On Tue, Apr 25, 2017 at 3:47 PM, Alan Cox wrote: > >> There could be a few user programs that would be effected by this > >> change. > >> See: > >> notable programs are: agetty, cs

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

> I took a closer look at the dosemu code. It appears that it does not That doesn't tell you want DOS itself will try and do... > purposely utilize SGDT to obtain the descriptor table while in vm86. It > does use SGDT (in protected mode) to emulate certain functionality such > as the Virtual xxx

Re: [PATCH 0/6] Intel Secure Guard Extensions

> But... that will mean that my ssh will need to be SGX-aware, and that > I will not be able to switch to AMD machine in future. ... or to other > Intel machine for that matter, right? I'm not privy to AMD's CPU design plans. However I think for the ssl/ssh case you'd use the same interfaces curr

Re: [PATCH 0/6] Intel Secure Guard Extensions

> > Storing your ssh private key encrypted such that even someone who > > completely compromises your system can't get the actual private key > > Well, if someone gets root on my system, he can get my ssh private > key right? Potentially not. If you are using a TPM or other TEE (such as SGX

Re: [PATCH 0/6] Intel Secure Guard Extensions

> Replay Protected Memory Block. It's a device that allows someone to > write to it and confirm that the write happened and the old contents > is no longer available. You could use it to implement an enclave that > checks a password for your disk but only allows you to try a certain > number of t

Re: Kernel docs: muddying the waters a bit

> DocBook is a means to an end; nobody really wants DocBook itself as far > as I can tell. We only have docbook because it was the tool of choice rather a lot of years ago to then get useful output formats. It was just inherited when borrowed the original scripts from Gnome/Gtk. It's still the mo