{"push_id":536774376,"size":1,"distinct_size":1,"ref":"refs/heads/cm-12.0_staging","head":"5384e1b9ddae08d4a387e6810e4224e671d71ca6","before":"4e423e0d392bec0d6e85e0468130979dd23df079","commits":[{"sha":"5384e1b9ddae08d4a387e6810e4224e671d71ca6","author":{"email":"60c228cf09e19acd74759f5c613924eab2745627@gmail.com","name":"Andy Lutomirski"},"message":"Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs\nWith this change, calling\n  prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)\ndisables privilege granting operations at execve-time.  For example, a\nprocess will not be able to execute a setuid binary to change their uid\nor gid if this bit is set.  The same is true for file capabilities.\n\nAdditionally, LSM_UNSAFE_NO_NEW_PRIVS is defined to ensure that\nLSMs respect the requested behavior.\n\nTo determine if the NO_NEW_PRIVS bit is set, a task may call\n  prctl(PR_GET_NO_NEW_PRIVS, 0, 0, 0, 0);\nIt returns 1 if set and 0 if it is not set. If any of the arguments are\nnon-zero, it will return -1 and set errno to -EINVAL.\n(PR_SET_NO_NEW_PRIVS behaves similarly.)\n\nThis functionality is desired for the proposed seccomp filter patch\nseries.  By using PR_SET_NO_NEW_PRIVS, it allows a task to modify the\nsystem call behavior for itself and its child tasks without being\nable to impact the behavior of a more privileged task.\n\nAnother potential use is making certain privileged operations\nunprivileged.  For example, chroot may be considered \"safe\" if it cannot\naffect privileged tasks.\n\nNote, this patch causes execve to fail when PR_SET_NO_NEW_PRIVS is\nset and AppArmor is in use.  It is fixed in a subsequent patch.\n\nSigned-off-by: Andy Lutomirski <luto@amacapital.net>\nSigned-off-by: Will Drewry <wad@chromium.org>\nAcked-by: Eric Paris <eparis@redhat.com>\n\nv18: updated change desc\nv17: using new define values as per 3.4","distinct":true,"url":"https://api.github.com/repos/Starship-Android/android_kernel_lge_hammerhead-starship/commits/5384e1b9ddae08d4a387e6810e4224e671d71ca6"}]}