Policy error of the day

Policy error of the day

[Dale Amon]

The policy build error for today is:

ERROR 'unknown type mailman_queue_chkpwd_t' at token ';' on line 81971:
#line 10047
allow mailman_queue_su_t mailman_queue_chkpwd_t:process transition;
/usr/bin/checkpolicy:  error(s) encountered while parsing configuration
make: *** [/etc/security/selinux/policy.15] Error 1

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Russell Coker]

On Thu, 20 Nov 2003 01:47, Dale Amon <amon@vnl.com> wrote:
> The policy build error for today is:
>
> ERROR 'unknown type mailman_queue_chkpwd_t' at token ';' on line 81971:
> #line 10047
> allow mailman_queue_su_t mailman_queue_chkpwd_t:process transition;
> /usr/bin/checkpolicy:  error(s) encountered while parsing configuration
> make: *** [/etc/security/selinux/policy.15] Error 1

The chkpwd changes broke mailman.  I'm not sure whether it's worth trying to 
fix this or whether mailman itself should be fixed instead.  I'll probably do 
a work-around soon.

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

Re: Policy error of the day

[Dale Amon]

On Thu, Nov 20, 2003 at 01:50:21AM +1100, Russell Coker wrote:
> On Thu, 20 Nov 2003 01:47, Dale Amon <amon@vnl.com> wrote:
> > The policy build error for today is:
> >
> > ERROR 'unknown type mailman_queue_chkpwd_t' at token ';' on line 81971:
> > #line 10047
> > allow mailman_queue_su_t mailman_queue_chkpwd_t:process transition;
> > /usr/bin/checkpolicy:  error(s) encountered while parsing configuration
> > make: *** [/etc/security/selinux/policy.15] Error 1
> 
> The chkpwd changes broke mailman.  I'm not sure whether it's worth trying to 
> fix this or whether mailman itself should be fixed instead.  I'll probably do 
> a work-around soon.

Is anything in progress? I've not found a way to get by 
this without going into the end-result disk image and fiddling
things manually, which is a pain. I haven't got any other workaround
because I install packages into the chrooted image like this:

 yes "" | PRIORITY=low DEBIAN_FRONTEND=noninteractive /usr/bin/apt-get -qqqqq -y install "$name" > /dev/null

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Russell Coker]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On Mon, 24 Nov 2003 03:07, Dale Amon <amon@vnl.com> wrote:
> On Thu, Nov 20, 2003 at 01:50:21AM +1100, Russell Coker wrote:
> > On Thu, 20 Nov 2003 01:47, Dale Amon <amon@vnl.com> wrote:
> > > The policy build error for today is:
> > >
> > > ERROR 'unknown type mailman_queue_chkpwd_t' at token ';' on line 81971:
> > > #line 10047
> > > allow mailman_queue_su_t mailman_queue_chkpwd_t:process transition;
> > > /usr/bin/checkpolicy:  error(s) encountered while parsing configuration
> > > make: *** [/etc/security/selinux/policy.15] Error 1
> >
> > The chkpwd changes broke mailman.  I'm not sure whether it's worth trying
> > to fix this or whether mailman itself should be fixed instead.  I'll
> > probably do a work-around soon.
>
> Is anything in progress? I've not found a way to get by
> this without going into the end-result disk image and fiddling
> things manually, which is a pain. I haven't got any other workaround
> because I install packages into the chrooted image like this:

Try the attached policy file.  It compiles, not sure if it works though...

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

