Not that anyone would ever run in permissive mode but...

Not that anyone would ever run in permissive mode but...

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This patch is needed for sudo.

Also added setkeycreatecon, although this will not work the way the code
is currently.

Pam activity should probably be happening after setkeycreatecon and
setexeccon

But I am not sure how pam_keyinit should work here any ways.

Currently you loose access to your keying material when you su or sudo.

These things will not be labeled corectly as currently used.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAke/HrwACgkQrlYvE4MpobND4QCg4L9uaKuKhMxQwlhCBUY5icwT
wCkAoIzPvgXScs286cbO2g8RZG3WVWtN
=5+0w
-----END PGP SIGNATURE-----

[-- Attachment #2: sudo-1.6.9p13-selinux.patch --]
[-- Type: text/plain, Size: 741 bytes --]

diff -up sudo-1.6.9p13/selinux.c.selinux sudo-1.6.9p13/selinux.c
--- sudo-1.6.9p13/selinux.c.selinux	2008-02-20 12:00:48.000000000 -0500
+++ sudo-1.6.9p13/selinux.c	2008-02-22 13:34:08.000000000 -0500
@@ -314,9 +314,19 @@ selinux_exec(char *role, char *type, cha
 
     if (setexeccon(new_context)) {
 	warn("unable to set exec context to %s", new_context);
-	goto error;
+	if (security_getenforce() == 1) {
+		goto error;
+	}
     }
 
+    if (setkeycreatecon(new_context)) {
+	    warn("Error!  Unable to set key creation context to %s",
+		 new_context);
+	    if (security_getenforce() == 1) {
+		    goto error;
+	    }
+    } 
+
 #ifdef WITH_AUDIT
     if (send_audit_message(1, old_context, new_context, user_ttypath)) 
 	goto error;

[-- Attachment #3: sudo-1.6.9p13-selinux.patch.sig --]
[-- Type: application/octet-stream, Size: 72 bytes --]

RE: Not that anyone would ever run in permissive mode but...

[Todd Miller]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> This patch is needed for sudo.
> 
> Also added setkeycreatecon, although this will not work the way the
> code is currently.
> 
> Pam activity should probably be happening after setkeycreatecon and
> setexeccon
> 
> But I am not sure how pam_keyinit should work here any ways.
> 
> Currently you loose access to your keying material when you su or
> sudo. 
> 
> These things will not be labeled corectly as currently used.

Thanks, I've merged that into the sudo tree.  I think I understand
why setkeycreatecon and setexeccon ought to be called before PAM.

I am correct in believing that the tty does _not_ need to be relabeled
before calling PAM since the conversation function runs in the current
context?

 - todd


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Not that anyone would ever run in permissive mode but...

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Todd Miller wrote:
> Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> This patch is needed for sudo.
>>
>> Also added setkeycreatecon, although this will not work the way the
>> code is currently.
>>
>> Pam activity should probably be happening after setkeycreatecon and
>> setexeccon
>>
>> But I am not sure how pam_keyinit should work here any ways.
>>
>> Currently you loose access to your keying material when you su or
>> sudo. 
>>
>> These things will not be labeled corectly as currently used.
> 
> Thanks, I've merged that into the sudo tree.  I think I understand
> why setkeycreatecon and setexeccon ought to be called before PAM.
> 
> I am correct in believing that the tty does _not_ need to be relabeled
> before calling PAM since the conversation function runs in the current
> context?
> 
>  - todd
Yes the problem is there is no good solution to this.  Since in some
cases you want jobs to run in the current context and others you want
them in the users context.

Same problem as DAC though.

Should pam_session be run in UID 0 or in my UID.  No good answer.

pam_keyinit is removing the current keyring and creating a new one.  In
the login programs this is happing after pam_selinux open so they get a
keyring labeled user_t or staff_t.  But sudo closes these and opens one
labeled staff_sudo_t.  If the setkeycreate call happened before the
pam_session it would be webadm_t.  But fixing this here would help, but
su has the same problem, and su has no selinux awareness.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAke/NHwACgkQrlYvE4MpobOmKwCgwUlu3/ImJh6ib71naqOnCaS8
QtYAoJXiHksHBYUyKMsbcv0Ny3ArhoZD
=okAi
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.