permission problem in /etc
 

Hello,
While troubleshooting my server in enforcing mode, I have come
across many files and directory in /etc which are not labelled and thus, I
am getting permission denied while using the root account:

johnson ~ # ls -Z /etc/ | grep "(null)"
ls: cannot access /etc/rsyncd.conf: Permission denied
ls: cannot access /etc/env.d: Permission denied
ls: cannot access /etc/make.conf: Permission denied
ls: cannot access /etc/shadow: Permission denied
ls: cannot access /etc/gshadow: Permission denied
ls: cannot access /etc/lilo.conf.example: Permission denied
ls: cannot access /etc/lilo.conf: Permission denied
ls: cannot access /etc/audit: Permission denied
ls: cannot access /etc/lilo.conf_example: Permission denied
ls: cannot access /etc/portage: Permission denied
ls: cannot access /etc/bind: Permission denied
ls: cannot access /etc/shadow-: Permission denied
ls: cannot access /etc/gshadow-: Permission denied
ls: cannot access /etc/mail: Permission denied
ls: cannot access /etc/dovecot: Permission denied
ls: cannot access /etc/postfix: Permission denied
ls: cannot access /etc/crontab: Permission denied
ls: cannot access /etc/cron.d: Permission denied
ls: cannot access /etc/fetchmailrc: Permission denied
ls: cannot access /etc/samba: Permission denied
ls: cannot access /etc/adjtime: Permission denied

all of these directory and files are not labelled as demonstrated below for
a particular set of daemon.

(null) samba
(null) dovecot
(null) bind

I have tried running the application rlpkg -a -r without success and also, I
have tried the command chcon but it won't let me relabel those directory
(while in enforcing mode). Is there any ways to fix that?

Thanks
Alain Toussaint

permission problem in /etc
 

On Sun, 19 Feb 2012 16:18:12 -0500
"Alain Toussaint" <alain.toussaint@securivm.ca> wrote:

> which are not labelled and thus, I
> am getting permission denied while using the root account:
>
> johnson ~ # ls -Z /etc/ | grep "(null)"
> ls: cannot access /etc/rsyncd.conf: Permission denied

What is the output of 'id -Z'

--
Matthew Thode (prometheanfire)

permission problem in /etc
 

On Sun, Feb 19, 2012 at 04:18:12PM -0500, Alain Toussaint wrote:
> While troubleshooting my server in enforcing mode, I have come
> across many files and directory in /etc which are not labelled and thus, I
> am getting permission denied while using the root account:
[...]

Using rlpkg -a -r should work, but only as long as the domain you run in has
the privileges to relabel to begin with. Most of the time, if no label is
set, it means that the system was once set up without SELinux running and
"rlpkg -a -r" hasn't been ran since.

My best bet here would be to boot in permissive mode, relabel the system,
and then reboot in enforcing again.

Wkr,
Sven Vermeulen

permission problem in /etc
 

> What is the output of 'id -Z'

johnson ~ # id -Z
root:staff_r:staff_t:s0-s0:c0.c1023

Alain

permission problem in /etc
 

<<<<<<<
Using rlpkg -a -r should work, but only as long as the domain you run in has
the privileges to relabel to begin with. Most of the time, if no label is
set, it means that the system was once set up without SELinux running and
"rlpkg -a -r" hasn't been ran since.

My best bet here would be to boot in permissive mode, relabel the system,
and then reboot in enforcing again.
>>>>>>

I did that. I rebooted into permissive mode, ran rlpkg -a -r and rebooted
into enforcing mode. The result were the same under root and I've tried with
my sysadm_r user but in the sysadm_r user, I could see all the permission in
/etc but trying to start some dovecot failed because dovecot didn't had
permission to access the /etc/dovecot directory.

Alain

permission problem in /etc
 

On Sun, Feb 19, 2012 at 08:12:39PM -0500, Alain Toussaint wrote:
> I did that. I rebooted into permissive mode, ran rlpkg -a -r and rebooted
> into enforcing mode. The result were the same under root and I've tried with
> my sysadm_r user but in the sysadm_r user, I could see all the permission in
> /etc but trying to start some dovecot failed because dovecot didn't had
> permission to access the /etc/dovecot directory.

