On 10/26/2010 04:05 PM, Bruno Wolff III wrote:
> On Tue, Oct 26, 2010 at 14:18:55 -0400,
> Przemek Klosowski<przemek.klosowski@nist.gov> wrote:
>>
>> Such user-differentiated authorization is provided by the filesystem
>> access rights, ACLs and SELinux attributes. Note that unlike the first
>> two mechanisms, SELinux can protect the data even for systems with
>> compromised root---as someone said, SELinux can be configured so that
>> you can tell people "here's the root password; now break into my computer".
>
> That's overstating things a bit. A root compromise is usually going to allow
> working around selinux limitations.

My point here is to distinguish between 'compromised root' and
'compromised overall system integrity'. Many (but not all) exploits are
of the first kind (get a root shell, or change your EUID to zero). Of
course the latter exploits can get around any security, as you say.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 26/10/10 22:24, Gregory Maxwell wrote:
> On Tue, Oct 26, 2010 at 4:10 PM, Bruno Wolff III<bruno@wolff.to> wrote:
>> This is where we should be going. Encryption is really irrelavent. The issue
>> should be if a removable device is inserted, who should have access to it
>> if it gets automounted. I would expect encrypted and unencrypted devices
>> to get the same treatment. The encrypted devices do already have a pop up,
>> so maybe that makes it not as much effort to ask a question when the device
>> is mounted. But I don't see otherwise why one would want to treat encrypted
>> and uncrypted removable devices differently.
>
> We don't know which of multiple users plugged the device in but we
> know which user provided the key to decrypt the device.
>
> The existence of encryption shows that the user may care more about
> the confidentiality of the data, and there is less of an previously
> existing "installed base" of expectations about how an encrypted
> volume works when you plug it in.

This is exactly it.

> If we wanted to get fancy (e.g. go beyond just a change in the default
> modes) additional users could authenticate themselves to an already
> mounted encrypted volume one at a time by providing the key.
>
> ::shrugs::

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 10/26/2010 10:39 PM, Bruno Wolff III wrote:
> On Tue, Oct 26, 2010 at 14:07:53 -0700,
> Jesse Keating <jkeating@redhat.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>>
>> That's only if you give root the right to disable or load new selinux
>> policy.
>
> And the policy is tight enough. You need to not allow root shells or most
> processes the ability to read the keys out of memory or to write memory
> that will change how things work. I don't think targeted policy is locked
> down enough to stop that even if you don't allow root to disble selinux.
>
>> Seriously, there are machines on the public Internet with a published
>> root account. You're welcome to log in and try to do anything with them.
>
> Yeah, I know about one guy that offers a root password if you ask. I am
> not sure what policy he is running on that machine.

It's Russell Coker, access details are available here:

http://www.coker.com.au/selinux/play.html

However the pages haven't been updated in a while and the service seems to be
down right now.

Regards,
Bryn.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

On 10/27/2010 06:35 AM, Bryn M. Reeves wrote:
> On 10/26/2010 10:39 PM, Bruno Wolff III wrote:
>> On Tue, Oct 26, 2010 at 14:07:53 -0700,
>> Jesse Keating <jkeating@redhat.com> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>
>>> That's only if you give root the right to disable or load new selinux
>>> policy.
>>
>> And the policy is tight enough. You need to not allow root shells or most
>> processes the ability to read the keys out of memory or to write memory
>> that will change how things work. I don't think targeted policy is locked
>> down enough to stop that even if you don't allow root to disble selinux.
>>
>>> Seriously, there are machines on the public Internet with a published
>>> root account. You're welcome to log in and try to do anything with them.
>>
>> Yeah, I know about one guy that offers a root password if you ask. I am
>> not sure what policy he is running on that machine.
>
> It's Russell Coker, access details are available here:
>
> http://www.coker.com.au/selinux/play.html
>
> However the pages haven't been updated in a while and the service seems to be
> down right now.
>
> Regards,
> Bryn.
There are two ways to get root on a system. One is through a login
process. Either login directly as root or login as a user and execute
su/sudo. SELinux by default since F9 and RHEL6 allows you to setup
confined users, but defaults to unconfined_t. If you login to a system
as a user and get unconfined_t user type, and you become root, you can
take over the system. You can setup the root account to login as any
confined user, and show a UID=0 account that can not do much.

SELinux also includes the concept of confined admin. You can setup
accounts that have limited privledged root access. webadm_r:webadm_t

http://magazine.redhat.com/2008/04/17/fedora-9-and-summit-preview-confining-the-user-with-selinux/

Explains this.

On my laptop I run as staff_t and when I run sudo I become webadm_t. If
I run runuser I become unconfined_t. This means you can setup a user
account that can use sudo to do certain admin activities with locked
down privs.

The other way you can become root is to break into the system through a
flaw in a network service. If you are running SELinux and break into
httpd, you would endup with a process labeled httpd_t, and would only be
allowed to do the things the web server is allowed to do, even if your
UID==0.

One caveat in this is, if there is a kernel flaw that allows a account
to manipulate memory in the kernel, the hacker has a chance to turn
SELinux enforcement off, and all bets are off. We try to protect
against this through checks like execmem,execstack,execmod,execheap and
memzero checks. Hopefully more in the future.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkzIJCcACgkQrlYvE4MpobM0TwCggJGaDwUnUr VFsuQa2YSk74X1
MUYAni2CkV2vu1IsUraYtu5W7MNTbsBq
=rLD7
-----END PGP SIGNATURE-----
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel