audit bug in fd handling

audit bug in fd handling

[Russell Coker]

It seems that when a file handle open read/write is inherited by a domain 
that is permitted read access only, an error about write access will be 
logged - even if there is a dontaudit rule!

Here's the dmesg log:
avc:  denied  { write } for  pid=4731 exe=/usr/sbin/sendmail 
path=/spool/fcron/fcrjob-Ldo3Uf (deleted) dev=03:08 ino=27923 
scontext=system_u:system_r:system_mail_t 
tcontext=system_u:object_r:system_crond_tmp_t tclass=file

Here's a grep from policy.conf:
dontaudit system_mail_t system_crond_tmp_t:file write;


Incidentally I'm changing the way mail sending operates.  Having daemons send 
mail as sysadm_mail_t is ugly, and having them send mail as user_mail_t is 
wrong.  I've created a new system_mail_t for this.

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

--
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: audit bug in fd handling

[Stephen Smalley]

On Wed, 10 Jul 2002, Russell Coker wrote:

> It seems that when a file handle open read/write is inherited by a domain
> that is permitted read access only, an error about write access will be
> logged - even if there is a dontaudit rule!

Congratulations, you've found a bug.  It isn't limited to file descriptor
inheritance - it occurs whenever multiple permissions are checked
simultaneously and at least one of the permissions is allowed.  A
workaround would be to specify the full set of permissions in the
dontaudit rule, e.g. 'dontaudit system_mail_t system_crond_tmp_t:file {
read write };'.  I'll post a patch for the SELinux module shortly.

--
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: audit bug in fd handling

[Stephen Smalley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 519 bytes --]


On Wed, 10 Jul 2002, Russell Coker wrote:

> It seems that when a file handle open read/write is inherited by a domain
> that is permitted read access only, an error about write access will be
> logged - even if there is a dontaudit rule!

The attached patch (also committed to the sourceforge CVS tree) fixes this
bug in the auditdeny logic.  To apply, save the patch to
~/auditdeny.patch, cd lsm-2.4, and patch -p0 < ~/auditdeny.patch.  Then,
rebuild your kernel.

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



[-- Attachment #2: Type: TEXT/PLAIN, Size: 1116 bytes --]

Index: security/selinux/include/linux/flask/avc.h
===================================================================
RCS file: /cvsroot/selinux/nsa/lsm-2.4/security/selinux/include/linux/flask/avc.h,v
retrieving revision 1.3
diff -u -r1.3 avc.h
--- security/selinux/include/linux/flask/avc.h	3 Jun 2002 13:46:51 -0000	1.3
+++ security/selinux/include/linux/flask/avc.h	10 Jul 2002 13:03:52 -0000
@@ -214,6 +214,7 @@
 	unsigned long	flags;
 	struct avc_entry entry;
 	__u32 seqno;
+	access_vector_t denied;
 
 	spin_lock_irqsave(&avc_lock, flags);
 	avc_cache_stats_incr(AVC_ENTRY_LOOKUPS);
@@ -254,9 +255,11 @@
 		ae = aeref->ae;
 	}
 
