* audit bug in fd handling
@ 2002-07-10 7:45 Russell Coker
2002-07-10 11:55 ` Stephen Smalley
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Russell Coker @ 2002-07-10 7:45 UTC (permalink / raw)
To: SE Linux
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: audit bug in fd handling 2002-07-10 7:45 audit bug in fd handling Russell Coker @ 2002-07-10 11:55 ` Stephen Smalley 2002-07-10 13:12 ` Stephen Smalley 2002-07-10 13:23 ` Ed Street 2 siblings, 0 replies; 22+ messages in thread From: Stephen Smalley @ 2002-07-10 11:55 UTC (permalink / raw) To: Russell Coker; +Cc: SE Linux 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: audit bug in fd handling 2002-07-10 7:45 audit bug in fd handling Russell Coker 2002-07-10 11:55 ` Stephen Smalley @ 2002-07-10 13:12 ` Stephen Smalley 2002-07-10 13:23 ` Ed Street 2 siblings, 0 replies; 22+ messages in thread From: Stephen Smalley @ 2002-07-10 13:12 UTC (permalink / raw) To: Russell Coker; +Cc: SE Linux [-- 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) { ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: audit bug in fd handling 2002-07-10 7:45 audit bug in fd handling Russell Coker 2002-07-10 11:55 ` Stephen Smalley 2002-07-10 13:12 ` Stephen Smalley @ 2002-07-10 13:23 ` Ed Street 2002-07-10 14:40 ` Russell Coker 2 siblings, 1 reply; 22+ messages in thread From: Ed Street @ 2002-07-10 13:23 UTC (permalink / raw) To: 'Russell Coker', 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: audit bug in fd handling 2002-07-10 13:23 ` Ed Street @ 2002-07-10 14:40 ` Russell Coker 2002-07-11 16:13 ` sysadm_tty_device_t Ed Street 0 siblings, 1 reply; 22+ messages in thread From: Russell Coker @ 2002-07-10 14:40 UTC (permalink / raw) To: blacknet, 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* sysadm_tty_device_t 2002-07-10 14:40 ` Russell Coker @ 2002-07-11 16:13 ` Ed Street 2002-07-11 17:21 ` sysadm_tty_device_t Stephen Smalley 2002-07-11 18:28 ` sysadm_tty_device_t Timothy Wood 0 siblings, 2 replies; 22+ messages in thread From: Ed Street @ 2002-07-11 16:13 UTC (permalink / raw) To: 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sysadm_tty_device_t 2002-07-11 16:13 ` sysadm_tty_device_t Ed Street @ 2002-07-11 17:21 ` Stephen Smalley 2002-07-11 17:24 ` sysadm_tty_device_t Ed Street 2002-07-11 18:28 ` sysadm_tty_device_t Timothy Wood 1 sibling, 1 reply; 22+ messages in thread From: Stephen Smalley @ 2002-07-11 17:21 UTC (permalink / raw) To: Ed Street; +Cc: 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 17:21 ` sysadm_tty_device_t Stephen Smalley @ 2002-07-11 17:24 ` Ed Street 2002-07-11 17:39 ` sysadm_tty_device_t Stephen Smalley 0 siblings, 1 reply; 22+ messages in thread From: Ed Street @ 2002-07-11 17:24 UTC (permalink / raw) To: 'Stephen Smalley'; +Cc: 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 17:24 ` sysadm_tty_device_t Ed Street @ 2002-07-11 17:39 ` Stephen Smalley 2002-07-11 17:54 ` sysadm_tty_device_t Ed Street ` (3 more replies) 0 siblings, 4 replies; 22+ messages in thread From: Stephen Smalley @ 2002-07-11 17:39 UTC (permalink / raw) To: Ed Street; +Cc: 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 17:39 ` sysadm_tty_device_t Stephen Smalley @ 2002-07-11 17:54 ` Ed Street 2002-07-11 18:19 ` sysadm_tty_device_t Stephen Smalley 2002-07-11 17:55 ` sysadm_tty_device_t Ed Street ` (2 subsequent siblings) 3 siblings, 1 reply; 22+ messages in thread From: Ed Street @ 2002-07-11 17:54 UTC (permalink / raw) To: 'Stephen Smalley'; +Cc: 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 17:54 ` sysadm_tty_device_t Ed Street @ 2002-07-11 18:19 ` Stephen Smalley 2002-07-11 18:24 ` sysadm_tty_device_t Ed Street 0 siblings, 1 reply; 22+ messages in thread From: Stephen Smalley @ 2002-07-11 18:19 UTC (permalink / raw) To: Ed Street; +Cc: 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 18:19 ` sysadm_tty_device_t Stephen Smalley @ 2002-07-11 18:24 ` Ed Street 2002-07-11 18:35 ` sysadm_tty_device_t Stephen Smalley 0 siblings, 1 reply; 22+ messages in thread From: Ed Street @ 2002-07-11 18:24 UTC (permalink / raw) To: 'Stephen Smalley'; +Cc: 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 18:24 ` sysadm_tty_device_t Ed Street @ 2002-07-11 18:35 ` Stephen Smalley 0 siblings, 0 replies; 22+ messages in thread From: Stephen Smalley @ 2002-07-11 18:35 UTC (permalink / raw) To: Ed Street; +Cc: 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 17:39 ` sysadm_tty_device_t Stephen Smalley 2002-07-11 17:54 ` sysadm_tty_device_t Ed Street @ 2002-07-11 17:55 ` Ed Street 2002-07-11 19:55 ` sysadm_tty_device_t Timothy Wood 2002-07-19 21:27 ` booting problem Charles R. Fuller 3 siblings, 0 replies; 22+ messages in thread From: Ed Street @ 2002-07-11 17:55 UTC (permalink / raw) To: 'Stephen Smalley'; +Cc: 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 17:39 ` sysadm_tty_device_t Stephen Smalley 2002-07-11 17:54 ` sysadm_tty_device_t Ed Street 2002-07-11 17:55 ` sysadm_tty_device_t Ed Street @ 2002-07-11 19:55 ` Timothy Wood 2002-07-11 19:53 ` sysadm_tty_device_t Ed Street 2002-07-11 20:05 ` sysadm_tty_device_t Stephen Smalley 2002-07-19 21:27 ` booting problem Charles R. Fuller 3 siblings, 2 replies; 22+ messages in thread From: Timothy Wood @ 2002-07-11 19:55 UTC (permalink / raw) To: Stephen Smalley; +Cc: Ed Street, 'SE Linux' В Чтв, 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 19:55 ` sysadm_tty_device_t Timothy Wood @ 2002-07-11 19:53 ` Ed Street 2002-07-11 20:07 ` sysadm_tty_device_t Stephen Smalley 2002-07-11 20:12 ` sysadm_tty_device_t Timothy Wood 2002-07-11 20:05 ` sysadm_tty_device_t Stephen Smalley 1 sibling, 2 replies; 22+ messages in thread From: Ed Street @ 2002-07-11 19:53 UTC (permalink / raw) To: 'Timothy Wood', 'Stephen Smalley'; +Cc: 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 19:53 ` sysadm_tty_device_t Ed Street @ 2002-07-11 20:07 ` Stephen Smalley 2002-07-11 20:12 ` sysadm_tty_device_t Timothy Wood 1 sibling, 0 replies; 22+ messages in thread From: Stephen Smalley @ 2002-07-11 20:07 UTC (permalink / raw) To: Ed Street; +Cc: 'Timothy Wood', 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 19:53 ` sysadm_tty_device_t Ed Street 2002-07-11 20:07 ` sysadm_tty_device_t Stephen Smalley @ 2002-07-11 20:12 ` Timothy Wood 1 sibling, 0 replies; 22+ messages in thread From: Timothy Wood @ 2002-07-11 20:12 UTC (permalink / raw) To: blacknet; +Cc: 'Stephen Smalley', 'SE Linux' В Чтв, 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: sysadm_tty_device_t 2002-07-11 19:55 ` sysadm_tty_device_t Timothy Wood 2002-07-11 19:53 ` sysadm_tty_device_t Ed Street @ 2002-07-11 20:05 ` Stephen Smalley 1 sibling, 0 replies; 22+ messages in thread From: Stephen Smalley @ 2002-07-11 20:05 UTC (permalink / raw) To: Timothy Wood; +Cc: Ed Street, 'SE Linux' 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: booting problem 2002-07-11 17:39 ` sysadm_tty_device_t Stephen Smalley ` (2 preceding siblings ...) 2002-07-11 19:55 ` sysadm_tty_device_t Timothy Wood @ 2002-07-19 21:27 ` Charles R. Fuller 2002-07-22 11:59 ` Stephen Smalley 3 siblings, 1 reply; 22+ messages in thread From: Charles R. Fuller @ 2002-07-19 21:27 UTC (permalink / raw) To: Stephen Smalley; +Cc: selinux 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: booting problem 2002-07-19 21:27 ` booting problem Charles R. Fuller @ 2002-07-22 11:59 ` Stephen Smalley 0 siblings, 0 replies; 22+ messages in thread From: Stephen Smalley @ 2002-07-22 11:59 UTC (permalink / raw) To: Charles R. Fuller; +Cc: selinux 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: sysadm_tty_device_t 2002-07-11 16:13 ` sysadm_tty_device_t Ed Street 2002-07-11 17:21 ` sysadm_tty_device_t Stephen Smalley @ 2002-07-11 18:28 ` Timothy Wood 1 sibling, 0 replies; 22+ messages in thread From: Timothy Wood @ 2002-07-11 18:28 UTC (permalink / raw) To: blacknet; +Cc: 'SE Linux' В Чтв, 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. ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2002-07-22 12:00 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-07-10 7:45 audit bug in fd handling Russell Coker 2002-07-10 11:55 ` Stephen Smalley 2002-07-10 13:12 ` Stephen Smalley 2002-07-10 13:23 ` Ed Street 2002-07-10 14:40 ` Russell Coker 2002-07-11 16:13 ` sysadm_tty_device_t Ed Street 2002-07-11 17:21 ` sysadm_tty_device_t Stephen Smalley 2002-07-11 17:24 ` sysadm_tty_device_t Ed Street 2002-07-11 17:39 ` sysadm_tty_device_t Stephen Smalley 2002-07-11 17:54 ` sysadm_tty_device_t Ed Street 2002-07-11 18:19 ` sysadm_tty_device_t Stephen Smalley 2002-07-11 18:24 ` sysadm_tty_device_t Ed Street 2002-07-11 18:35 ` sysadm_tty_device_t Stephen Smalley 2002-07-11 17:55 ` sysadm_tty_device_t Ed Street 2002-07-11 19:55 ` sysadm_tty_device_t Timothy Wood 2002-07-11 19:53 ` sysadm_tty_device_t Ed Street 2002-07-11 20:07 ` sysadm_tty_device_t Stephen Smalley 2002-07-11 20:12 ` sysadm_tty_device_t Timothy Wood 2002-07-11 20:05 ` sysadm_tty_device_t Stephen Smalley 2002-07-19 21:27 ` booting problem Charles R. Fuller 2002-07-22 11:59 ` Stephen Smalley 2002-07-11 18:28 ` sysadm_tty_device_t Timothy Wood
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.