On Sat, 2 Oct 2004 01:36, Daniel J Walsh <dwalsh@redhat.com> wrote:
> >+# /usr/sbin/sendmail asks for w access to utmp
> >+allow sendmail_t initrc_var_run_t:file { getattr read lock write };
> >
> >Why does sendmail need lock and write access to initrc_var_run_t?
>
> sm-client will not work without this.

That turned out to be a bug in sendmail.fc. I have attached a patch which fixes sendmail.fc and also removes the unnecessary rules from sendmail.te.

> >Also you have put in comments indicating that several programs have been
> >compiled with SSP (Stack Smashing Protection). If the Fedora GCC packages
> >support SSP then we should enable it for newrole etc.

You missed the bit about SSP.

> >+allow udev_t domain:dir r_dir_perms;
> >
> >Why does udev need this? Why would it need read access to the directory
> > but not to files inside it?
>
> It is running killall.

OK, then probably we want a dontaudit rule.

> >+/usr/bin/chage -- system_u:object_r:passwd_exec_t
> >
> >This is wrong. It should be admin_passwd_exec_t. A regular user should
> > not execute this.
>
> chage -l dwalsh is available.

OK, we need to patch chage in the same way as passwd then. We don't want to permit root:user_r:user_t to invalidate accounts.

> >--- nsapolicy/macros/global_macros.te 2004-09-22 16:19:13.000000000
> > -0400 +++ policy-1.17.25/macros/global_macros.te 2004-09-30
> > 20:59:57.315488479 -0400
> >@@ -287,6 +287,7 @@
> > allow $1_t device_t:dir { getattr search };
> > allow $1_t null_device_t:chr_file rw_file_perms;
> > dontaudit $1_t console_device_t:chr_file rw_file_perms;
> >+dontaudit $1_t unpriv_userdomain:fd use;
> >
> > r_dir_file($1_t, sysfs_t)
> >
> >How do you trigger this? Is it related to the bug in su where su does not
> >re-open the terminal when changing role? I expect that fixing su will fix
> >this.
>
> Maybe, it happens when you do a service daemon restart. Not sure we can
> easily fix the su bug.

Please give an example of a command that triggers this.

> >+allow $1_lpr_t $1_mozilla_t:tcp_socket { read write };
> >+allow $1_lpr_t $1_mozilla_t:unix_stream_socket { read write };
> >
> >Looks like mozilla is too buggy to close it's file handles before spawning
> >lpr. There's no reason for lpr to access a tcp or unix socket that
> > mozilla has created, they should be dontaudit rules.
>
> Happens when printing from pdf files. Could they be opening a pipe to
> the lpr command?

I can't believe that mozilla would use a TCP socket to send data to lpr. Creating a unix domain socket for it also seems to be a very odd way of doing things that is likely to cause breakage. It would either be a fifo or a temporary file.

Does it work if you replace those allow rules with dontaudit rules?

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page



--
This message was distributed to subscribers of the selinux mailing 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.



text/x-diff attachment: diff