[Reiko]

SELinux is great....when you can get it working right, lol. It's somewhat difficult to administer at first, but once you get the hang of it it's not too bad. There's way to make it fix itself, which 9/10 times is a safe thing to do and won't break things. but boy, that 1/10 when it does break stuff... hold on.

The nice thing w/ SELinux is you can set it to enforcing or permitting on the fly, so if something is broken, you can just set to permissive mode while troubleshooting the problem and it will continue logging the exception without actually impeding functionality. Be warned though, DISABLING SELinux (different from permissive mode) requires a FSCK and can take a long time since it has to go thru and analyze each. individual. file.

What about the actual policy administration? Is it troublesome?

I've seen so many systems that will allow a user to hop from a restricted role (HTTP daemon for example) to unconfined_u:unconfined_r:unconfined_t: s0 just by writing out an SSH public key to ~/.ssh/authorized_keys and logging in.

[roger_smith]

What about the actual policy administration? Is it troublesome?

I've seen so many systems that will allow a user to hop from a restricted role (HTTP daemon for example) to unconfined_u:unconfined_r:unconfined_t: s0 just by writing out an SSH public key to ~/.ssh/authorized_keys and logging in.

:-o That sounds wrong... I'll see if I can play with that and see what happens. Were those systems set to enforcing?

I'll break out some of my reference material and see what I can find about SELinux and brush up on it to see if we can explore that issue more.

[Reiko]

They were indeed set to enforcing. They're multi-user systems that are used for web hosting, like you'd see with CPanel, Directadmin, Plesk, etc. The user is allowed to write to his own home directory by DAC and SElinux, and his processes run as children of the HTTP server, so they inherit its role.

The attack scenario here would be a PHP/CGI shell writing the key out, then logging in to remove SEL (and other) restrictions.

[roger_smith]

They were indeed set to enforcing. They're multi-user systems that are used for web hosting, like you'd see with CPanel, Directadmin, Plesk, etc. The user is allowed to write to his own home directory by DAC and SElinux, and his processes run as children of the HTTP server, so they inherit its role.

The attack scenario here would be a PHP/CGI shell writing the key out, then logging in to remove SEL (and other) restrictions.

DSO PHP Handler? There's something that could be interesting and I'm glad you mentioned that since I'm about to embark on a research project involving SELinux and CPanel. If it was running DSO, meaning PHP and what not runs as user nobody, I could see that potentially causing issues! A very interesting scenario indeed, when I have some extra time later (stupid school and house chores!) I'm going to see if I can play w/ that more.

[Reiko]

SUPHP handler, I think. DSO would stop this cold because nobody (typically) either has no home (/nonexistent) or can't write to his home.

[roger_smith]

SUPHP handler, I think. DSO would stop this cold because nobody (typically) either has no home (/nonexistent) or can't write to his home.

Duh, you're right.

I'll try and kick a cpanel image and set it up to play w/ this tonight, I'm intrigued :-D

[Reiko]

Duh, you're right.

I'll try and kick a cpanel image and set it up to play w/ this tonight, I'm intrigued :-D

Have fun, and if possible let me know what you discovered ^^
Sorry for hijacking your beginners' thread by the way... maybe we should have another one for stuff like this?

[roger_smith]

Have fun, and if possible let me know what you discovered ^^
Sorry for hijacking your beginners' thread by the way... maybe we should have another one for stuff like this?

I'll keep you posted on anything I find.
As far as the hijack, not worries at all! You've got the gears turning now and what's the point of discussion if one can't be inspired, right? lol.

I'm cool w/ another thread on the topic too if ya like