System hang during boot on Debian Sid

System hang during boot on Debian Sid

[Dave Patterson]

With kernel 2.6.13.3 with NSA patch applied the options
CONFIG_DEVPTS_FS_XATTR and CONFIG_DEVPTS_FS_SECURITY disappear.  Or
have gone somewhere...

Compiling while ignoring these two options and booting selinux=1 in
grub I get ...

SELinux initialized (dev sysfs type sysfs) uses genfs contexts

and the system hangs.  Any suggestions?


-- 
Regards, Dave
--

--
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: System hang during boot on Debian Sid

[Stephen Smalley]

On Sun, 2005-10-09 at 15:34 +0700, Dave Patterson wrote:
> With kernel 2.6.13.3 with NSA patch applied the options
> CONFIG_DEVPTS_FS_XATTR and CONFIG_DEVPTS_FS_SECURITY disappear.  Or
> have gone somewhere...
> 
> Compiling while ignoring these two options and booting selinux=1 in
> grub I get ...
> 
> SELinux initialized (dev sysfs type sysfs) uses genfs contexts
> 
> and the system hangs.  Any suggestions?

Those options were obsoleted by the generic VFS fallback for security
xattrs (attempts to get/set security xattrs now fall back automatically
to the security module if the filesystem doesn't support xattrs
natively, so devpts and tmpfs no longer require their own handlers).
That change was included in the 2.6.13-selinux1.patch and is going to be
part of 2.6.14 upstream (already in 2.6.14-rcX, and has been in Fedora
rawhide kernels for a while).

I don't know about the state of SELinux in Debian sid, but Russell's
message indicated that udev doesn't work well with SELinux in Debian
yet.  

-- 
Stephen Smalley
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: System hang during boot on Debian Sid

[Dave Patterson]

* Stephen Smalley <sds@tycho.nsa.gov> [2005-10-11 08:27:38 -0400]:


> > and the system hangs.  Any suggestions?
> 
> That change was included in the 2.6.13-selinux1.patch and is going to be
> part of 2.6.14 upstream (already in 2.6.14-rcX, and has been in Fedora
> rawhide kernels for a while).
Ah. OK... 
> I don't know about the state of SELinux in Debian sid, but Russell's
> message indicated that udev doesn't work well with SELinux in Debian
> yet.  
> 
And I can see why - Debian's initrd is archaic, so I don't use it
unless I have to, and udev in our distro is indeed grumpy.
No, the main cause of my problems so far lie in my policy
configuration at the moment (the boot process was hanging at INIT) -
Russel's package is the strict policy, and I haven't edited it well
enough yet.  I'm attempting a prototype multiuser, multilingual
desktop install using this, and I've banged my shins on a few things so far.
-- 
Regards, Dave
--

--
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: System hang during boot on Debian Sid

[Luke Kenneth Casson Leighton]