[-- Attachment #2: mailman.te --]
[-- Type: text/plain, Size: 3362 bytes --]

#DESC Mailman - GNU Mailman mailing list manager
#
# Author: Russell Coker <russell@coker.com.au>
# X-Debian-Packages: mailman

type mailman_data_t, file_type, sysadmfile;
type mailman_archive_t, file_type, sysadmfile;

type mailman_log_t, file_type, sysadmfile, logfile;
type mailman_lock_t, file_type, sysadmfile, lockfile;

define(`mailman_domain', `
type mailman_$1_t, domain, privlog;
type mailman_$1_exec_t, file_type, sysadmfile, exec_type;
role system_r types mailman_$1_t;
allow mailman_$1_t var_t:dir search;
file_type_auto_trans(mailman_$1_t, var_log_t, mailman_log_t, file)
rw_dir_create_file(mailman_$1_t, mailman_data_t)
uses_shlib(mailman_$1_t)
can_exec_any(mailman_$1_t)
allow mailman_$1_t { proc_t sysctl_t sysctl_kernel_t }:dir search;
allow mailman_$1_t { proc_t sysctl_kernel_t }:file { read getattr };
allow mailman_$1_t var_lib_t:dir { getattr search };
allow mailman_$1_t var_lib_t:lnk_file read;
allow mailman_$1_t device_t:dir search;
allow mailman_$1_t etc_runtime_t:file { read getattr };
read_locale(mailman_$1_t)
file_type_auto_trans(mailman_$1_t, var_lock_t, mailman_lock_t, file)
allow mailman_$1_t fs_t:filesystem getattr;
can_network(mailman_$1_t)
allow mailman_$1_t resolv_conf_t:file { getattr read };
allow mailman_$1_t self:unix_stream_socket create_socket_perms;
allow mailman_$1_t var_t:dir { getattr search };
')

mailman_domain(queue)
can_tcp_connect(mailman_queue_t, mail_server_domain)

can_exec(mailman_queue_t, su_exec_t)
allow mailman_queue_t self:capability setuid;

# some of the following could probably be changed to dontaudit, someone who
# knows mailman well should test this out and send the changes
allow mailman_queue_t sysadm_home_dir_t:dir { getattr search };

mailman_domain(mail)
dontaudit mailman_mail_t mta_delivery_agent:tcp_socket { read write };
allow mailman_mail_t mta_delivery_agent:fd use;
ifdef(`qmail.te', `
allow mailman_mail_t qmail_spool_t:file { read ioctl getattr };
# do we really need this?
allow mailman_mail_t qmail_lspawn_t:fifo_file write;
')

create_dir_file(mailman_queue_t, mailman_archive_t)

ifdef(`apache.te', `
mailman_domain(cgi)
can_tcp_connect(mailman_cgi_t, mail_server_domain)

domain_auto_trans({ httpd_t httpd_suexec_t }, mailman_cgi_exec_t, mailman_cgi_t)
# should have separate types for public and private archives
r_dir_file(httpd_t, mailman_archive_t)
allow httpd_t mailman_data_t:dir search;
r_dir_file(mailman_cgi_t, mailman_archive_t)

dontaudit mailman_cgi_t httpd_log_t:file append;
allow httpd_t mailman_cgi_t:process signal;
allow mailman_cgi_t httpd_t:process sigchld;
allow mailman_cgi_t httpd_t:fd use;
allow mailman_cgi_t httpd_t:fifo_file { getattr read write ioctl };
allow mailman_cgi_t httpd_sys_script_t:dir search;
allow mailman_cgi_t devtty_t:chr_file { read write };
allow mailman_cgi_t self:process { fork sigchld };
')

allow mta_delivery_agent mailman_data_t:dir search;
allow mta_delivery_agent mailman_data_t:lnk_file read;
domain_auto_trans(mta_delivery_agent, mailman_mail_exec_t, mailman_mail_t)
allow mailman_mail_t self:unix_dgram_socket create_socket_perms;

system_crond_entry(mailman_queue_exec_t, mailman_queue_t)
allow mailman_queue_t devtty_t:chr_file { read write };
allow mailman_queue_t self:process { fork signal sigchld };


# so MTA can access /var/lib/mailman/mail/wrapper
allow mta_delivery_agent var_lib_t:dir search;

Policy error of the day

[Dale Amon]

The policy build error for today is:

make: *** No rule to make target `file_contexts/program/redhat-config-users.fc', needed by `file_contexts/file_contexts'.  Stop.
dpkg: error processing selinux-policy-default (--configure):
 subprocess post-installation script returned error exit status 2
Errors were encountered while processing:
 selinux-policy-default
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Policy error of the day

[Dale Amon]

Ah...Russ... did you do something naughty? I note all of these are
failing after the postinst.d/selinux. I wonder if you are 
expecting these installs to be occuring under selinux rather
than on a non-selinux 'factory' machine in a chroot:

run-parts: /etc/dpkg/postinst.d/selinux exited with return code 1
dpkg: error processing selinux-policy-default (--configure):
 1Error running trigger postinst: No such file or directory
run-parts: /etc/dpkg/postinst.d/selinux exited with return code 1
dpkg: error processing modutils (--configure):
 1Error running trigger postinst: No such file or directory
run-parts: /etc/dpkg/postinst.d/selinux exited with return code 1
dpkg: error processing strace (--configure):
 1Error running trigger postinst: No such file or directory
run-parts: /etc/dpkg/postinst.d/selinux exited with return code 1
dpkg: error processing hdparm (--configure):
 1Error running trigger postinst: No such file or directory
run-parts: /etc/dpkg/postinst.d/selinux exited with return code 1
dpkg: error processing dash (--configure):
 1Error running trigger postinst: No such file or directory
run-parts: /etc/dpkg/postinst.d/selinux exited with return code 1
dpkg: error processing cramfsprogs (--configure):
 1Error running trigger postinst: No such file or directory
dpkg: dependency problems prevent configuration of initrd-tools:
 initrd-tools depends on cramfsprogs; however:
  Package cramfsprogs is not configured yet.
 initrd-tools depends on dash | ash; however:
  Package dash is not configured yet.
  Package ash is not installed.
dpkg: error processing initrd-tools (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 selinux-policy-default
 modutils
 strace
 hdparm
 dash
 cramfsprogs
 initrd-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Dale Amon]

On Sat, Nov 29, 2003 at 12:31:20PM +0000, Dale Amon wrote:
> Ah...Russ... did you do something naughty? I note all of these are
> failing after the postinst.d/selinux. I wonder if you are 
> expecting these installs to be occuring under selinux rather
> than on a non-selinux 'factory' machine in a chroot:

I haven't heard back from you. Any ideas on what went
wrong? I can work around it if necessary by putting a
rm postinst.d/selinux in my script at that point so
that package installation doesn't get broken, but
sweeping things under the rug is hardly ever a good 
idea.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Russell Coker]

On Sat, 29 Nov 2003 23:31, Dale Amon <amon@vnl.com> wrote:
> Ah...Russ... did you do something naughty? I note all of these are
> failing after the postinst.d/selinux. I wonder if you are
> expecting these installs to be occuring under selinux rather
> than on a non-selinux 'factory' machine in a chroot:

setfiles is supposed to operate on a non-SE machine.  The current version 
apparently still has the code to check for validity of a context before 
applying it, the plan is to fix this and I thought it was already fixed.  It 
will be fixed soon.

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

Re: Policy error of the day

[Russell Coker]

On Mon, 1 Dec 2003 01:36, Dale Amon <amon@vnl.com> wrote:
> rm postinst.d/selinux in my script at that point so
> that package installation doesn't get broken, but
> sweeping things under the rug is hardly ever a good
> idea.

I don't sweep things under the rug.

Building Debian packages is not difficult.  Getting the source to a package 
and modifying it to work the way you want should be easy enough.

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

Re: Policy error of the day

[Dale Amon]

On Mon, Dec 01, 2003 at 07:10:09AM +1100, Russell Coker wrote:
> On Mon, 1 Dec 2003 01:36, Dale Amon <amon@vnl.com> wrote:
> > rm postinst.d/selinux in my script at that point so
> > that package installation doesn't get broken, but
> > sweeping things under the rug is hardly ever a good
> > idea.
> 
> I don't sweep things under the rug.

Russ, that's not what I said. I said that me doing it in
my script is sweeping it under the rug. 
 
> Building Debian packages is not difficult.  Getting the source to a package 
> and modifying it to work the way you want should be easy enough.

Certainly, if I was only doing this for a one time install
or just for myself. I'm trying to beat on them to 
show up the problems so that someone else who can't sort
in on their own doesn't have to.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Dale Amon]

On Mon, Dec 01, 2003 at 07:08:37AM +1100, Russell Coker wrote:
> setfiles is supposed to operate on a non-SE machine.  The current version 
> apparently still has the code to check for validity of a context before 
> applying it, the plan is to fix this and I thought it was already fixed.  It 
> will be fixed soon.

Thanks. That's the sort of thing I'm trying to shake
out of the system. I'm not getting on you, just pointing
out things so you can find 'em and fix 'em.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Dale Amon]

On Mon, Dec 01, 2003 at 07:08:37AM +1100, Russell Coker wrote:
> setfiles is supposed to operate on a non-SE machine.  The current version 
> apparently still has the code to check for validity of a context before 
> applying it, the plan is to fix this and I thought it was already fixed.  It 
> will be fixed soon.

BTW, this would be doubly good. I'm ever so slowly 
working my way towards a CD and to do so I'll need to
run setfiles in a chroot on a non-selinux machine. If
setfiles could still mark, that would be really good.

I might also note that during much of my builds I 
temporarily replace setfiles with a script that
always returns true; (debootstrap does this also)
I had to do this for a few other things like 
hostname and such or else script mediated package 
installs in a chroot get horrible messed up.

If setfiles can now act reasonably on a non-selinux
build machine, perhaps I should drop the temporary
override?

It would be really nice if I could get by just with a 
policy.15 file instead of needing to write the
disk image to a test machine, boot, label and then
save the disk image.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Dale Amon]

On Sun, Nov 30, 2003 at 09:31:42PM +0000, Dale Amon wrote:
> temporarily replace setfiles with a script that
> always returns true; (debootstrap does this also)
> I had to do this for a few other things like 
> hostname and such or else script mediated package 

Just to avoid misunderstanding since I put the () in
the wrong place. debootstrap overrides hostname and
daemon-start-stop; I do those two PLUS setfiles.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Stephen Smalley]