Aha, we're getting somewhere then.

You indeed need to be sysadm_r to view those (all) labels. The staff_r role
(and its affiliated domains) do not have the rights to view all these
labels. That is why you see all those "??" in the "ls -Z" output.

For dovecot, you'll need to check in which domain dovecot is running. There
is a dovecot domain (dovecot_t) but your system might not run it in that
domain properly. It is also possible that the policy is not up to date with
recent dovecot development (and then needs policy updates).

At first sight, I don't see the dovecot_t domain to be capable of doing much
with dovecot_etc_t if it is a directory:

allow dovecot_t dovecot_etc_t:file read_file_perms;

Wkr,
Sven Vermeulen

permission problem in /etc
 

Pardon me for the dumb question but I'm having a migraine and must prepare
for a midterm tomorrow;

> allow dovecot_t dovecot_etc_t:file read_file_perms;

How do I do that? :)

Alain

permission problem in /etc
 

On Mon, Feb 20, 2012 at 05:23:11PM -0500, Alain Toussaint wrote:
> Pardon me for the dumb question but I'm having a migraine and must prepare
> for a midterm tomorrow;
>
> > allow dovecot_t dovecot_etc_t:file read_file_perms;
>
> How do I do that? :)


Hmm either I forgot to reply, or the reply didn't reach my mailbox, so here
goes the answer ;-)

http://www.gentoo.org/proj/en/hardened/selinux-faq.xml#localpolicy

In short, you'll need to create a policy file, build it and include it in
the system. The policy will be inserted in the policy store so that it is
loaded every time you (re)boot the system, so you can remove the source file
if you want.

Usually you don't want to though. I personally have a single
"localpolicy.te" file in which I put all my exceptional rules (that don't
need to be part of the main policy, but are necessary on my system) and
maintain that file.

Wkr,
Sven Vermeulen

permission problem in /etc
 

> > Pardon me for the dumb question but I'm having a migraine and must
> prepare
> > for a midterm tomorrow;
> >
> > > allow dovecot_t dovecot_etc_t:file read_file_perms;
> >
> > How do I do that? :)
>
>
> Hmm either I forgot to reply, or the reply didn't reach my mailbox, so
> here
> goes the answer ;-)
>
> http://www.gentoo.org/proj/en/hardened/selinux-faq.xml#localpolicy
>
> In short, you'll need to create a policy file, build it and include it
in
> the system. The policy will be inserted in the policy store so that it
is
> loaded every time you (re)boot the system, so you can remove the source
> file
> if you want.
>
> Usually you don't want to though. I personally have a single
> "localpolicy.te" file in which I put all my exceptional rules (that
don't
> need to be part of the main policy, but are necessary on my system) and
> maintain that file.

In the end, this is no longer apropos (for now) because I transferred all
my mail setup to google apps for business but I got a new spare computer
which I will use for R&D of a numbers of projects including developing
policy files for selinux.

Do you have some project for which I could help develop policy files? This
will be a good way for me to learn selinux.

Alain

permission problem in /etc
 

On Mon, Mar 12, 2012 at 08:15:50PM -0400, Alain Toussaint wrote:
> In the end, this is no longer apropos (for now) because I transferred all
> my mail setup to google apps for business but I got a new spare computer
> which I will use for R&D of a numbers of projects including developing
> policy files for selinux.
>
> Do you have some project for which I could help develop policy files? This
> will be a good way for me to learn selinux.

Developing policies isn't a good way to start learning SELinux. It is about
using, finding out in which logs files to find information, and what the log
entries tell you.

Understanding SELinux and its denials is needed before you can build
policies. Otherwise your policy will most likely not pass the mustard...

But I'm not going to stop you from contributing if you want ;-) On our
bugzilla, there is a requests for a policy for miniupnpd. But there are
probably other applications or services that we offer that still do not have
a proper policy with it (after all, we have about 230 policy modules whereas
there are several thousand packages in our tree...

Wkr,
Sven Vermeulen