lkml.org 
[lkml]   [2017]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
Quoting Peter Dolding (oiaohm@gmail.com):
> On Sat, May 20, 2017 at 12:33 AM, Serge E. Hallyn <serge@hallyn.com> 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 it is less contained and
> > more trusted anyway. If I went to the trouble to run an application in a
> > private user namespace (where it can have cap_sys_admin, but not targeted
> > at my tty) then it should be more contained. That's the point of targeted
> > capabilities.
>
> The thing that is missed every time is how much is cap_sys_admin.
>
> So you are saying a user namespace has to be set up to contain the defect.
>
> Really no application should have cap_sys_admin.
>
> The theory of capabilities is that security should be broken down into
> logical blocks.
>
> 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_SYS_ADMIN.

So you can create a new CAP_SYS_TIOCSSTI if you like, and offer a patch where
*both* CAP_SYS_ADMIN and CAP_SYS_ADMIN suffice. Again, see CAP_SYSLOG for a
prior example.

What you may not do is change it so that on an older kernel you must have
CAP_SYS_ADMIN to use TIOCSTI, while on a newer one it does not suffice.

-serge

\
 
 \ /
  Last update: 2017-05-30 17:52    [W:0.088 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site