-	if (!requested || (requested & ae->allowed) != requested) {
-		if (!requested || (requested & ae->auditdeny))
-			avc_audit(ssid, tsid, tclass, requested & ~(ae->allowed), ae,
+	denied = requested & ~(ae->allowed);
+
+	if (!requested || denied) {
+		if (!requested || (denied & ae->auditdeny))
+			avc_audit(ssid, tsid, tclass, denied, ae,
 				  AVC_AUDITDENY, auditdata);
 #ifdef CONFIG_SECURITY_SELINUX_DEVELOP
 		if (avc_debug_always_allow) {

RE: audit bug in fd handling

[Ed Street]

Hello,

Perhaps this is why mail is the #1 exploited service.  So what's the
solution?  

Ed

=> -----Original Message-----
=> From: owner-selinux@tycho.nsa.gov
[mailto:owner-selinux@tycho.nsa.gov] On
=> Behalf Of Russell Coker
=> Sent: Wednesday, July 10, 2002 3:46 AM
=> To: SE Linux
=> Subject: audit bug in fd handling
=> 
=> It seems that when a file handle open read/write is inherited by a
domain
=> that is permitted read access only, an error about write access will
be
=> logged - even if there is a dontaudit rule!
=> 
=> Here's the dmesg log:
=> avc:  denied  { write } for  pid=4731 exe=/usr/sbin/sendmail
=> path=/spool/fcron/fcrjob-Ldo3Uf (deleted) dev=03:08 ino=27923
=> scontext=system_u:system_r:system_mail_t
=> tcontext=system_u:object_r:system_crond_tmp_t tclass=file
=> 
=> Here's a grep from policy.conf:
=> dontaudit system_mail_t system_crond_tmp_t:file write;
=> 
=> 
=> Incidentally I'm changing the way mail sending operates.  Having
daemons
=> send
=> mail as sysadm_mail_t is ugly, and having them send mail as
user_mail_t
=> is
=> wrong.  I've created a new system_mail_t for this.
=> 
=> --
=> I do not get viruses because I do not use MS software.
=> If you use Outlook then please do not put my email address in your
=> address-book so that WHEN you get a virus it won't use my address in
the
=> >From field.
=> 
=> --
=> 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.


--
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: audit bug in fd handling

[Russell Coker]

On Wed, 10 Jul 2002 15:23, Ed Street wrote:
> Perhaps this is why mail is the #1 exploited service.  So what's the
> solution?

I'm not sure what you mean by this.  The bug I found was just a case of 
excessive logging and does no harm (apart from possibly encouraging 
inexperienced SE Linux administrators to grant excessive permissions).

The issue of an application granting write access to the file is annoying, 
however it is apparently operating on an open file handle pointing to a 
deleted file, after deleting the file you can't re-open it in read-only mode.

In this case fcron could either open the file twice before deleting it (once 
for read and once for write), or it could pipe the data to /usr/bin/mail 
(either directly from the cron job, or it could spool it in RAM).

What should it do?  I am happy to write a patch for fcron and get it 
submitted through the Debian bug tracking system if a consensus of opinion is 
reached here on the right way of doing it.

> => -----Original Message-----
> => From: owner-selinux@tycho.nsa.gov
> [mailto:owner-selinux@tycho.nsa.gov] On
> => Behalf Of Russell Coker
> => Sent: Wednesday, July 10, 2002 3:46 AM
> => To: SE Linux
> => Subject: audit bug in fd handling
> =>
> => It seems that when a file handle open read/write is inherited by a
> domain
> => that is permitted read access only, an error about write access will
> be
> => logged - even if there is a dontaudit rule!
> =>
> => Here's the dmesg log:
> => avc:  denied  { write } for  pid=4731 exe=/usr/sbin/sendmail
> => path=/spool/fcron/fcrjob-Ldo3Uf (deleted) dev=03:08 ino=27923
> => scontext=system_u:system_r:system_mail_t
> => tcontext=system_u:object_r:system_crond_tmp_t tclass=file
> =>
> => Here's a grep from policy.conf:
> => dontaudit system_mail_t system_crond_tmp_t:file write;
> =>
> =>
> => Incidentally I'm changing the way mail sending operates.  Having
> daemons
> => send
> => mail as sysadm_mail_t is ugly, and having them send mail as
> user_mail_t
> => is
> => wrong.  I've created a new system_mail_t for this.
> =>
> => --
> => I do not get viruses because I do not use MS software.
> => If you use Outlook then please do not put my email address in your
> => address-book so that WHEN you get a virus it won't use my address in
> the
> => >From field.
> =>
> => --
> => 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.

-- 
I do not get viruses because I do not use MS software.
If you use Outlook then please do not put my email address in your
address-book so that WHEN you get a virus it won't use my address in the
>From field.

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

sysadm_tty_device_t

[Ed Street]

Hello,

Was working with putting syslog on /dev/tty24 (entry in /etc/syslog.conf
is 
*.*	/dev/tty24

Selinux shows /dev/tty1 as syadm_tty_device_t but /dev/tty24 is just
tty_device_t.  I started poking around looking for sysadm_tty_device_t
but not exactly sure what tty's are being set to this.  My question is
where is the control file, is it /etc/securetty?

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: sysadm_tty_device_t

[Stephen Smalley]

On Thu, 11 Jul 2002, Ed Street wrote:

> Was working with putting syslog on /dev/tty24 (entry in /etc/syslog.conf
> is
> *.*	/dev/tty24
>
> Selinux shows /dev/tty1 as syadm_tty_device_t but /dev/tty24 is just
> tty_device_t.  I started poking around looking for sysadm_tty_device_t
> but not exactly sure what tty's are being set to this.  My question is
> where is the control file, is it /etc/securetty?

ttys are initialized to tty_device_t by 'make relabel'.  They are then
relabeled by the modified login program based on the user's context for
user sessions, and are also relabeled by the newrole program for shells in
different roles.

--
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: sysadm_tty_device_t

[Ed Street]

Hello,

And sysadm_tty_device_t?

Ed

=> 
=> ttys are initialized to tty_device_t by 'make relabel'.  They are
then
=> relabeled by the modified login program based on the user's context
for
=> user sessions, and are also relabeled by the newrole program for
shells
=> in different roles.


--
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: sysadm_tty_device_t

[Stephen Smalley]

On Thu, 11 Jul 2002, Ed Street wrote:

> And sysadm_tty_device_t?

That was my point.  The ttys start in tty_device_t.  If login or newrole
creates a sysadm_r:sysadm_t shell, then it relabels the tty to
sysadm_tty_device_t.  If login or newrole creates a user_r:user_t shell,
then it relabels the tty to user_tty_device_t.  These relabeling
operations are based on type_change rules in the policy configuration.

--
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: sysadm_tty_device_t

[Ed Street]

Hello,

OK my /etc/syslogd.conf file contains this

*.*	/dev/tty24

when I boot or run-init I get this

allow syslogd_t tty_device_t:chr_file { append };
        #EXE=/sbin/syslogd  PATH=/dev/tty24   :  append

The avc from kern.log is this

Jul 11 13:51:17 debian kernel: avc:  denied  { append } for  pid=160
exe=/sbin/syslogd path=/dev/tty24 dev=72:01 ino=2175725
scontext=system_u:system_r:syslogd_t
tcontext=system_u:object_r:tty_device_t tclass=chr_file

Syntax is this:
debian:~# id
uid=0(root) gid=0(root) groups=0(root) context=root:sysadm_r:sysadm_t
sid=222

run_init /etc/init.d/sysklogd restart


Also states permission denied for /dev/tty24.  BTW in case anyone is
wondering /dev/tty1-12 is the left alt key, /dev/tty13-24 is the right
alt key.

Ed

=> -----Original Message-----
=> From: Stephen Smalley [mailto:sds@tislabs.com]
=> Sent: Thursday, July 11, 2002 1:39 PM
=> To: Ed Street
=> Cc: 'SE Linux'
=> Subject: RE: sysadm_tty_device_t
=> 
=> 
=> On Thu, 11 Jul 2002, Ed Street wrote:
=> 
=> > And sysadm_tty_device_t?
=> 
=> That was my point.  The ttys start in tty_device_t.  If login or
newrole
=> creates a sysadm_r:sysadm_t shell, then it relabels the tty to
=> sysadm_tty_device_t.  If login or newrole creates a user_r:user_t
shell,
=> then it relabels the tty to user_tty_device_t.  These relabeling
=> operations are based on type_change rules in the policy
configuration.
=> 
=> --
=> 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: sysadm_tty_device_t

[Stephen Smalley]

On Thu, 11 Jul 2002, Ed Street wrote:

> Hello,
>
> OK my /etc/syslogd.conf file contains this
>
> *.*	/dev/tty24
>
> when I boot or run-init I get this
>
> allow syslogd_t tty_device_t:chr_file { append };
>         #EXE=/sbin/syslogd  PATH=/dev/tty24   :  append
>
> The avc from kern.log is this
>
> Jul 11 13:51:17 debian kernel: avc:  denied  { append } for  pid=160
> exe=/sbin/syslogd path=/dev/tty24 dev=72:01 ino=2175725
> scontext=system_u:system_r:syslogd_t
> tcontext=system_u:object_r:tty_device_t tclass=chr_file

Right, this is what I would expect to happen.  What is your question,
exactly?  If you want syslogd to be able to write to a tty, you need to
grant syslogd_t the necessary permission.  If you want to ensure that only
syslogd can write to the tty, then define a new type, assign it to the tty
in types.fc (or use chcon directly), and grant syslogd_t permission to the
new type.  Otherwise, just allow syslogd_t tty_device_t:chr_file append;

--
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: sysadm_tty_device_t

[Ed Street]

Hello,

Should the /dev/tty24 be sysadm_tty_device_t instead of tty_device_t?
Now here's the odd thing, I change /dev/tty24 to tty1, tty2 or tt3 and I
get sysadm_tty_device_t and there's no denied messages

Ed

=> -----Original Message-----
=> From: Stephen Smalley [mailto:sds@tislabs.com]
=> Sent: Thursday, July 11, 2002 2:20 PM
=> To: Ed Street
=> Cc: 'SE Linux'
=> Subject: RE: sysadm_tty_device_t
=> 
=> 
=> On Thu, 11 Jul 2002, Ed Street wrote:
=> 
=> > Hello,
=> >
=> > OK my /etc/syslogd.conf file contains this
=> >
=> > *.*	/dev/tty24
=> >
=> > when I boot or run-init I get this
=> >
=> > allow syslogd_t tty_device_t:chr_file { append };
=> >         #EXE=/sbin/syslogd  PATH=/dev/tty24   :  append
=> >
=> > The avc from kern.log is this
=> >
=> > Jul 11 13:51:17 debian kernel: avc:  denied  { append } for
pid=160
=> > exe=/sbin/syslogd path=/dev/tty24 dev=72:01 ino=2175725
=> > scontext=system_u:system_r:syslogd_t
=> > tcontext=system_u:object_r:tty_device_t tclass=chr_file
=> 
=> Right, this is what I would expect to happen.  What is your question,
=> exactly?  If you want syslogd to be able to write to a tty, you need
to
=> grant syslogd_t the necessary permission.  If you want to ensure that
=> only
=> syslogd can write to the tty, then define a new type, assign it to
the
=> tty
=> in types.fc (or use chcon directly), and grant syslogd_t permission
to
=> the
=> new type.  Otherwise, just allow syslogd_t tty_device_t:chr_file
append;
=> 
=> --
=> 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: sysadm_tty_device_t

[Stephen Smalley]

On Thu, 11 Jul 2002, Ed Street wrote:

> Should the /dev/tty24 be sysadm_tty_device_t instead of tty_device_t?
> Now here's the odd thing, I change /dev/tty24 to tty1, tty2 or tt3 and I
> get sysadm_tty_device_t and there's no denied messages

So this suggests that:
a) Your policy includes a 'allow syslogd_t
sysadm_tty_device_t:chr_file..." rule.  Check your policy.conf.
b) tty[1-3] are currently in use or were last used by a sysadm_r:sysadm_t
user session.

You can certainly assign sysadm_tty_device_t to /dev/tty24 if you want.

--
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: sysadm_tty_device_t

[Ed Street]

Hello,

Forgot one thing.

*.*	/dev/tty1-3 does work correctly (from /etc/syslog.conf)

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: sysadm_tty_device_t

[Timothy Wood]

В Чтв, 11.07.2002, в 13:39, Stephen Smalley написал:
> 
> On Thu, 11 Jul 2002, Ed Street wrote:
> 
> > And sysadm_tty_device_t?
> 
> That was my point.  The ttys start in tty_device_t.  If login or newrole
> creates a sysadm_r:sysadm_t shell, then it relabels the tty to
> sysadm_tty_device_t.  If login or newrole creates a user_r:user_t shell,
> then it relabels the tty to user_tty_device_t.  These relabeling
> operations are based on type_change rules in the policy configuration.
> 
> --
> Stephen D. Smalley, NAI Labs
> ssmalley@nai.com
> 

So no matter what the file context is login and newrole relabel them
when they take control of the tty, correct?  If so, then it is really up
to the controlling program (or program that needs control in this case)
and so syslog needs premissions to relabel and/or control the tty,
yes/no?

Timothy,


--
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: sysadm_tty_device_t

[Ed Street]

Hello,

That's what it seems to be.  It does look like an accident waiting to
happen as well.

Ed

=> -----Original Message-----
=> From: Timothy Wood [mailto:timothy@hallcomp.com]
=> Sent: Thursday, July 11, 2002 3:55 PM
=> To: Stephen Smalley
=> Cc: Ed Street; 'SE Linux'
=> Subject: RE: sysadm_tty_device_t
=> 
=> В Чтв, 11.07.2002, в 13:39, Stephen Smalley написал:
=> >
=> > On Thu, 11 Jul 2002, Ed Street wrote:
=> >
=> > > And sysadm_tty_device_t?
=> >
=> > That was my point.  The ttys start in tty_device_t.  If login or
=> newrole
=> > creates a sysadm_r:sysadm_t shell, then it relabels the tty to
=> > sysadm_tty_device_t.  If login or newrole creates a user_r:user_t
=> shell,
=> > then it relabels the tty to user_tty_device_t.  These relabeling
=> > operations are based on type_change rules in the policy
configuration.
=> >
=> > --
=> > Stephen D. Smalley, NAI Labs
=> > ssmalley@nai.com
=> >
=> 
=> So no matter what the file context is login and newrole relabel them
=> when they take control of the tty, correct?  If so, then it is really
up
=> to the controlling program (or program that needs control in this
case)
=> and so syslog needs premissions to relabel and/or control the tty,
=> yes/no?
=> 
=> Timothy,


--
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: sysadm_tty_device_t

[Stephen Smalley]

On Thu, 11 Jul 2002, Ed Street wrote:

> That's what it seems to be.  It does look like an accident waiting to
> happen as well.

I'm not sure what you mean.  The relabeling of the terminal devices by
login is just like the setting of the uid on the device by login.  Nothing
unusual here.

--
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: sysadm_tty_device_t

[Timothy Wood]

В Чтв, 11.07.2002, в 15:53, Ed Street написал:
> Hello,
> 
> That's what it seems to be.  It does look like an accident waiting to
> happen as well.
> 
> Ed

I would not nessicarily call it an accident waiting to happen.  More
like something that needs configured if you want it.  You have to
remember that basic idea here is no access to something you don't need
(as far as processes are concerned).  Syslog really only needs access to
the log files it writes to, with the exception of severe kernel
messages.  The latter I suppose works (/dev/console not /dev/tty*) but I
have never noticed any kernel warnings or avc messages denying syslog
write to /dev/console.  So I could easily be wrong about that. 

Timothy,

> 
> => -----Original Message-----
> => From: Timothy Wood [mailto:timothy@hallcomp.com]
> => Sent: Thursday, July 11, 2002 3:55 PM
> => To: Stephen Smalley
> => Cc: Ed Street; 'SE Linux'
> => Subject: RE: sysadm_tty_device_t
> => 
> => В Чтв, 11.07.2002, в 13:39, Stephen Smalley написал:
> => >
> => > On Thu, 11 Jul 2002, Ed Street wrote:
> => >
> => > > And sysadm_tty_device_t?
> => >
> => > That was my point.  The ttys start in tty_device_t.  If login or
> => newrole
> => > creates a sysadm_r:sysadm_t shell, then it relabels the tty to
> => > sysadm_tty_device_t.  If login or newrole creates a user_r:user_t
> => shell,
> => > then it relabels the tty to user_tty_device_t.  These relabeling
> => > operations are based on type_change rules in the policy
> configuration.
> => >
> => > --
> => > Stephen D. Smalley, NAI Labs
> => > ssmalley@nai.com
> => >
> => 
> => So no matter what the file context is login and newrole relabel them
> => when they take control of the tty, correct?  If so, then it is really
> up
> => to the controlling program (or program that needs control in this
> case)
> => and so syslog needs premissions to relabel and/or control the tty,
> => yes/no?
> => 
> => Timothy,
> 
> 



--
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: sysadm_tty_device_t

[Stephen Smalley]

On 11 Jul 2002, Timothy Wood wrote:

> So no matter what the file context is login and newrole relabel them
> when they take control of the tty, correct?  If so, then it is really up
> to the controlling program (or program that needs control in this case)
> and so syslog needs premissions to relabel and/or control the tty,
> yes/no?

The modified login and newrole programs (and sshd program, but it only
deals with ptys) relabel the terminal device based on the user's context
and the original context on the device.  The proper SID is obtained via
the security_change_sid call, which computes a SID based on the
type_change rules in the policy configuration.

This is only necessary when you have a dynamic situation where the proper
context for the device needs to be adjusted for the current "owner" of the
device, and is parallel to the existing Linux handling of setting the uid
on such devices.

If you are dedicating a terminal for syslogd output, then you can
statically label it with a type, grant syslogd permission to append to
that type, and be done with it.

--
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: booting problem

[Charles R. Fuller]

Stephen,

I am having a problem of booting selinux on my machine.  I have modified 
the kernel and finished off with a the quick install command.

The specific error is a kernel panic on boot of the selinux kernel and 
an error point to correcting the referrence for "ROOT="

The reference "ROOT=" is the same for the none linux kernels.  Thanks 
for the help in advance.

Also I originally used GRUB as the boot loader the first time I ran 
Redhat 7.2 with SE-linux.  If you know how to change the boot loader  
from lilo to GRUB that could be one option.


Charles R. Fuller




--
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: booting problem

[Stephen Smalley]

On Fri, 19 Jul 2002, Charles R. Fuller wrote:

> The specific error is a kernel panic on boot of the selinux kernel and
> an error point to correcting the referrence for "ROOT="
>
> The reference "ROOT=" is the same for the none linux kernels.  Thanks
> for the help in advance.

Could you provide the exact output, along with a copy of your lilo.conf or
grub.conf (omitting any passwords, of course)?

--
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: sysadm_tty_device_t

[Timothy Wood]

В Чтв, 11.07.2002, в 12:13, Ed Street написал:
> Hello,
> 
> Was working with putting syslog on /dev/tty24 (entry in /etc/syslog.conf
> is 
> *.*	/dev/tty24
> 
> Selinux shows /dev/tty1 as syadm_tty_device_t but /dev/tty24 is just
> tty_device_t.  I started poking around looking for sysadm_tty_device_t
> but not exactly sure what tty's are being set to this.  My question is
> where is the control file, is it /etc/securetty?
> 
> 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.
> 

you need to edit the file context for the tty devices.  I think it is in
/usr/src/selinux/policy/file_contexts/dev.fc (I do not have my SE box up
and running at the moment so I do not know for certain.  Can any
acknowledge if that is the right file please).  Now changing it there
will make the change permanent but you still need to either relabel the
file system (do a make relabel from the policy directory) or use chcon
to change just the one device (eg chcon <file_context> /dev/tty24)



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

booting problem

[于婧]

I'm porting hardhat linux v2.1 on my motorola lopec mpc7410 board with a
zynx zx212 dual-port ethernet card on it.The problem is that the kernel
can't start up with the ethernet card on,while without it everything is
perfect.Since zx212 is compatible with 21143,I build the kernel with
the "tulip" option on.It should be no problem,but it happened. It halts
after "now booting the kernel".
Does anybody have the same problem?

Best Regard
Yu

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Booting Problem

[Ronaldo Zacarias Afonso]

  I just compiled a new kernel and when I try to boot it the following
message apears on my screen:

Partition check:
hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7>
Unable to handle kernel NULL pointer dereference at virtual address 00000000
current->tss.cr3 = 01a5d000, %cr3 = 01a5d000
*pde = 00000000
Oops: 0000
CPU: 0
EIP: 0010:[<00000000>]
EFLAGS: 00010246
eax: 00000000 ebx: c2045260 ecx: c1ddbfe0 edx: c2045260
esi: c0e1f5dc edi: 00000000 ebp: 00000000 esp: c1a5fe00
ds: 0018 es: 0018 ss: 0018
Process rpc.lockd (pid: 340, process nr: 12, stackpage=c1a5f000)
Stack: c0e1f5dc 00000000 c015f38f c0e1f5dc 00000000 c0dc1000 c28181e9
c0e1f5dcc0dc1000 c2819d16 c0dc1000 c0e6cd90 c2817274 c0dc1000 c0e6cd90 c28172eb
c0e6cd90 c1a5fe78 c281a9a7 c0e6cd90 c1a5fe78 c28174d1 c1a5fe78 00000000
Call Trace: [] [] [] [] [] [] []
[] [] [] [] [] [] [] []
[] [] [] []
Code: 8a 04 0b 89 44 24 38 50 68 f0 5e 1b c0 e8 55 9b 00 00 83 c4


  Can anyone help me?