Re: security.bsd.see_other_uids for jails

On Sun, May 28, 2006 at 03:46:06PM +0200, Anatoli Klassen wrote:
if security.bsd.see_other_uids is set to 0, users from the main system
can still see processes from jails if they have (by accident) the save uid.

For me it's wrong behavior because the main system and the jail are two
different systems where uids are independent.

You could try the following (untested) patch to the MAC seeotheruid
module. You'd need to compile a kernel with the MAC option and then:

kldload mac_seeotheruids
sysctl security.mac.seeotheruids.enabled=1
sysctl security.mac.seeotheruids.jail_match=1

and I think it will do what you want. The module is very simple, so
if it doesn't quite do what you want, then you may be able to tweak
it to get what you want.

David.


Index: sys/security/mac_seeotheruids/mac_seeotheruids.c
===================================================================
RCS file: /cvs/FreeBSD-CVS/src/sys/security/mac_seeotheruids/mac_seeotheruids.c,v
retrieving revision 1.8
diff -u -r1.8 mac_seeotheruids.c
--- sys/security/mac_seeotheruids/mac_seeotheruids.c 30 Sep 2005 23:41:10 -0000 1.8
+++ sys/security/mac_seeotheruids/mac_seeotheruids.c 28 May 2006 14:57:24 -0000
@@ -105,6 +105,29 @@
SYSCTL_INT(_security_mac_seeotheruids, OID_AUTO, specificgid, CTLFLAG_RW,
&specificgid, 0, "Specific gid to be exempt from seeotheruids policy");

+/*
+ * Restriction: Unprivileged users outside jail cannot see jailed processes,
+ * unprivileged users in a jail can only see processes in the same jail.
+ */
+static int jail_match = 0;
+SYSCTL_INT(_security_mac_seeotheruids, OID_AUTO, jail_match,
+ CTLFLAG_RW, &jail_match, 0, "Allow access only when in the same jail");
+
+static int
+mac_seeotheruids_prison_check(struct ucred *u1, struct ucred *u2) {
+
+ if (!jail_match)
+ return (0);
+
+ if (u1->cr_prison == NULL && u2->cr_prison == NULL)
+ return (0);
+
+ if (u1->cr_prison != NULL && u1->cr_prison == u2->cr_prison)
+ return (0);
+
+ return (ESRCH);
+}
+
static int
mac_seeotheruids_check(struct ucred *u1, struct ucred *u2)
{
@@ -113,7 +136,8 @@
return (0);

if (primarygroup_enabled) {
- if (u1->cr_rgid == u2->cr_rgid)
+ if (u1->cr_rgid == u2->cr_rgid &&
+ mac_seeotheruids_prison_check(u1, u2) == 0)
return (0);
}

@@ -122,7 +146,8 @@
return (0);
}

- if (u1->cr_ruid == u2->cr_ruid)
+ if (u1->cr_ruid == u2->cr_ruid &&
+ mac_seeotheruids_prison_check(u1, u2) == 0)
return (0);

if (suser_privileged) {
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: security.bsd.see_other_uids for jails
    ... if security.bsd.see_other_uids is set to 0, users from the main system can still see processes from jails if they have (by accident) the save uid. ... For me it's wrong behavior because the main system and the jail are two different systems where uids are independent. ... E.g. "users" from the outer system can ptrace the processes in ...
    (freebsd-hackers)
  • Re: security.bsd.see_other_uids for jails
    ... can still see processes from jails if they have (by accident) the save uid. ... For me it's wrong behavior because the main system and the jail are two ... E.g. "users" from the outer system can ptrace the processes in ...
    (freebsd-hackers)
  • Re: OpenSSH Security (just a question, please no f-war)
    ... > Which reminds me that we should really tweak the code and put it in a ... > jail instead of a chroot. ... to be distinct from any other UID on the system. ...
    (FreeBSD-Security)
  • Re: OpenSSH Security (just a question, please no f-war)
    ... > Which reminds me that we should really tweak the code and put it in a ... > jail instead of a chroot. ... to be distinct from any other UID on the system. ...
    (FreeBSD-Security)
  • Re: security.bsd.see_other_uids for jails
    ... still see processes from jails if they have the save uid. ... But my question is if it's really intended that jail is not real virtual system but just a way to limit interaction from jail to host and not vice versa. ... It is more precise to think of jail as a subsetting service than a virtualizing service: processes in jails see a subset of the system resources, ... This means that applications in the "host" environment overlap with the jail environments by virtue of also having access to that subset, as they can directly name files in the file system subset, IP and port bindings, processes, and so on. ...
    (freebsd-hackers)