On 05/16/2017 05:43 PM, Peter Dolding wrote:

On Wed, May 17, 2017 at 12:28 AM, Kees Cook [off-list ref] wrote:

quoted

On Tue, May 16, 2017 at 5:22 AM, Matt Brown [off-list ref] wrote:

quoted

On 05/16/2017 05:01 AM, Peter Dolding wrote:

quoted

quoted

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
and you openly admit you have.

This is not true that I'm openly going against what the documentation
instructs. The part of the email chain where I show this got removed
somehow. Again I will refer to the capabilities man page that you
quoted.

From http://man7.org/linux/man-pages/man7/capabilities.7.html

"Don't choose CAP_SYS_ADMIN if you can possibly avoid it!
...
The only new features that should be associated with CAP_SYS_ADMIN are
ones that closely match existing uses in that silo."

My feature affects the TIOCSTI ioctl. The TIOCSTI ioctl already falls
under CAP_SYS_ADMIN, therefore I actually *am* following the
documentation.

CAP_SYS_ADMIN is the right choice here, I agree with Matt: it is
already in use for TIOCSTI. We can't trivially add new capabilities
flags (see the various giant threads debating this, the most recently
that I remember from the kernel lock-down series related to Secure
Boot).

We cannot just keep on expanding CAP_SYS_ADMIN either.

quoted

quoted

quoted

I fact this usage of TIOCSTI I personally think should require two
capabilities flags set.   CAP_SYS_ADMIN section left as it is at this
stage.   With TIOSCTI stuck behind another capability.

If you had added a new capability flag you could set file capabilities
on any of the old applications depending on the now secured behaviour.

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?

Kees I like but you have forgot the all important rule.   The Linus
Rule.    Existing applications must  have a method work.
  So modify applications  binary is not way out of problem.

Please note making CAP_SYS_ADMIN the only way to use TIOCSTI also
means setting CAP_SYS_ADMIN on all the existing applications to obey
the Linus Rule of not break userspace.   So this is why the patch is
strictly no as this means elevating privilege of existing applications
and possibly opening up more security flaws.

This feature is not required so it is not "making CAP_SYS_ADMIN the
only way to use TIOCSTI". It defaults to no as to not break some
existing programs that use it.

Reality any patch like the one we are talking about due to the Linus
Rule and the security risk it will open up obey this it just be
rejected.   There is another kind of way I will cover with Serge.

Peter Dolding.

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