Working out subject /bin/passwd policy (the nesting of which failed)

Submit your RBAC policies or suggest policy improvements

Working out subject /bin/passwd policy (the nesting of which failed)

Postby timbgo » Sun Aug 14, 2016 9:38 am

title: Working out subject /bin/passwd policy (the nesting of which failed)
---
I'm into figuring out Gentoo useflags "caps" and "filecaps", which I need for:
Use Tor browser on grsecurity-hardened system?
viewtopic.php?f=3&t=4524
( I have an issue there with, "file capabilities" which, for now, cost me disabling the "GRKERNSEC_KMEM", when installing Qemu.)
and at first (wasn't careful when looking it up) the binary /bin/passwd looked a fine piece of runtime Gentoo "caps" flag in action to explore (which I later found it wasn't), but...
(Just to mention here that the passwd program had probably worked, but the kernel and much around it changes fast, and today I found it didn't anymore.)
Code: Select all
$ passwd
Changing password for miro
Old password:
passwd: failed to crypt password with previous salt: Invalid argument
The password for miro is unchanged.

...[but] I can't get it to work yet.
That failed not because I didn't type the correct password. But...:
Code: Select all
Aug 14 07:41:09 g0n kernel: [224107.885312] grsec: (miro:U:/) exec of /bin/passwd (passwd ) by /bin/passwd[bash:12318] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:5888] uid/euid:1000/1000 gid/egid:1000/1000
Aug 14 07:41:09 g0n kernel: [224107.889964] grsec: (miro:U:/) denied access to hidden file /etc/shadow by /bin/passwd[passwd:12318] uid/euid:1000/0 gid/egid:1000/1000, parent /bin/bash[bash:5888] uid/euid:1000/1000 gid/egid:1000/1000
Aug 14 07:41:18 g0n kernel: [224116.491017] grsec: (miro:U:/) denied access to hidden file /dev/log by /bin/passwd[passwd:12318] uid/euid:1000/0 gid/egid:1000/1000, parent /bin/bash[bash:5888] uid/euid:1000/1000 gid/egid:1000/1000

...[but] because probably some policies are not right in my /etc/grsec/policy.

How do I fix this? I know I can set it to learning by adding:
Code: Select all
# Role: miro
subject /bin/passwd ol {
   /            h
   -CAPS_ALL
   bind   disabled
   connect   disabled
}

but would this do the work?:
Code: Select all
# Role: miro
subject /bin/bash:/bin/passwd o {
   /            h
   /etc/shadow      rw
   /dev/log      w
   -CAP_ALL
   bind   disabled
   connect   disabled
}


That just would not work for some reason. I was following the example that
I'll paste literally, from the Gentoo's (finally updated!)...:
Code: Select all
# equery l gradm
 * Searching for gradm ...
[IP-] [  ] sys-apps/gradm-3.1.201607172312:0

...[from] recent gradm, the vanilla /etc/gradm/policy has these lines. Here they are:
Code: Select all
# Nested subjects
# subject /bin/su:/bin/bash:/bin/cat
#     / rwx
#     +CAP_ALL
# grant privilege to specific processes if they are executed
# within a trusted path.  In this case, privilege is
# granted if /bin/cat is executed from /bin/bash, which is
# executed from /bin/su.
#
# Configuration inheritance on nested subjects
# nested subjects inherit rules from their parents.  In the
# example above, the nested subject would inherit rules
# from the nested subject for /bin/su:/bin/bash,
# and the subject /bin/su
# View the 1.9.x documentation for more information on
# configuration inheritance


But I kept getting errors like:
Code: Select all
No object /bin/passwd found for nested subject /bin/bash:/bin/passwd
 specified on line 5003 of /etc/grsec/policy.


So I try:
Code: Select all
# Role: miro
subject /bin/passwd
   /            h
   /etc/shadow      rw
   /dev/log      w
   -CAP_ALL
   bind   disabled
   connect   disabled

and here the terminal:
Code: Select all
$ passwd
Changing password for miro
Old password:
Incorrect password for miro.
The password for miro is unchanged.
$

but that is a lie there. The error/the real reason was again a different one:
Code: Select all
Aug 14 10:37:09 g0n kernel: [234668.390146] grsec: (miro:U:/bin/passwd) exec of /bin/passwd (passwd ) by /bin/passwd[bash:12855] uid/euid:1000/1000 gid/egid:1000/1000, parent /bin/bash[bash:5888] uid/euid:1000/1000 gid/egid:1000/1000
Aug 14 10:37:17 g0n kernel: [234675.498054] grsec: (miro:U:/bin/passwd) denied connect() to the unix domain socket /dev/log by /bin/passwd[passwd:12855] uid/euid:1000/0 gid/egid:1000/1000, parent /bin/bash[bash:5888] uid/euid:1000/1000 gid/egid:1000/1000

So what is missing is permission to connect to unix socket /dev/log .
It is a socket indeed:
Code: Select all
# file /dev/log
/dev/log: socket
#


So I'll try sticking after the line
Code: Select all
   connect   disabled

of the new subject, this line:
Code: Select all
   sock_allow_family unix

And it finally worked. Here the terminal:
Code: Select all
$ passwd
Changing password for miro
Old password:
Enter the new password (minimum of 5 characters)
Please use a combination of upper and lower case letters and numbers.
New password:
Re-enter new password:
They don't match; try again.
New password:
Bad password: it does not contain enough DIFFERENT characters.  Try again.
...[ I couldn't get out of here, so I repeated unmatching, too simple passwords ]
...
New password:
Bad password: too simple.  Try again.
The password for miro is unchanged.
$

But the point is, it worked.

I have questions, and queries left after having done this.

1) Why did the nesting of subjects not work when I tried it above?

2) The reference in the vanilla /etc/grsec/policy that ships with the gradm
package is to:
Code: Select all
# View the 1.9.x documentation for more information on
# configuration inheritance

Misleading. Because the current package is gradm-3.1.201607172312 ... But it's not so important, I guess. After all, e.g. when we read about things and, say, kernel 2.6 is mentioned in /usr/src/linux/Documentation, it is often meant what has been applied first in 2.6, and remains applied in all greated version kernels...

But within gradm package, there is no documentation on nesting, other than what I pasted above.

(When I find time, I'll try and read about it, probably on https://en.wikibooks.org/wiki/Grsecurity, or on the Forums, but now I have to go back to getting me a useable Tor browser in a grsec-hardened system... Apparently only through virtual machines...)

3) If anyone knows or can suggest how this could have been done better, or if anything was wrongly done, go ahead. I'm still struggling with gradm.

---
What a relic from the past that passwd program is, though!
Code: Select all
# ls -l /bin/passwd
-rws--x--x 1 root root 71776 2015-11-23 00:42 /bin/passwd
#

(and I sure was wrong when I thought it had capabilities applied, see the "s"
in the "-rws--x--x" above?)

Read the new concept of linux capabilities (they get applied runtime with "caps" flag, or get set to files with "filecaps" flag in Gentoo, and, sure, in various other ways typical of, and pertaining to, other distros) from its inventor Chris Friedhoff:
http://www.friedhoff.org/posixfilecaps.html

But don't foget, no don't forget to learn how somehow its implementation has left a non-grsecurity-hardened linux kernel pretty much a hackers' playground from:
False Boundaries and Arbitrary Code Execution
viewtopic.php?f=7&t=2522

---
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr
Try refute: rootkit hooks in kernel,
linux capabilities for intrusion? (Linus?)
timbgo
 
Posts: 295
Joined: Tue Apr 16, 2013 9:34 am

Return to RBAC policy development