Is make relabel suposed to be run from policy or or setfiles?

Is make relabel suposed to be run from policy or or setfiles?

[JW]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As per the instructions on http://www.nsa.gov/selinux/doc/readme.html section 16,  I rebooted into the selinux kernel, loged in as jw (who is the sysadmin, sysadm_r:sysadm_t) su'd to root (who,a ccording to the default selinux setup [which I did not change] is a 'common user', cd'd to /usr/src/selinux/policy and ran 'make relabel' with the following results:

ccs001:/usr/src/selinux/policy # make relabel
/usr/local/selinux/bin/setfiles file_contexts/file_contexts `mount | awk '/(ext[23]|reiserfs)/{print $3}'`
/usr/local/selinux/bin/setfiles:  Running on a SELinux kernel, using new system calls
/usr/local/selinux/bin/setfiles:  read 665 specifications
/usr/local/selinux/bin/setfiles:  invalid context system_u:object_r:inetd_var_log_t on line number 625
/usr/local/selinux/bin/setfiles:  invalid context system_u:object_r:inetd_var_log_t on line number 626
/usr/local/selinux/bin/setfiles:  invalid context system_u:object_r:inetd_var_log_t on line number 637
/usr/local/selinux/bin/setfiles:  invalid context system_u:object_r:inetd_var_log_t on line number 638
/usr/local/selinux/bin/setfiles:  invalid context system_u:object_r:initrc_runlevel_t on line number 654
/usr/local/selinux/bin/setfiles:  invalid context system_u:object_r:initrc_runlevel_t on line number 655
/usr/local/selinux/bin/setfiles:  invalid context system_u:object_r:initrc_runlevel_t on line number 668
/usr/local/selinux/bin/setfiles:  invalid context system_u:object_r:initrc_runlevel_t on line number 669
make: *** [relabel] Error 1
ccs001:/usr/src/selinux/policy #

I did notice the following in /var/log/warn:

Jul  8 19:48:18 ccs001 kernel:
Jul  8 19:48:18 ccs001 kernel: avc:  denied  { write } for  pid=759 exe=/bin/su path=/dev/log dev=08:03 ino=26755 scontext=jw:sysadm_r:sysadm_su_t tcontext=system_u:object_r:device_t tclass=sock_file
Jul  8 19:48:18 ccs001 kernel:
Jul  8 19:48:18 ccs001 kernel: avc:  denied  { sendto } for  pid=759 exe=/bin/su path=/dev/log scontext=jw:sysadm_r:sysadm_su_t tcontext=system_u:system_r:initrc_t tclass=unix_dgram_socket


I noticed a post from Russel suggested that make relabel should be run from selinux/setfiles/ not selinux/policy, but I'm not sure if that's correct or not.

ccs001:/usr/src/selinux/setfiles # make relabel
chcon system_u:object_r:setfiles_exec_t /usr/local/selinux/bin/setfiles
ccs001:/usr/src/selinux/setfiles #

Is that correct? Based on some discussion I had on IRC, I think it is NOT correct.
Perhaps someone could update the web page if it is correct.
I'll also point out that step 17 (PATH changes) have to occur before you can run make relabel, because use is made of /usr/local/selinux/chcon

Just out of curiosity, why do you have to be root to do that? I have no doubt that I've much to lera here :-) but considering that 'jw' is sysadm_* and 'root' is just user_*, I would think that jw would be the proper account to run make relabel under.


- -- 

- ----------------------------------------------------
Jonathan Wilson
System Administrator
Cedar Creek Software     http://www.cedarcreeksoftware.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9Kjl0Q5u80xXOLBcRAv2EAJ431gypUeAcKK8KZJS9JGutL+wFRACcCrgo
slqOJh1GOr5CDofyUUQJb84=
=4n1v
-----END PGP SIGNATURE-----


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Is make relabel suposed to be run from policy or or setfiles?

[JW]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


ES >Hello,
ES >
ES >What irc network/channel?

#selinux, irc.openprojects.net I'm there noe (23:00 CDT), will be there for an hour or more probably. Drop by :-)

ES >May want to try make -C /usr/share/Selinux/policy/current relabel first.

Ok, you are the second person that's said that - you must be a Ddebian user. I do not have a directory "current" under policy.

