Bug 172470 - mgetty post receive fax operations fail with SELinux enabled
mgetty post receive fax operations fail with SELinux enabled
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-11-04 17:05 EST by Brad Wade
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-05-05 11:01:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
local.te (14.56 KB, text/plain)
2005-11-09 13:51 EST, Brad Wade
no flags Details
Post-fax receive script run by mgetty (3.07 KB, text/plain)
2005-11-09 14:03 EST, Brad Wade
no flags Details
New local.te (416 bytes, text/plain)
2005-12-07 01:45 EST, Brad Wade
no flags Details

  None (edit)
Description Brad Wade 2005-11-04 17:05:24 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

Description of problem:
After receiving a fax, the /etc/mgetty+sendfax/mgetty.config allows mgetty to notify a user via email that a fax was received using the "notify <username>" option.  It also allows a fax notification program to run, which is defined as /etc/mgetty+sendfax/new_fax for FC4.  Neither sendmail nor new_fax are allowed to run with selinux enabled.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set the "notify" option in /etc/mgetty+sendfax/mgetty.config to email a user that a fax was received (e.g., "notify root")
2. Copy a sample new_fax from /usr/share/doc/mgetty-1.1.33/samples to /etc/mgetty+sendfax, making it executable by root (the file must be named new_fax)
3. Receive a fax

Actual Results:  When mgetty goes to notify the user in mgetty.config, it reports the following in /var/log/mgetty.log.ttyS3 (my fax modem is located at /dev/ttyS3):

11/04 14:16:17 yS3  fax_notify_mail: mailer exit status: 32512 (127)

Also, when trying to run new_fax, mgetty reports the following in the same log file:

11/04 14:16:17 yS3  system() failed: Permission denied

Expected Results:  Disabling selinux, I get the following in mgetty.log.ttyS3 (user name hidden) when notifying the user in mgetty.config:

11/04 14:23:32 yS3   fax_notify_mail: sending mail to: xxx

Log entry when running new_fax (phone number hidden):

11/04 14:23:32 yS3   notify: '/etc/mgetty+sendfax/new_fax 0 'xxx-xxx-xxxx' 1  /v
ar/spool/fax/incoming/ff36bd12cS3-xxx-xxx-xxxx.01 >/dev/console 2>&1 </dev/null'

Additional info:

Maybe there's a workaround or something that I haven't configured correctly, but I couldn't find one when I go to edit the security settings, so I believe it's a bug.  Here's my output from getsebool -a:

NetworkManager_disable_trans --> inactive
allow_execmem --> active
allow_execmod --> active
allow_execstack --> active
allow_ftpd_anon_write --> inactive
allow_gssd_read_tmp --> active
allow_httpd_anon_write --> inactive
allow_httpd_sys_script_anon_write --> inactive
allow_kerberos --> active
allow_postgresql_use_pam --> inactive
allow_rsync_anon_write --> inactive
allow_saslauthd_read_shadow --> inactive
allow_smbd_anon_write --> inactive
allow_write_xshm --> inactive
allow_ypbind --> inactive
apmd_disable_trans --> inactive
arpwatch_disable_trans --> inactive
auditd_disable_trans --> inactive
bluetooth_disable_trans --> inactive
canna_disable_trans --> inactive
cardmgr_disable_trans --> inactive
comsat_disable_trans --> inactive
cupsd_config_disable_trans --> inactive
cupsd_disable_trans --> inactive
cupsd_lpd_disable_trans --> inactive
cvs_disable_trans --> inactive
cyrus_disable_trans --> inactive
dbskkd_disable_trans --> inactive
dhcpc_disable_trans --> inactive
dhcpd_disable_trans --> inactive
dovecot_disable_trans --> inactive
fingerd_disable_trans --> inactive
ftp_home_dir --> active
ftpd_disable_trans --> inactive
ftpd_is_daemon --> active
gssd_disable_trans --> inactive
hald_disable_trans --> inactive
hotplug_disable_trans --> inactive
howl_disable_trans --> inactive
hplip_disable_trans --> inactive
httpd_builtin_scripting --> active
httpd_can_network_connect --> active
httpd_disable_trans --> inactive
httpd_enable_cgi --> active
httpd_enable_ftp_server --> inactive
httpd_enable_homedirs --> active
httpd_ssi_exec --> active
httpd_suexec_disable_trans --> inactive
httpd_tty_comm --> inactive
httpd_unified --> active
inetd_child_disable_trans --> inactive
inetd_disable_trans --> inactive
innd_disable_trans --> inactive
kadmind_disable_trans --> inactive
klogd_disable_trans --> inactive
krb5kdc_disable_trans --> inactive
ktalkd_disable_trans --> inactive
lpd_disable_trans --> inactive
mysqld_disable_trans --> inactive
named_disable_trans --> inactive
named_write_master_zones --> inactive
nfs_export_all_ro --> active
nfs_export_all_rw --> active
nfsd_disable_trans --> inactive
nmbd_disable_trans --> inactive
nscd_disable_trans --> inactive
ntpd_disable_trans --> inactive
pegasus_disable_trans --> inactive
portmap_disable_trans --> inactive
postfix_disable_trans --> inactive
postgresql_disable_trans --> inactive
pppd_can_insmod --> inactive
pppd_disable_trans --> inactive
pppd_for_user --> inactive
pptp_disable_trans --> inactive
privoxy_disable_trans --> inactive
ptal_disable_trans --> inactive
radiusd_disable_trans --> inactive
radvd_disable_trans --> inactive
read_default_t --> active
rlogind_disable_trans --> inactive
rpcd_disable_trans --> inactive
rsync_disable_trans --> inactive
samba_enable_home_dirs --> active
saslauthd_disable_trans --> inactive
secure_mode_insmod --> inactive
secure_mode_policyload --> inactive
slapd_disable_trans --> inactive
smbd_disable_trans --> inactive
snmpd_disable_trans --> inactive
spamd_disable_trans --> inactive
squid_connect_any --> inactive
squid_disable_trans --> inactive
stunnel_disable_trans --> inactive
stunnel_is_daemon --> inactive
syslogd_disable_trans --> inactive
system_dbusd_disable_trans --> inactive
telnetd_disable_trans --> inactive
tftpd_disable_trans --> inactive
udev_disable_trans --> inactive
use_nfs_home_dirs --> inactive
use_samba_home_dirs --> inactive
uucpd_disable_trans --> inactive
winbind_disable_trans --> inactive
ypbind_disable_trans --> inactive
ypserv_disable_trans --> inactive
zebra_disable_trans --> inactive
Comment 1 Brad Wade 2005-11-09 13:51:35 EST
Created attachment 120850 [details]