On Tue, Oct 11, 2005 at 08:20:02PM +0700, Dave Patterson wrote:
> * Stephen Smalley <sds@tycho.nsa.gov> [2005-10-11 08:27:38 -0400]:
> 
> 
> > > and the system hangs.  Any suggestions?
> > 
> > That change was included in the 2.6.13-selinux1.patch and is going to be
> > part of 2.6.14 upstream (already in 2.6.14-rcX, and has been in Fedora
> > rawhide kernels for a while).
> Ah. OK... 
> > I don't know about the state of SELinux in Debian sid, but Russell's
> > message indicated that udev doesn't work well with SELinux in Debian
> > yet.  
> > 
> And I can see why - Debian's initrd is archaic, so I don't use it
> unless I have to, and udev in our distro is indeed grumpy.
> No, the main cause of my problems so far lie in my policy
> configuration at the moment (the boot process was hanging at INIT) -
> Russel's package is the strict policy, and I haven't edited it well
> enough yet.  I'm attempting a prototype multiuser, multilingual
> desktop install using this, and I've banged my shins on a few things so far.

 yes, you will.

 not least of those will be if you use kdm.

 xdm, kdm, gdm, wdm, all seem to derive from the same codebase at some
 point.  they've been hacked about rather badly since, and the
 authorisation code has been shuffled.

 gdm is fairly sorted (because it's the default on FC) but kdm?  naah.

 the last time i mentioned this, i believe it was russell who mentioned
 that there needs to be some work done in creating a modified policy to
 deal with kdm.

 specifically, there is a part of kdm which communicates via a socket to
 the user desktop bit, which allows kde to shut down the system.

 l.


--
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: System hang during boot on Debian Sid

[Dave Patterson]

* Luke Kenneth Casson Leighton <lkcl@lkcl.net> [2005-10-11 18:05:44 +0100]:

 
>  gdm is fairly sorted (because it's the default on FC) but kdm?  naah.
> 
>  the last time i mentioned this, i believe it was russell who mentioned
>  that there needs to be some work done in creating a modified policy to
>  deal with kdm.
> 
>  specifically, there is a part of kdm which communicates via a socket to
>  the user desktop bit, which allows kde to shut down the system.
> 
Thanks for that - good thing to know as I'm shaking the system down.

-- 
Regards, Dave
--

--
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: System hang during boot on Debian Sid

[Thomas Bleher]

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

* Luke Kenneth Casson Leighton <lkcl@lkcl.net> [2005-10-11 19:16]:
> On Tue, Oct 11, 2005 at 08:20:02PM +0700, Dave Patterson wrote:
> > * Stephen Smalley <sds@tycho.nsa.gov> [2005-10-11 08:27:38 -0400]:
> > 
> > 
> > > > and the system hangs.  Any suggestions?
> > > 
> > > That change was included in the 2.6.13-selinux1.patch and is going to be
> > > part of 2.6.14 upstream (already in 2.6.14-rcX, and has been in Fedora
> > > rawhide kernels for a while).
> > Ah. OK... 
> > > I don't know about the state of SELinux in Debian sid, but Russell's
> > > message indicated that udev doesn't work well with SELinux in Debian
> > > yet.  
> > > 
> > And I can see why - Debian's initrd is archaic, so I don't use it
> > unless I have to, and udev in our distro is indeed grumpy.
> > No, the main cause of my problems so far lie in my policy
> > configuration at the moment (the boot process was hanging at INIT) -
> > Russel's package is the strict policy, and I haven't edited it well
> > enough yet.  I'm attempting a prototype multiuser, multilingual
> > desktop install using this, and I've banged my shins on a few things so far.
> 
>  yes, you will.
> 
>  not least of those will be if you use kdm.
> 
>  xdm, kdm, gdm, wdm, all seem to derive from the same codebase at some
>  point.  they've been hacked about rather badly since, and the
>  authorisation code has been shuffled.
> 
>  gdm is fairly sorted (because it's the default on FC) but kdm?  naah.
> 
>  the last time i mentioned this, i believe it was russell who mentioned
>  that there needs to be some work done in creating a modified policy to
>  deal with kdm.
> 
>  specifically, there is a part of kdm which communicates via a socket to
>  the user desktop bit, which allows kde to shut down the system.

I don't think that's true any longer. I have kdm running here without
special modifications or patches (at least for normal user logins). If
kdm should be able to shutdown the system it needs to have some access
to lilo, but I don't remember completely (could dig it up if you want).
I do not allow my users to shutdown the system from within their session
so I don't know what mods you need for this.

Thomas


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: System hang during boot on Debian Sid

[Valdis.Kletnieks]

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

On Wed, 12 Oct 2005 10:34:30 +0200, Thomas Bleher said:

> special modifications or patches (at least for normal user logins). If
> kdm should be able to shutdown the system it needs to have some access
> to lilo, but I don't remember completely (could dig it up if you want).

lilo? To shutdown the system?  That doesn't sound right...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: System hang during boot on Debian Sid

[Thomas Bleher]

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

* Valdis.Kletnieks@vt.edu [2005-10-12 18:27]:
> On Wed, 12 Oct 2005 10:34:30 +0200, Thomas Bleher said:
> 
> > special modifications or patches (at least for normal user logins). If
> > kdm should be able to shutdown the system it needs to have some access
> > to lilo, but I don't remember completely (could dig it up if you want).
> 
> lilo? To shutdown the system?  That doesn't sound right...

Lilo has a nice feature in that it let's you set the target for the next
boot (lilo -R). Very handy if you want to boot an install kernel or
something like that. KDM supports this interface, so if you have the
appropriate permissions you can select which target to boot via a drop
down menu.
Of course, it gets a bit scary when you look at the needed permissions.
I have this snippet in policy:

# kdm_greet wants this - determine which systems can be booted
allow xdm_t boot_t:dir search;
type xdm_lilo_t, domain, fs_domain, privmem;
domain_auto_trans(xdm_t, bootloader_exec_t, xdm_lilo_t)
role system_r types xdm_lilo_t;
uses_shlib(xdm_lilo_t)
allow xdm_lilo_t boot_t:dir search;
allow xdm_lilo_t { bootloader_etc_t boot_t etc_t }:file { getattr read };
allow xdm_lilo_t boot_t:file write;
allow xdm_lilo_t device_t:dir { getattr search };
allow xdm_lilo_t fixed_disk_device_t:blk_file { getattr read write ioctl };
allow xdm_lilo_t xdm_t:unix_stream_socket { getattr read write };
allow xdm_lilo_t fs_t:filesystem getattr;
allow xdm_lilo_t memory_device_t:chr_file read;
allow xdm_lilo_t self:capability sys_rawio;

Thomas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: System hang during boot on Debian Sid

[Manoj Srivastava]

On Tue, 11 Oct 2005 20:20:02 +0700, Dave Patterson <sdpatt2@gmail.com> said: 

> And I can see why - Debian's initrd is archaic, so I don't use it
> unless I have to, and udev in our distro is indeed grumpy

        Starting with 2.6.14, Debian has moved away from innitrd to
 initramfs (I think currently the default is to prefer yaird).

        manoj
-- 
The greatest of faults is to be conscious of none.
Manoj Srivastava   <manoj.srivastava@stdc.com>    <srivasta@acm.org> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

--
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: System hang during boot on Debian Sid

[Manoj Srivastava]

On Tue, 11 Oct 2005 18:05:44 +0100, Luke Kenneth Casson Leighton <lkcl@lkcl.net> said: 

>  not least of those will be if you use kdm.

>  xdm, kdm, gdm, wdm, all seem to derive from the same codebase at
>  some point.  they've been hacked about rather badly since, and the
>  authorisation code has been shuffled.

        Err. I thought I had submitted patches for xdm, and they had
 been accepted in Debian X. Have the patches been lost in the recent
 X.Org upgrade? If so, I'll have a look and get xdm working again.

        manoj
-- 
What is irritating about love is that it is a crime that requires an
accomplice. Charles Baudelaire
Manoj Srivastava   <manoj.srivastava@stdc.com>    <srivasta@acm.org> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

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