I have decided that policy is the correct place to run make relabel (someone correct me if I'm wrong), and the erorrs are genuine.

I can say one thing for sure, I'm going to have to do a _lot_ of tuning :-( there's errors and warnings at every turn.

Say, if this list moderated? It's very slow, posts I sent 6 hours ago are just now filtering in.
- -- 

- ----------------------------------------------------
Jonathan Wilson
System Administrator
Cedar Creek Software     http://www.cedarcreeksoftware.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD4DBQE9KmEUQ5u80xXOLBcRAnznAJixTh30nUkPYkQDhf8188GT75lRAJ9NJSWg
fHgQO35uokkt+m5xc0sX9w==
=zCmA
-----END PGP SIGNATURE-----


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

lsm3 notes

[Ed Street]

Hello,

Couple of things I noted about the new lsm3 

I keep seeing /dev/xconsole avc's. 

This is from startup
allow initrc_t device_t:fifo_file { setattr };
        #EXE=/bin/chmod  PATH=/dev/xconsole   :  setattr

startup as well
allow initrc_t resolv_conf_t:file { setattr };
        #EXE=/bin/chmod  PATH=/etc/resolv.conf   :  setattr


when I ssh into the box
allow sshd_t sysadm_home_t:dir { search };
        #EXE=/usr/sbin/sshd  PATH=/root   :  search

when sysklogd starts at boot
allow syslogd_t device_t:fifo_file { read write };
        #EXE=/sbin/syslogd  PATH=/dev/xconsole   :  read write

when I tried to tail syslog as user_r
allow user_t var_log_t:file { getattr read };
        #EXE=/bin/bash  PATH=/var/log/syslog   :  getattr
        #EXE=/usr/bin/tail  PATH=/var/log/syslog   :  read

Most notably problems with sysklogd, and it's not writing events to
/var/log/syslog

Ed


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Is make relabel suposed to be run from policy or or setfiles?

[Stephen Smalley]

On Mon, 8 Jul 2002, JW wrote:

> /usr/local/selinux/bin/setfiles:  invalid context system_u:object_r:inetd_var_log_t on line number 625
> /usr/local/selinux/bin/setfiles:  invalid context system_u:object_r:initrc_runlevel_t on line number 669

The types listed above are not defined in the upstream .te files nor are
they used in the upstream .fc files.  So I'll assume that you are using a
customized policy other than the example policy.  It would be helpful to
explicitly identify what policy you are using.  In any event, the error is
quite simple:  you are using types in your .fc files that are not defined
in your .te files.

> I noticed a post from Russel suggested that make relabel should be run from selinux/setfiles/ not selinux/policy, but I'm not sure
> if that's correct or not.

That changed in the May 2nd release.  Prior to that release, the file
contexts configuration lived in the setfiles directory separately from the
policy and you ran 'make relabel' in the setfiles directory.  Since that
release, the file contexts configuration has lived under the policy
directory and you perform the 'make relabel' in the policy directory.

> ccs001:/usr/src/selinux/setfiles # make relabel
> chcon system_u:object_r:setfiles_exec_t /usr/local/selinux/bin/setfiles
> ccs001:/usr/src/selinux/setfiles #

This is not the 'make relabel' that you want.  The 'relabel' targets in
the setfiles, selopt, and utils Makefiles are selective relabels of
specific programs installed by those Makefiles, as opposed to a full
relabeling of the entire filesystem.  These targets are a convenience when
installing new versions of these particular programs on an existing
SELinux system so that you can do a 'make install relabel' of these
programs and end up with a newly installed program with the right security
context.  They are separate from the base 'install' target since they will
not work on a non-SELinux kernel for an initial install of SELinux.

> I'll also point out that step 17 (PATH changes) have to occur before you
> can run make relabel, because use is made of /usr/local/selinux/chcon

Not a problem.  The 'make relabel' that you want doesn't use chcon.

> Just out of curiosity, why do you have to be root to do that? I have no doubt that I've much to lera here :-) but considering that 'jw' is sysadm_* and 'root' is just user_*, I would think that jw would be the
> proper account to run make relabel under.

You need to be root to create and/or update the persistent label mappings
(if running on a non-SELinux kernel) and to traverse the entire
filesystem (whether running on a non-SELinux kernel or a SELinux kernel).
You can login as a normal user initially, but you need to su to root.
When running on a SELinux kernel, you also need to be in sysadm_r.

Keep in mind that the SELinux access controls are orthogonal to the Linux
access controls, and that both access controls must authorize an operation
in order for it to be performed.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: lsm3 notes

[Stephen Smalley]

On Tue, 9 Jul 2002, Ed Street wrote:

> I keep seeing /dev/xconsole avc's.
> This is from startup
> allow initrc_t device_t:fifo_file { setattr };
>         #EXE=/bin/chmod  PATH=/dev/xconsole   :  setattr

/dev/xconsole doesn't exist on my systems.  Feel free to define an
appropriate type and submit a patch to types/device.te and
file_contexts/type.fc, along with a patch to whatever domains require
access.  What creates this FIFO?

> startup as well
> allow initrc_t resolv_conf_t:file { setattr };
>         #EXE=/bin/chmod  PATH=/etc/resolv.conf   :  setattr

Why are your rc scripts changing the mode on /etc/resolv.conf?
In any event, this is probably harmless.

> when I ssh into the box
> allow sshd_t sysadm_home_t:dir { search };
>         #EXE=/usr/sbin/sshd  PATH=/root   :  search

Do you really need to login directly as root?

> when I tried to tail syslog as user_r
> allow user_t var_log_t:file { getattr read };
>         #EXE=/bin/bash  PATH=/var/log/syslog   :  getattr
>         #EXE=/usr/bin/tail  PATH=/var/log/syslog   :  read

Do you really want to permit ordinary users to read your logs?

> Most notably problems with sysklogd, and it's not writing events to
> /var/log/syslog

Are klogd and syslogd running in the right domains?

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: lsm3 notes

[Ed Street]

Hello,

=> > I keep seeing /dev/xconsole avc's.
=> > This is from startup
=> > allow initrc_t device_t:fifo_file { setattr };
=> >         #EXE=/bin/chmod  PATH=/dev/xconsole   :  setattr
=> 
=> /dev/xconsole doesn't exist on my systems.  Feel free to define an
=> appropriate type and submit a patch to types/device.te and
=> file_contexts/type.fc, along with a patch to whatever domains require
=> access.  What creates this FIFO?

I'm not 100% sure why it's doing the file_fifo or the xconsole.  It does
warrant further investigation.

=> 
=> > startup as well
=> > allow initrc_t resolv_conf_t:file { setattr };
=> >         #EXE=/bin/chmod  PATH=/etc/resolv.conf   :  setattr
=> 
=> Why are your rc scripts changing the mode on /etc/resolv.conf?
=> In any event, this is probably harmless.

I think at load of services it's looking at /etc/resolv.conf for dns
issues but it eludes me as to why setattr is being issued.  Another good
reason for Selinux, is to see what linux is REALLY doing behind our
backs with out our knowing.

=> 
=> > when I ssh into the box
=> > allow sshd_t sysadm_home_t:dir { search };
=> >         #EXE=/usr/sbin/sshd  PATH=/root   :  search
=> 
=> Do you really need to login directly as root?

No I normally ssh in as a user and su to root.  I also noted that the
path is not being set correctly either.

=> 
=> > when I tried to tail syslog as user_r
=> > allow user_t var_log_t:file { getattr read };
=> >         #EXE=/bin/bash  PATH=/var/log/syslog   :  getattr
=> >         #EXE=/usr/bin/tail  PATH=/var/log/syslog   :  read
=> 
=> Do you really want to permit ordinary users to read your logs?

No, this can be ignored and I should have left it out.  Figured I would
see what it gave in this case.

=> 
=> > Most notably problems with sysklogd, and it's not writing events to
=> > /var/log/syslog
=> 
=> Are klogd and syslogd running in the right domains?

Yes klogd and syslogd is running correctly.  Seems that Selinux is
denying access to both on a restart.  I am in agreement they may not
have the correct label (same issue as raid devices )

IN any case this is definitely turning out to be a very fun project to
be working on.  It's proving some rather insightful views into linux.

Ed


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: lsm3 notes

[Stephen Smalley]

On Tue, 9 Jul 2002, Ed Street wrote:

> No I normally ssh in as a user and su to root.  I also noted that the
> path is not being set correctly either.

If you ssh in as a user, run newrole -r sysadm_r, and then su, you should
be fine.

The errors when directly logging in as root are a consequence of removing
direct transitions from sshd_t to sysadm_t and changing the default login
context for root to user_r.  sshd_t no longer has search access to
sysadm_home_t, so you'll see that denial, and the root shell will start
in user_r:user_t, so accesses to any of the /root files by the shell will
also be denied (including reading the root dotfiles, but these audit
messages are suppressed via dontaudit rules).  If you then use newrole -r
sysadm_r, you can work normally as root.  Hence, it is possible to
directly login as root if necessary, but you'll run through some nonfatal
denials.

> Yes klogd and syslogd is running correctly.  Seems that Selinux is
> denying access to both on a restart.  I am in agreement they may not
> have the correct label (same issue as raid devices )

If you mean restarting them from an administrator shell, you need to use
run_init to do that.  Otherwise, they'll end up with the wrong contexts.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com





--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Is make relabel suposed to be run from policy or or setfiles?

[JW]

On Tuesday 09 July 2002 06:49, you wrote:
> On Mon, 8 Jul 2002, JW wrote:
> > /usr/local/selinux/bin/setfiles:  invalid context
> > system_u:object_r:inetd_var_log_t on line number 625
> > /usr/local/selinux/bin/setfiles:  invalid context
> > system_u:object_r:initrc_runlevel_t on line number 669
>
> The types listed above are not defined in the upstream .te files nor are
> they used in the upstream .fc files.  So I'll assume that you are using a
> customized policy other than the example policy.  

Actually, no, at the time I was reciving those error messages, I was indeed using the default ploicy files, policy11.
I am running on SuSE 8.0 Most of those errors whent away when I added Carstens's additional policy files for SuSE. 

> In any event, the error is
> quite simple:  you are using types in your .fc files that are not defined
> in your .te files.

Ok, that is the information I was looking for.


> > Just out of curiosity, why do you have to be root to do that? 
>
 > You can login as a normal user initially, but you need to su to root.
> When running on a SELinux kernel, you also need to be in sysadm_r.

Presumeably you mean su and newrole. I haven't tried it yet, I will later.

> Keep in mind that the SELinux access controls are orthogonal to the Linux
> access controls, and that both access controls must authorize an operation
> in order for it to be performed.

Ok. I was under the impression (from things I read and heard), that root was pretty much reduced to a normal user, and the sysadm_* user became, in effect, root. 
But I'm still reading on the subject, hopefully there's something written about this in the documentation.

Thank you.

	JW



--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.