strange failure

strange failure

[Russell Coker]

I have the following in my policy:
allow devfsd_t domain:dir_file_class_set getattr;

But I get the following logged:
Mar 22 22:26:22 test kernel: avc:  denied  { getattr } for  pid=394 
exe=/sbin/devfsd path=/vc/2 dev=00:07 ino=20 
scontext=system_u:system_r:devfsd_t 
tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file

What am I missing?

I've tried this many times, read the macro expansion, reloaded the config and 
restarted the daemon etc.  I'm pretty sure that I haven't made the obvious 
mistakes of not saving the file or not loading the policy etc.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
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.

Mix and Match problems

[Dale Amon]

A question for Russ. In your debian package you still
have the original policy/README file. If you are 
trying to build an selinux using your policy Makefile
there is a catch-22. The README suggests building
and installing policy first; but your Makefile uses
chsid. chsid is not built until the next step when
you make and make install libsecure; and even then
it would not ordinarily be built as the original 
libsecure/test/Makefile suggests it is needed only 
if chcon is not present.

After going through that, I still got errors when
trying to use your make install. I'm going to 
presume that is due to the fact that I'm doing
a build under a non-selinux kernel and thus
chsid is missing something it needs.

This may all be moot, and I'm getting the problems
only because I'm mixing your policy with Stephen's
release, but thought I'd mention it in case it's
of any use.


--
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: Mix and Match problems

[Russell Coker]

On Sun, 24 Mar 2002 16:22, Dale Amon wrote:
> A question for Russ. In your debian package you still
> have the original policy/README file. If you are
> trying to build an selinux using your policy Makefile
> there is a catch-22. The README suggests building
> and installing policy first; but your Makefile uses
> chsid. chsid is not built until the next step when
> you make and make install libsecure; and even then

No.  If you use my packages then after installing the "selinux" package you 
have (for a new install) a copy of the sample policy files copied to 
/etc/selinux and chsid installed in /usr/bin/chsid.  It all works.

chsid should probably be in /usr/sbin though, but that's a minor issue.

> it would not ordinarily be built as the original
> libsecure/test/Makefile suggests it is needed only
> if chcon is not present.

That's fine, my debian/rules builds it anyway.  It has to be this way because 
the ability to change the SID of individual files is mandatory for the base 
SE Linux functionality.  Therefore my selinux package which is built from the 
selinux-small source archive MUST have the ability to do this.  As I'm forced 
to install chsid for this I haven't made chcon a priority, so there is still 
no Debian package of it.

> After going through that, I still got errors when
> trying to use your make install. I'm going to
> presume that is due to the fact that I'm doing
> a build under a non-selinux kernel and thus
> chsid is missing something it needs.
>
> This may all be moot, and I'm getting the problems
> only because I'm mixing your policy with Stephen's
> release, but thought I'd mention it in case it's
> of any use.

My makefiles etc are specifically designed for building packages of SE Linux. 
For Debian packages I have proven them to be workable, for RPM packages there 
should be no need for significant modification if you choose to have the same 
package contents as I have for Debian.  Otherwise it'll be problematic for 
you.

Supporting a Slackware style install is not something that concerns me.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
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: strange failure

[Stephen Smalley]

On Fri, 22 Mar 2002, Russell Coker wrote:

> I have the following in my policy:
> allow devfsd_t domain:dir_file_class_set getattr;
>
> But I get the following logged:
> Mar 22 22:26:22 test kernel: avc:  denied  { getattr } for  pid=394
> exe=/sbin/devfsd path=/vc/2 dev=00:07 ino=20
> scontext=system_u:system_r:devfsd_t
> tcontext=root:object_r:sysadm_tty_device_t tclass=chr_file
>
> What am I missing?
>
> I've tried this many times, read the macro expansion, reloaded the config and
> restarted the daemon etc.  I'm pretty sure that I haven't made the obvious
> mistakes of not saving the file or not loading the policy etc.

'domain' is a type attribute that is associated with every type that is
used to label a process (and would consequently be termed a "domain" in a
traditional TE model).  Hence, 'domain' includes sysadm_t but not
sysadm_tty_device_t.  Your allow rule permits devfsd to stat files labeled
with domains, which would only be /proc/PID entries.  If you want to grant
access to all terminal device types, use the 'ttyfile' and/or 'ptyfile'
type attributes with the chr_file class.  If you want to grant access to
all file types, then use the 'file_type' attribute.

--
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.