This might be a short tutorial in my case, but I'm currently writing a book on setting up your own servers (FTP, HTTP, DNS, BitTorrent, CVS, etc) and during the process, I sometimes get the urge to splurt out some things, because I get annoyed when I see "bad suggestions".

This book has no expected date, I'm not a technical writer, so it may take a lot longer than expected, I am not offering parts of it till it is finished and has been thoroughly tested, sorry for that, but I will provide tutorials that I feel are important to not have quick answers for, thank you

First I'll explain SELinux (Security Enhanced Linux, does the name say it all?) is as it's name says an enhancement to Linux (what is Linux?) Linux is the kernel, so we can say, SELinux is an enhancment to the kernel. Others says it is a piece of .... because it makes it hard to configure, is there really a fine line between ease of use and security?

Basically it provides additional (annoyances) security measures, which implement DAC (Discretionary Access Control) and RBAC (Role-Based Access Control).

Tip: If you don't use SELinux then the commands like chcon will not apply to you but the rest will.

Now I guess you want me to explain DAC and RBAC, that's ok, it's making this longer than I expected so...

So why is DAC so annoying, well the annoyance that people encounter and one of the things we must fix to get UserDir permissions working is because of DAC (and I don't mean the green stuff that burns in pipes, although if anyone is offering a mellowpuff (this biscuit!)). The method relies on files and resources explicitly being told who's allowed and not allowed access (but isn't this normal User Permission settings, yes it is with a twist), It works with the permissions set, the user:group of that file, the user (mentioned again as object), the object (as an object) and the type (as an object, not! as what the object is part of but what the object actually represents in terms of it's type of content we should expect).

So lets say you, being user1 create a file in your home directory /home/user1 called yeah_and.txt. Now since you created this file, you've got full rights over it, being the owner right, saving it in your own home directory right, yes that wasn't a trick question because you do have full rights of what a TXT file needs going by permissions, read and write access but not execute, so while it's not full full access it's enough access to work with that file (chmod 664). Then you have permissions being the owner and in your group, usually the same name as the owner. And least but not last (did he really say it backwards?, I think I need a mellowpuff), there's these blimmin' objects, which determines whether you are the user of this object, that it's based on an object, and that the type of object will be functional with other programs who could access this object (e.g. a text editor), pretty much what policies are set up for this type.

Just follow my lead and you'll overcome it. For the owner implementing these DAC objects, it gives them control over who can access it, in more ways now (including doing more things), although those in higher authority already have the power, so powerful that not even DAC tries to get in their way, but DAC does set the same rules as if they were users, but the rules are special. So don't worry, they get treated the same too, but they aren't likely to be denied whatever they choose to do, you will be.

OK so now that I spent ages going on about DAC, what about RBAC, well that'll have to wait after my smoke (15 mins later...)

OK well lets not speak much on RBAC, it's similar to DAC, the thing is, it's based on your level of authority, imagine you had those people who knew what they were doing, they sometimes go by the name of the Administrators, well being high up, they deserve quite a lot of privileges, now say you have a user, who's known as The Janitor, now why would we give the Janitor the same privileges as the Administrators, we don't, we limit him to what access he needs and this is RBAC, it limits your access by who you are, if you're the CEO, we're not going to give you full access are we? We sometimes know that even if they are that high (and not CEO of some form of computer company) then we aren't giving them full access, because we do not like restoring from backups every 10 minutes right?

So we are given these policies, SELinux wouldn't have taken off if users had no clue on how to configure it, since you had to work with the program access as well as user access, so the nice people over at Red Hat, took the trouble out of it by coming up with preconfigured policies, enough to make the riotting stop, except for Apache, who was severely SELinux-ified, that the simple task of actually getting Apache to accept UserDir was now a trial and error cry for those who don't RTFM or in this case Read The Configuration Comments, because it's right above where you were editting, some handy dandy, clues.

So I think I've bored people enough, and I am a bit late with finishing this up, so lets get down to business.

This is the important part to this, the above is just for reasoning.

First of all, I hope you've got Apache installed, if not



Test to see if it's running by opening your web browser and typing http://localhost/

Now you've got apache installed, now we want to work out where we want our user directory, this is easy as long as you're not root at the time.

We want it at $HOME/public_html or /home/`whoami`/public_html, (nothing beats console!!!) and if you're not getting me, then in a way that doesn't work with console, /home/<username>/public_html, where you replace <username> with your username.

OK so lets use console make those directories and set permissions, well lets leave the configuring apache till the end and do everything we can do now.



Now you can use whatever text editor you want, I'm using vi, as I've got minimal things on my server, just the basics pretty much.

So here we need to look for UserDir which most likely is disabled, so we enable it by making sure we've loaded the module with:

LoadModule userdir_module modules/mod_userdir.so

When then look for <IfModule mod_userdir.c>, that's if it exists if not then just underneath DocumentRoot and LocationMatch we will put it.

<IfModule mod_userdir.c>
# If you want to enable a lot of users, either add them to UserDir enabled or change UserDir "disable" to UserDir disabled root ... and any other users you wouldn't allow.
UserDir "disable"
UserDir enabled yourusername goes here
UserDir public_html
</IfModule>

OK, now at the very bottom of the page, we got one last thing to add.

<Directory "/home/*/public_html">
Options Indexes SymLinksIfOwnerMatch IncludesNoExec
AllowOverride FileInfo AuthConfig Limit
</Directory>

And that's it, all configured, now to just restart our server and test it out.



If it works, I am done, if it doesn't, I'm am done for.

Cheers,

MC

Cool...
For more info on SELinux have a look here http://www.gentoo.org/proj/en/hardened/selinux/
its designed around Gentoo, but has alot of usefull information than could be applied to any distro.

Apache on Fedora core 3 PLEASE HELP
Configuring Apache On Fedora Core 3 For Userdir

I am having a configuration issue I am sure, but I can not find my error. My document root is var/www/html. I do have an html page there. I went to the welcome.Conf file in the etc/httpd/confd folder and remmed out as the file suggested. I continue to get the test page. For some reason it will not bring in the HTML page in the document root when I type in either the URL from another pc, or localhost on the server.

Any ideas on what I should check...

Oh yea, I am obviously a rookie...

THanks for your help!

-question by Robert Johnes