On Sun, 2003-11-30 at 15:08, Russell Coker wrote:
> setfiles is supposed to operate on a non-SE machine.  The current version 
> apparently still has the code to check for validity of a context before 
> applying it, the plan is to fix this and I thought it was already fixed.  It 
> will be fixed soon.

The fix wasn't in the last public release, but is in our current tree
(and the sourceforge tree).  It checks the errno from a
security_check_context failure to see if it was just ENOENT (i.e.
/selinux/context didn't exist), and doesn't generate an error in that
case.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: Policy error of the day

[Stephen Smalley]

On Mon, 2003-12-01 at 09:27, Stephen Smalley wrote:
> On Sun, 2003-11-30 at 15:08, Russell Coker wrote:
> > setfiles is supposed to operate on a non-SE machine.  The current version 
> > apparently still has the code to check for validity of a context before 
> > applying it, the plan is to fix this and I thought it was already fixed.  It 
> > will be fixed soon.
> 
> The fix wasn't in the last public release, but is in our current tree
> (and the sourceforge tree).  It checks the errno from a
> security_check_context failure to see if it was just ENOENT (i.e.
> /selinux/context didn't exist), and doesn't generate an error in that
> case.

BTW, this doesn't eliminate the need to have an xattr handler for the
security namespace; setfiles cannot work without such a handler in the
kernel.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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

Re: Policy error of the day

[Dale Amon]

On Mon, Dec 01, 2003 at 09:29:59AM -0500, Stephen Smalley wrote:
> BTW, this doesn't eliminate the need to have an xattr handler for the
> security namespace; setfiles cannot work without such a handler in the
> kernel.

Can it deal with a loopback image with xattr, where
it is running in a chroot on a non-selinux system? ie,
can it label the files on the loopback? I thought it
would not be able to without an /selinux and a make
load of the policy before hand, neither of which can
be done in this situation. (ie building an image to
be used on a CDROM)

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Dale Amon]

Stephen: I've sorted out my upgrades so it's time to
get back to the selinux building...

I'm preparing a new kernel for the machine I build on
and have just hesitated over the enabling of xattr's
in the kernel config. I'm pretty sure the file system
won't be automatically affected, but I want to do
a "tell me three times on it" because I simply cannot
afford to make this machine unable to boot under
old kernels.

So, do all swear on a stack of bible and assorted other
holy or unholy books that booting a kernel with xattr ext2
support enabled will *NOT* touch an existing file system 
and make it unuseable in, say a 2.2 kernel?

I would be *most* upset if that were to happen.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Dale Amon]

