[gentoo-hardened] Newbee alarm....

[gentoo-hardened] Newbee alarm....

[Nico Baggus]

Well.. at least is nice to introduce one-self.

Hi, I am a self-employed OpenVMS Cluster/systems manager by profession and run some linux on the side.

I am new to selinux on gentoo although I run Gentoo for some years now after migrating from some Slackware based mess, through Redhat (until 9), and felt at home with gentoo.

I started using hardened recently and found quite some messages in the audit log... enough to not warrent moving to enforcing.

I'll post some findings after this.
--
Nico Baggus

Re: [gentoo-hardened] Newbee alarm....

[Matt Thode]

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

Looking at all of them I'd like to talk a bit about it, have you installed the plugins?  Having the audit logs attached would help and knowing why you need the additions too.
Join #gentoo-hardened to talk?

-- Matthew Thode

On Nov 2, 2011, at 7:22 PM, Nico Baggus wrote:

> Well.. at least is nice to introduce one-self.
> 
> Hi, I am a self-employed OpenVMS Cluster/systems manager by profession and run some linux on the side.
> 
> I am new to selinux on gentoo although I run Gentoo for some years now after migrating from some Slackware based mess, through Redhat (until 9), and felt at home with gentoo.
> 
> I started using hardened recently and found quite some messages in the audit log... enough to not warrent moving to enforcing.
> 
> I'll post some findings after this.
> --
> Nico Baggus
> 
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 881 bytes --]

Re: [gentoo-hardened] Newbee alarm....

[Nico Baggus]

Matthew,

I tried to join the #gentoo-hardend, I can see messages but get a 404 response one sending something.
I am Noci there ...

Re: [gentoo-hardened] Newbee alarm....

[Francisco Blas Izquierdo Riera (klondike)]

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

Hi Nico,

First of all don't get me wrong, read this assuming I have a big smile
in my face: I also have been a newbie and over all, its not everyday you
find somebody wanting to give a hand on the project.

First regarding your e-mails, strange as it may seem it would be more
helpful if you could have sent all of them in a huge e-mail, this list
usually has low traffic and receiving 10 threads on the same topic is
very likely to upset somebody (not me though, I receive more e-mail from
gentoo-user anyway).

Also, please do open bugs when suggesting policy improvements or fixes
it makes it way easier for the team to review and read your proposals
and makes us less likely to forget about them (try to find this e-mails
in two months from now and try to find a bug and you'll understand what
I mean).

As an extra I want to invite you too to #gentoo-hardened as a first
resort for help. We don't bite, even less to newbies... unless you allow
us to, that is :P

Finally I'd like to point you to the cool SELinux handbook made by Swift
just in case you don't know about it:
http://www.gentoo.org/proj/en/hardened/selinux/selinux-handbook.xml

Take care :D

klondike


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-hardened] Newbee alarm....

[Sven Vermeulen]

On Thu, Nov 03, 2011 at 01:22:40AM +0100, Nico Baggus wrote:
> Well.. at least is nice to introduce one-self.
> 
> Hi, I am a self-employed OpenVMS Cluster/systems manager by profession and
> run some linux on the side.
> 
> I am new to selinux on gentoo although I run Gentoo for some years now 
> after migrating from some Slackware based mess, through Redhat (until 9),
> and felt at home with gentoo.
> 
> I started using hardened recently and found quite some messages in the 
> audit log... enough to not warrent moving to enforcing.
> 
> I'll post some findings after this.

Hi Nico,

Welcome in the world of Security Enhanced Linux. I am very glad to see you
are trying to get it working, and I can promise you that it will be a
challenging road. SELinux is a Mandatory Access Control system that is very
flexible, yet also very cumbersome and detailed. 

Now, in your other mails you are focusing on the AVC logs that you got from
running in permissive mode. That is fine, but will also cloud your view on
what you need and what you see. After all, there could be AVC denials that
are cosmetic (you should ignore them).

But the most difficult part you'll notice is to "read" these AVC denials. It
is not sufficient to just run audit2allow against them all and hope for the
best. If you do that, your system might work for a while, but you could have
opened up privileges that shouldn't be there in the first place.

For that reason, it is *very* *important* to look at each denial by itself,
figure out what is happening here, look for related denials and only /then/
on how to resolve it.

For instance, look at the following denials (I picked two from a whole bunch
since those two are related):

{ create } comm="mkdir" name=".test.1390"
scontext=system_u:system_r:initrc_t
tcontext=system_u:object_r:var_log_t tclass=dir  

{ rmdir } comm="rmdir" name=".test.1390" dev=vda4 ino=16285
scontext=system_u:system_r:initrc_t tcontext=system_u:object_r:var_log_t
tclass=dir

You can imagine them being related since they both work on the same object
(a directory called ".test.1390"). Also, because of the name syntax, it is
probably created using mktemp or so. And since the context of the directory
is var_log_t, it is easily deducable that it is in /var/log.

As it turns out, these rules are triggered by /etc/init.d/bootmisc (hence
the source context of initrc_t) which tests to see if it can write to a
directory (/var/log). Although I can think this is a wrong approach here
(after all, the bootmisc script doesn't seem to create directories in
/var/log, only files like /var/log/dmesg) it is something that is a "valid"
situation.

Resolving this can be done in three ways (well, there are probably more)

(1.) Have bootmisc updated so that /var/log isn't "tested" with the
     "dir_writeable" check, but with a proper file create check
(2.) Have initrc_t enhanced so that it can create initrc_var_log_t labeled
     directories, and give it the proper privileges to create such directories
(3.) Give initrc_t the manage privileges for var_log_t directories (which is
     somewhat what would happen if we throw audit2allow against the lines)

These are also in order of preference. As you can see, (3.) is last (but
easiest).

For each denial we get, we need to perform a similar analysis. Just pointing
out which denials we get isn't enough (but it is a start). Showing the
audit2allow "fixes" doesn't help us with anything though :-( They are meant
as a resolution, but since we do not know the problem we can't just accept
that.

For many denials, I personally also require that they are reproduced when
running in enforcing mode. Initially, that might not be possible on your
system so we first need to focus then on the denials that are "more
obvious".

If you ever want to try out enforcing mode, just boot in permissive, log in
as root and ensure that "id -Z" returns something like
"root:sysadm_r:sysadm_t", and *not* kernel_t, initrc_t, locallogin_t or
anything else. Only when your context is sysadm_t, then you can run
"setenforce 1" to switch to enforcing mode.

Keep that terminal logged on, work around a bit. If you get stuck, switch
back to the terminal, type in "setenforce 0" and you are back in permissive.

Wkr,
	Sven Vermeulen

Re: [gentoo-hardened] Newbee alarm....

[Anthony G. Basile]

On 11/02/2011 09:56 PM, Francisco Blas Izquierdo Riera (klondike) wrote:
> Hi Nico,
> 
> Also, please do open bugs when suggesting policy improvements or fixes

https://bugs.gentoo.org/

search for your bug first - comment that you also hit the bug if it is
the same as yours.

file under "Gentoo Linux"

component: hardened

Summary: one line beginning with <cat>/<pkg>

eg. sec-policy/selinux-nagios-2.20110726-r1: audit messages indicate
that checkdisk_plugin has problems

Description: longer version of summary, also cut and paste the output
from "emerge --info"

Steps to reproduce: command lines if possible


We forget emails quickly.  We are reminded of bugs each time we search
for bugs assigned to us.


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 8040 5A4D 8709 21B1 1A88  33CE 979C AF40 D045 5535
GnuPG ID  : D0455535