I looked at some of the other bug reports dealing with selinux-targeted and saw
that if I do the following, then I can create a local policy that will allow
the previously blocked items to run:

1. # /usr/sbin/setenforce 0
2. Stopped the auditd daemon.
3. Cleared the /var/log/audit/audit.log file (actually, I just backed it up by
renaming it)
4. Started the auditd daemon.
5. Received a fax.
6. # cd /etc/selinux/targeted/src/policy/
7. # /usr/bin/audit2allow -i < /var/log/audit/audit.log >>

I have attached the resulting local.te file.  I am quite surprised at the
entries in local.te--mgetty seems to want to access everything.  Also, I had to
comment out the 

#allow getty_t unconfined_t:dir { getattr read search };

line so that I could run "make load" in the /etc/selinux/targeted/src/policy/
directory.  After running "make load", I can now receive faxes and have my
new_fax script run properly.

I will also post my new_fax script.
Comment 2 Brad Wade 2005-11-09 14:03:07 EST
Created attachment 120852 [details]
Post-fax receive script run by mgetty

My new_fax script is actually a combination of new_fax.hpa and printfax located
in /usr/share/doc/mgetty-1.1.33/samples/ with some minor customizations (I
couldn't get pbmtolj working).	I have commented out the username where I send
email.	I have an HP LaserJet 5L printer and the script works great for

I should also note that mgetty is also not allowed to save faxes in the default
installation directory: /var/spool/fax/incoming without the previous local.te

Also, I have the following mgetty packages installed:

# rpm -qa | grep mgetty

and pbm packages (used for working with fax documents):

# rpm -qa | grep pbm
Comment 3 Brad Wade 2005-11-28 17:38:37 EST

I'm available to help fix this bug.  Let me know how I can help.

Comment 4 Daniel Walsh 2005-11-30 10:00:10 EST
Can you just disable trans for mgetty?

If you set getty_disable_trans boolean does your script work?

setsebool -P getty_disable_trans=1

Another option would be to write a fax policy.  Basically take your script and
build a domain for it to be started for mgetty.  Giving getty all the privs to
allow your script to work would make it too weak for the majority of people who
do not have mgetty accepting faxes.
Comment 5 Paul Osmialowski 2005-12-03 05:34:11 EST
Soon I'm going to run Fax-receiving box working on already installed FC4, so any
solutions for this bug seem to be important to me.
Comment 6 Brad Wade 2005-12-07 01:40:40 EST
(In reply to comment #4)


Thanks for the reply.  I usually reply much sooner--I've been busy interviewing
for a new job among other things.

> Can you just disable trans for mgetty?
> If you set getty_disable_trans boolean does your script work?
> setsebool -P getty_disable_trans=1

I tried looking for the boolean, but couldn't find it.  I tried looking for
anything with 'getty' it before I posted.  I have
selinux-policy-targeted-1.27.1-2.14 installed.  Should I have such a boolean,
and if so, where do I find it (i.e., where did I lose it? :) ).

> Another option would be to write a fax policy.  Basically take your script and
> build a domain for it to be started for mgetty.  Giving getty all the privs to
> allow your script to work would make it too weak for the majority of people who
> do not have mgetty accepting faxes.

Good suggestion.  I was thinking about it--the mgetty.config file allows you to
notify someone when a fax is received.  I regenerated a new local.te to allow
email notification (without regards to running the new_fax script) and I got a
much smaller file:

allow getty_t bin_t:lnk_file read;
allow getty_t devtty_t:chr_file { read write };
allow getty_t self:fifo_file { getattr write };
allow getty_t self:process setpgid;
allow getty_t proc_t:file { getattr read };
allow getty_t shell_exec_t:file { execute execute_no_trans getattr read };
allow getty_t var_spool_t:dir { add_name search write };
allow getty_t var_spool_t:file { create getattr setattr write };

I think that this would be an allowable addition to the current policy since it
only allows the user to send mail (the only thing that wasn't allowed to run in

As far as running a script, I agree that my original local.te file would be too
permissive for most people.  Will you point me to a good resource on how to
build domains?  Thanks!
Comment 7 Brad Wade 2005-12-07 01:45:49 EST
Created attachment 121961 [details]
New local.te

Decided to create an attachment of last local.te.

P.S.  Daniel, sorry about addressing that last message to you as Dan--I was
going off memory.
Comment 8 Brad Wade 2006-03-17 16:20:14 EST
Russell and Daniel,

I'd still like to see this bug resolved.  In the latest version of
selinux-targeted (I have selinux-policy-targeted-1.27.1-2.22), it now lists the
getty_disabled_trans boolean.  With this boolean disabled, nothing is allowed to
happen (mgetty can not save faxes, email, etc.).  It seems to me that mgetty
should be allowed to received faxes in the directory that the mgetty-sendfax rpm
creates (i.e., /var/spool/fax/incoming).  It would also appear reasonable that
it can email the user in the config script.

With getty_disabled_trans enabled, mgetty will only save a fax in the /tmp
directory.  It still can't send an email or run the script in the config
file--both of which I would assume would happen with this boolean enabled.

Again, I am available to help you fix this bug.  Thanks for your time.
Comment 9 Brad Wade 2006-03-28 23:44:39 EST
Dear Russell and Daniel,

I realize that with Fedora Core 5 just being released that you have had your
hands full.  I would still like to see this bug resolved.  I have created my own
local.te several times, only to have it not work with nearly every release of
selinux-policy-targeted.  I really think a more permanent fix is wanting.  I
think the following would solve the problem:

1. Allow mgetty to write to the /var/spool/fax and its subdirectories (incoming
and outgoing).  This seems reasonable since mgetty-sendfax*.rpm creates these
2. Allow mgetty to send mail.  This seems reasonable since its part of the
mgetty source code.
3. For those that want to run the new_fax script, either allow
getty_disable_trans to do this or as previously mentioned, create a domain (I
haven't tried that yet--however, I believe it would most would change after
updated selinux-policy-targeted).

Again, I am available to help fix this bug.  I usually use another computer with
my cell phone attached to make the fax call to debug things.  Hoping to resolve
this bug soon...thanks!
Comment 10 Daniel Walsh 2006-04-03 12:48:46 EDT
Changes /var/spool/fax to getty_var_run_t.

Allowed getty to send mail

Need help on the fax part.

Fixed in selinux-policy-2.2.29-2.fc5
Comment 11 Brad Wade 2006-04-04 23:55:49 EDT
Thanks for the reply.  I'm still running FC4.  However, enabling
getty_disable_trans now allows my script to run.  I don't know if the latest
version of selinux-policy-targeted did that (I have 1.27.1-2.22) or if I forgot
to restart init earlier.  Either way, it works.

It might be a bit before I'm able to install FC5.  I'll test it after I get it
installed.  Thanks for fixing /var/spool/fax and allowing getty to send mail. 
Right now, though, I'm very happy that I can use mgetty on FC4 without any
problems.  If it's OK with you, let's leave this bug open until we can verify
that the fix works on FC5.  Thanks again.
Comment 12 Brad Wade 2006-04-06 02:45:46 EDT
I got thinking about it.  The only other thing that my script does that is not
allowed by the current policy (or built into mgetty) is to print the fax.  I
don't think the policy would be too lenient to print and most scripts included
with mgetty include the option to print.  Will you allow that option, too?

Also, are there plans to backport the changes you've made to FC4?  Thanks!
Comment 14 Daniel Walsh 2006-05-05 11:01:56 EDT
Closing as these have been marked as modified, for a while.  Feel free to reopen
if not fixed

Note You need to log in before you can comment on or make changes to this bug.