Actually not as much immediate worry as I thought:
the most important machine is all reiserfs so unless
I build with my xattr patches, it is guaranteed safe.
However I may want to add those patches so I can test
build rfs loop images, so the question still stands...
running into the issue is just delayed a bit.

-- 
------------------------------------------------------
   Dale Amon     amon@islandone.org    +44-7802-188325
       International linux systems consultancy
     Hardware & software system design, security
    and networking, systems programming and Admin
	      "Have Laptop, Will Travel"
------------------------------------------------------

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

Re: Policy error of the day

[Russell Coker]

On Thu, 4 Dec 2003 23:40, Dale Amon <amon@vnl.com> wrote:
> I'm preparing a new kernel for the machine I build on
> and have just hesitated over the enabling of xattr's
> in the kernel config. I'm pretty sure the file system
> won't be automatically affected, but I want to do
> a "tell me three times on it" because I simply cannot
> afford to make this machine unable to boot under
> old kernels.
>
> So, do all swear on a stack of bible and assorted other
> holy or unholy books that booting a kernel with xattr ext2
> support enabled will *NOT* touch an existing file system
> and make it unuseable in, say a 2.2 kernel?

XATTR's don't appear on their own.  You can have a file system driver compiled 
with XATTR options and nothing will happen as long as no programs try to set 
an xattr.  Of course it would only take one program to do this...

In practise I have not found this to be a problem, I've run machines for 
months with XATTR enabled and not had it get used.

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

Re: Policy error of the day

[Stephen Smalley]

On Thu, 2003-12-04 at 07:40, Dale Amon wrote:
> I'm preparing a new kernel for the machine I build on
> and have just hesitated over the enabling of xattr's
> in the kernel config. I'm pretty sure the file system
> won't be automatically affected, but I want to do
> a "tell me three times on it" because I simply cannot
> afford to make this machine unable to boot under
> old kernels.
> 
> So, do all swear on a stack of bible and assorted other
> holy or unholy books that booting a kernel with xattr ext2
> support enabled will *NOT* touch an existing file system 
> and make it unuseable in, say a 2.2 kernel?
> 
> I would be *most* upset if that were to happen.

No promises, but my experience has been that unless you set the
attributes on the filesystem, there is no harm.  I've never had a
problem until _after_ I've run setfiles to label the filesystem.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


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