[ale] why I love windows

Jim Kinney jim.kinney at gmail.com
Tue Jan 31 13:03:57 EST 2012


On Tue, Jan 31, 2012 at 11:24 AM, mike at trausch.us <mike at trausch.us> wrote:

>
>
> Ultimately, I would like a system that enables me to do certain things
> without having to elevate my own privileges.  There is (to my knowledge)
> absolutely nothing to stop a program lurking in my userspace from
> starting up in the window system and watching for me to gain root access
> in a terminal window to do nasty things before I can stop it.
>
> But if I were allowed to “aptitude update && aptitude safe-upgrade” or
> “emerge --sync && emerge -DNua world” without invoking root privilege,
> by having helpers go and request that backends kick in and do their
> jobs, then I never have to run “sudo” or become root.  I can just type
> the commands and if I have the permission to run them, the backend will
> start up for me; if I do not have the permission to run them, the
> backend will return a permission denied error.  And all the while,
> nothing can lurk in my window system and try to take advantage of a root
> shell while it’s in a terminal window.
>
>        --- Mike
>
> I don't understand what the advantage is of totally blurring the line
between user and admin is. You can right now set up your non-root account
to do root-ish things with no further work other than typing the command.

The hard separation exists for a reason. It's better to learn the tool
chains available before embarking on a new project to reinvent the wheel.
SELinux and AppArmour are very similar in concept but different in
operation and practice. As you use Debian derivatives, learn AppArmour. If
you use RedHat derivatives, learn SELinux.

FYI: PolicyKit is a native part of RHEL. It's purpose is to handle the
process that allows a user with proper privileges to do gui-fied root-ish
things. It is tied in nicely with SELinux. My laptop runs in permissive
mode. My servers run in targeted mode. That means apache can read/write
ONLY apache directories (i.e. have the type httpd_sys_content_t. I can as
admin make any area of the filesystem have that type and apache will be
able to use that space. If I want to, I can dig way deep and allow
suexec_httpd to use particular spaces only and not be able to write to /tmp
or whatever. Targeted policy is pretty easy. MLS/MCS can be the total
brain-bender :-) Picture the following:

Each user has multiple level of security. Each level can "read down" and
"write up" a security level. A process called "polyinstantiation" was
created so that each user has multiple $HOME with different security
levels. There is a /tmp for each level in use AND it's tied to each user.
So it's a private /tmp that kernel space understands as normal /tmp when a
user app calls for an IO to /tmp. Each security level transition requires a
login. The entire chain of logins is tracked back to the originating login.
So a user can't use a local exploit to become root and then do anything
because the system knows the transition path.

Now add in MCS to further subdivide the system and processes into
compartments that can each have multiple levels. So Fred works on two
projects and at different levels on each. Each category can (and usually
does) require a complete login process (not su) so that polyinstantiation
wakes up and does it's job at each category and level.

Once you know how to read the audit logs, you can track a user through what
is done. By tricks such as dual logs and append-only partitions, a cracker
has nearly no chance to both "do bad things" AND cover the tracks.

I'll start working on the SELinux roadshow and holler when it's ready.

-- 
-- 
James P. Kinney III

As long as the general population is passive, apathetic, diverted to
consumerism or hatred of the vulnerable, then the powerful can do as they
please, and those who survive will be left to contemplate the outcome.
- *2011 Noam Chomsky

http://heretothereideas.blogspot.com/
*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20120131/96b230b6/attachment.html 


More information about the Ale mailing list