Quoting Alan Cox (gno...@lxorguk.ukuu.org.uk):
> > Alan is right. CAP_SYS_ADMIN allows crossing the tty barrier.
>
> I don't need CAP_ anything to mmap your frame buffer, or use selection to
> cut and paste text into the terminal.
>
> > Broken applications that you can wrap in a pty/tty pair as
> Alan is right. CAP_SYS_ADMIN allows crossing the tty barrier.
I don't need CAP_ anything to mmap your frame buffer, or use selection to
cut and paste text into the terminal.
> Broken applications that you can wrap in a pty/tty pair as the lxc
> application does would be defeated if those appl
On Wed, May 31, 2017 at 7:52 AM, Alan Cox wrote:
>> > So tty stuff should under a tty capabilities.
>>
>> (last reply on this)
>>
>> Currently capabilities.7 says
>>
>> * employ the TIOCSTI ioctl(2) to insert characters into the
>> input queue of a
>> terminal othe
> > So tty stuff should under a tty capabilities.
>
> (last reply on this)
>
> Currently capabilities.7 says
>
> * employ the TIOCSTI ioctl(2) to insert characters into the
> input queue of a
> terminal other than the caller's controlling terminal;
>
> for CAP
Quoting Peter Dolding (oia...@gmail.com):
> On Sat, May 20, 2017 at 12:33 AM, Serge E. Hallyn wrote:
> > On Fri, May 19, 2017 at 12:48:17PM +1000, Peter Dolding wrote:
> >> Using cap_sys_admin as fix is like removing car windsheld because
> >> vision is being blocked by a rock hitting it.
> >
> >
On Sat, May 20, 2017 at 12:33 AM, Serge E. Hallyn wrote:
> On Fri, May 19, 2017 at 12:48:17PM +1000, Peter Dolding wrote:
>> Using cap_sys_admin as fix is like removing car windsheld because
>> vision is being blocked by a rock hitting it.
>
> Nonsense. If the application has cap_sys_admin then i
On Fri, May 19, 2017 at 12:48:17PM +1000, Peter Dolding wrote:
> Using cap_sys_admin as fix is like removing car windsheld because
> vision is being blocked by a rock hitting it.
Nonsense. If the application has cap_sys_admin then it is less contained and
more trusted anyway. If I went to the tr
On Thu, May 18, 2017 at 1:18 PM, Kees Cook wrote:
> On Wed, May 17, 2017 at 11:25 AM, Daniel Micay wrote:
>> On Wed, 2017-05-17 at 17:41 +0100, Alan Cox wrote:
>>> > If we're adjusting applications, they should be made to avoid
>>> > TIOSCTI
>>> > completely. This looks to me a lot like the symli
On Wed, May 17, 2017 at 11:25 AM, Daniel Micay wrote:
> On Wed, 2017-05-17 at 17:41 +0100, Alan Cox wrote:
>> > If we're adjusting applications, they should be made to avoid
>> > TIOSCTI
>> > completely. This looks to me a lot like the symlink restrictions:
>> > yes,
>> > userspace should be fixed
On Wed, 2017-05-17 at 17:41 +0100, Alan Cox wrote:
> > If we're adjusting applications, they should be made to avoid
> > TIOSCTI
> > completely. This looks to me a lot like the symlink restrictions:
> > yes,
> > userspace should be fixed to the do the right thing, but why not
> > provide support to
> If we're adjusting applications, they should be made to avoid TIOSCTI
> completely. This looks to me a lot like the symlink restrictions: yes,
> userspace should be fixed to the do the right thing, but why not
> provide support to userspace to avoid the problem entirely?
We do it's called pty/tt
On Wed, May 17, 2017 at 1:48 AM, Serge E. Hallyn wrote:
> Quoting Kees Cook (keesc...@chromium.org):
>> On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote:
>> > On 05/16/2017 05:01 AM, Peter Dolding wrote:
>> >>>
>> >>>
>> >>> I could see a case being make for CAP_SYS_TTY_CONFIG. However I still
>
On 05/16/2017 05:43 PM, Peter Dolding wrote:
On Wed, May 17, 2017 at 12:28 AM, Kees Cook wrote:
On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote:
On 05/16/2017 05:01 AM, Peter Dolding wrote:
I could see a case being make for CAP_SYS_TTY_CONFIG. However I still
choose to do with CAP_SYS_AD
On Wed, May 17, 2017 at 12:28 AM, Kees Cook wrote:
> On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote:
>> On 05/16/2017 05:01 AM, Peter Dolding wrote:
I could see a case being make for CAP_SYS_TTY_CONFIG. However I still
choose to do with CAP_SYS_ADMIN because it is already i
Quoting Kees Cook (keesc...@chromium.org):
> On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote:
> > On 05/16/2017 05:01 AM, Peter Dolding wrote:
> >>>
> >>>
> >>> I could see a case being make for CAP_SYS_TTY_CONFIG. However I still
> >>> choose to do with CAP_SYS_ADMIN because it is already in us
On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote:
> On 05/16/2017 05:01 AM, Peter Dolding wrote:
>>>
>>>
>>> I could see a case being make for CAP_SYS_TTY_CONFIG. However I still
>>> choose to do with CAP_SYS_ADMIN because it is already in use in the
>>> TIOCSTI ioctl.
>>>
>> Matt Brown don't giv
On 05/16/2017 05:01 AM, Peter Dolding wrote:
I could see a case being make for CAP_SYS_TTY_CONFIG. However I still
choose to do with CAP_SYS_ADMIN because it is already in use in the
TIOCSTI ioctl.
Matt Brown don't give me existing behaviour.CAP_SYS_ADMIN is
overload. The documentation t
>
> I could see a case being make for CAP_SYS_TTY_CONFIG. However I still
> choose to do with CAP_SYS_ADMIN because it is already in use in the
> TIOCSTI ioctl.
>
Matt Brown don't give me existing behaviour.CAP_SYS_ADMIN is
overload. The documentation tells you that you are not to expand it
a
On 05/15/2017 07:10 PM, Peter Dolding wrote:
On Tue, May 16, 2017 at 6:57 AM, Alan Cox wrote:
O> I'm not implying that my patch is supposed to provide safety for
"hundreds of other" issues. I'm looking to provide a way to lock down a
single TTY ioctl that has caused real security issues to ari
On Tue, May 16, 2017 at 6:57 AM, Alan Cox wrote:
> O> I'm not implying that my patch is supposed to provide safety for
>> "hundreds of other" issues. I'm looking to provide a way to lock down a
>> single TTY ioctl that has caused real security issues to arise. For
>
> In other words you are not ac
O> I'm not implying that my patch is supposed to provide safety for
> "hundreds of other" issues. I'm looking to provide a way to lock down a
> single TTY ioctl that has caused real security issues to arise. For
In other words you are not actually fixing anything.
> this reason, it's completely i
On 05/10/2017 04:29 PM, Alan Cox wrote:
On Fri, 5 May 2017 19:20:16 -0400
Matt Brown wrote:
This patchset introduces the tiocsti_restrict sysctl, whose default is
controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this
control restricts all TIOCSTI ioctl calls from non CAP_SYS_A
On Wed, 2017-05-10 at 21:29 +0100, Alan Cox wrote:
>
> In addition your change to allow it to be used by root in the guest
> completely invalidates any protection you have because I can push
>
> "rm -rf /\n"
>
> as root in my namespace and exit
>
> The tty buffers are not flushed across the con
On Fri, 5 May 2017 19:20:16 -0400
Matt Brown wrote:
> This patchset introduces the tiocsti_restrict sysctl, whose default is
> controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this
> control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.
>
> This patch was inspi
24 matches
Mail list logo
