2.6.0-test3

2.6.0-test3

[Magosányi Árpád]

Hi!

I have a 2.6.0-test3 kernel.
It seems that I have compiled in selinux, and it initializes at boot,
but I cannot use it. What did I done wrong?

The kernel configuration:
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
# CONFIG_SECURITY_SELINUX_MLS is not set

Relevant messages in dmesg:
Security Scaffold v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
There is already a security framework initialized, register_security
failed.
Failure registering capabilities with the kernel
selinux_register_security:  Registering secondary module capability
Capability LSM initialized

The strace of running avc_toggle:
execve("/sbin/avc_toggle", ["avc_toggle"], [/* 20 vars */]) = 0
uname({sys="Linux", node="test42", ...}) = 0
brk(0)                                  = 0x804a000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or
directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=6096, ...}) = 0
old_mmap(NULL, 6096, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40012000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\275Z\1\0004\0\0\0\20\320"..., 1024) = 1024
fstat64(3, {st_mode=S_IFREG|0755, st_size=1104040, ...}) = 0
old_mmap(NULL, 1113796, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0x40014000
mprotect(0x4011c000, 32452, PROT_NONE)  = 0
old_mmap(0x4011c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x107000) = 0x4011c000
old_mmap(0x40122000, 7876, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40122000
close(3)                                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40124000
munmap(0x40012000, 6096)                = 0
security(0xf97cff8c, 0xb, 0, 0x400098bc, 0xbffffb54) = -1 ENOSYS
(Function not implemented)
dup(2)                                  = 3
fcntl64(3, F_GETFL)                     = 0x8002 (flags
O_RDWR|O_LARGEFILE)
brk(0)                                  = 0x804a000
brk(0x804b000)                          = 0x804b000
brk(0)                                  = 0x804b000
fstat64(3, {st_mode=S_IFCHR|0666, st_rdev=makedev(4, 2), ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0x40012000
_llseek(3, 0, 0xbffff920, SEEK_CUR)     = -1 ESPIPE (Illegal seek)
write(3, "avc_toggle: Function not implemented\n", 37) = 37
close(3)                                = 0
munmap(0x40012000, 4096)                = 0
exit_group(0)                           = ?

Package: selinux
Priority: optional
Section: admin
Installed-Size: 5390
Maintainer: Russell Coker <russell@coker.com.au>
Architecture: i386
Source: selinux-small
Version: 2003071106-1
Provides: flask
Depends: libc6 (>= 2.3.1-1), libpam0g (>= 0.76), expect (>= 5.38.0-3)
Recommends: selinux-policy
Conflicts: flask, devfsd (<< 1.3.25-6)
Filename: pool/main/s/selinux-small/selinux_2003071106-1_i386.deb
Size: 2155622
MD5sum: 4048f92a0f22b77cc06236d0e6f49235
Description: Management utilities for NSA Security Enhanced Linux
 SE Linux is a system for adding Mandatory Access Control to Linux.  It
uses
 Domain Type control as well as Role Based control.  This package
provides
 all the base utilities for controlling it.



-- 
GNU GPL: csak tiszta forrásbó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: 2.6.0-test3

[Russell Coker]

On Thu, 21 Aug 2003 22:29, Magosányi Árpád wrote:
> I have a 2.6.0-test3 kernel.
> It seems that I have compiled in selinux, and it initializes at boot,
> but I cannot use it. What did I done wrong?

The 2.6.0 kernel (and the kernel-patch I recently uploaded known as "lsm2" in 
the kernel-patch-2.4-lsm package) have a new version of SE Linux.

This new version of SE Linux does not use the sys_security system call, and 
therefore any application compiled for the old SE Linux which uses that call 
(such as avc_toggle) will fail.

Colin Walters is doing most of the work for the new SE Linux in Debian at the 
moment.  Unfortunately my 2.6.0 work has not progressed far enough for me to 
be able to advise you on how to do it right at this time.  Hopefully Colin 
will be able to help.

The #selinux channel on irc.debian.org may help you too, there are a number of 
people there who are experimenting with 2.6.0 who can probably give you some 
pointers.

Finally before anyone asks, UML and SE Linux should work with kernel 
2.6.0test3 if you use the one line patch suggested by Steve.  However for me 
it doesn't work at all, there are several different kernel bugs which get in 
the way.  I am looking forward to 2.6.0test4, test3 seems too flakey.

For the new SE Linux you are probably better off using the back-port to 
2.4.21.

-- 
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: 2.6.0-test3

[Dale Amon]

On Thu, Aug 21, 2003 at 11:37:59PM +1000, Russell Coker wrote:
> This new version of SE Linux does not use the sys_security system call, and 
> therefore any application compiled for the old SE Linux which uses that call 
> (such as avc_toggle) will fail.

Ouch. I'm just in the process of setting up a 2.6.0 test system
to check out the "mainstream" selinux.

Are there compilable apps on the NSA sight that will work with
a vanilla 2.6.0-test3?


--
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: 2.6.0-test3

[Colin Walters]

On Thu, 2003-08-21 at 09:37, Russell Coker wrote:

> This new version of SE Linux does not use the sys_security system call, and 
> therefore any application compiled for the old SE Linux which uses that call 
> (such as avc_toggle) will fail.
> 
> Colin Walters is doing most of the work for the new SE Linux in Debian at the 
> moment.  Unfortunately my 2.6.0 work has not progressed far enough for me to 
> be able to advise you on how to do it right at this time.  Hopefully Colin 
> will be able to help.

My 2.6.0 Debian packages are here:

http://web.verbum.org/debian/experimental/

I have been busy with some other things and haven't had a chance to
update my packages recently.  I know at least coreutils, pam, and passwd
all have higher versions in unstable now.

Eventually, I'd like to not have to use any packages outside of unstable
at all.  Russell, what do you think about starting to send these patches
to the Debian package maintainers and get them integrated?  At least the
Debian coreutils package already applies over 50 patches, one more
wouldn't hurt :)
The only drawback I see is a dependency on libselinux, but it's so small
anyways.


--
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: 2.6.0-test3

[Stephen Smalley]

On Thu, 2003-08-21 at 13:25, Dale Amon wrote:
> Ouch. I'm just in the process of setting up a 2.6.0 test system
> to check out the "mainstream" selinux.
> 
> Are there compilable apps on the NSA sight that will work with
> a vanilla 2.6.0-test3?

The NSA site includes userland components ported to the new SELinux API
(and updated to the RH9 packages).  The userland port was mostly done by
Dan Walsh of RedHat.  Note that the new SELinux API and xattr support
was also back ported to the 2.4-based SELinux, so the same userland can
be used with the newer 2.4-based SELinux.  The older 2.4-based SELinux
is no longer being actively maintained, and will be moved to a
historical versions page along with the original SELinux in future
releases.  See http://www.nsa.gov/selinux/download5.html for the
2.6-based SELinux or http://www.nsa.gov/selinux/download3.html for the
new 2.4-based SELinux.  Colin Walters has worked on porting and
packaging the new components for Debian, so you may want to use his
packages if you are using Debian.

Note that there have been some patches to the SELinux module since
2.6.0-test3; there is a patch on the NSA site that includes some of
those changes, but we have also fed further changes up to Andrew Morton
since the last public release on the NSA site, and they are now in
Linus' BitKeeper tree as well.

-- 
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: 2.6.0-test3

[Brian May]

On Thu, Aug 21, 2003 at 01:40:23PM -0400, Colin Walters wrote:
> Eventually, I'd like to not have to use any packages outside of unstable
> at all.  Russell, what do you think about starting to send these patches
> to the Debian package maintainers and get them integrated?  At least the
> Debian coreutils package already applies over 50 patches, one more
> wouldn't hurt :)
> The only drawback I see is a dependency on libselinux, but it's so small
> anyways.

Does the libselinux in unstable support the 2.6 interface yet?
-- 
Brian May <bam@snoopy.apana.org.au>

--
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: 2.6.0-test3

[Russell Coker]

On Fri, 22 Aug 2003 03:25, Dale Amon wrote:
> On Thu, Aug 21, 2003 at 11:37:59PM +1000, Russell Coker wrote:
> > This new version of SE Linux does not use the sys_security system call,
> > and therefore any application compiled for the old SE Linux which uses
> > that call (such as avc_toggle) will fail.
>
> Ouch. I'm just in the process of setting up a 2.6.0 test system
> to check out the "mainstream" selinux.
>
> Are there compilable apps on the NSA sight that will work with
> a vanilla 2.6.0-test3?

Yes, they have a complete release with patched applications.

However those of us who use different versions of the relevant applications, 
or who use alternate programs will have some coding to do.  Also the process 
of upgrading from old SE Linux to new SE Linux will be slightly more 
difficult than doing a fresh install of SE Linux...  :(

-- 
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: 2.6.0-test3

[Russell Coker]

On Fri, 22 Aug 2003 03:40, Colin Walters wrote:
> Eventually, I'd like to not have to use any packages outside of unstable
> at all.  Russell, what do you think about starting to send these patches
> to the Debian package maintainers and get them integrated?  At least the
> Debian coreutils package already applies over 50 patches, one more
> wouldn't hurt :)

I think it's a great idea.

In fact I will move my old-SE Linux packages out of Debian.  Anyone who wants 
backward compatability can use my personal site, and your packages for 2.6 
etc can go into main.

I will continue to maintain the policy package however.

Colin, I suggest that you resist the temptation to upload a "selinux" package 
which depends on all your packages.  Make your packages conflict/replace 
selinux.

I will file the bug report requesting that my selinux-small packages be 
removed from main and that your packages replace them.

-- 
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: 2.6.0-test3

[Brian May]

On Fri, Aug 22, 2003 at 12:04:56PM +1000, Russell Coker wrote:
> However those of us who use different versions of the relevant applications, 
> or who use alternate programs will have some coding to do.  Also the process 
> of upgrading from old SE Linux to new SE Linux will be slightly more 
> difficult than doing a fresh install of SE Linux...  :(

What is required to upgrade?

I assume the biggest problem will be the file labels?
-- 
Brian May <bam@snoopy.apana.org.au>

--
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: 2.6.0-test3

[Russell Coker]

On Fri, 22 Aug 2003 14:53, Brian May wrote:
> On Fri, Aug 22, 2003 at 12:04:56PM +1000, Russell Coker wrote:
> > However those of us who use different versions of the relevant
> > applications, or who use alternate programs will have some coding to do. 
> > Also the process of upgrading from old SE Linux to new SE Linux will be
> > slightly more difficult than doing a fresh install of SE Linux...  :(
>
> What is required to upgrade?
>
> I assume the biggest problem will be the file labels?

Firstly you have to install a kernel with the new SE Linux support and boot 
it.  Then you have to install the utilities that match the new kernel (after 
which you can't go back).  Then you install the policy, label the file 
systems, and reboot.  Then you do another relabel after the reboot for any 
files that were created by shutdown (presuming that nothing went wrong and 
you have a bootable system that allows you to login).

Much the same as installing SE Linux on a non-SE machine.

-- 
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: 2.6.0-test3

[Russell Coker]

On Fri, 22 Aug 2003 14:53, Brian May wrote:
> On Fri, Aug 22, 2003 at 12:04:56PM +1000, Russell Coker wrote:
> > However those of us who use different versions of the relevant
> > applications, or who use alternate programs will have some coding to do. 
> > Also the process of upgrading from old SE Linux to new SE Linux will be
> > slightly more difficult than doing a fresh install of SE Linux...  :(
>
> What is required to upgrade?
>
> I assume the biggest problem will be the file labels?

Steve tells me that it is not possible to create appropriate XATTR's without 
having an in-kernel handler for them.  So unless some code is ported from 
2.6.0 or the new SE Linux version for 2.4.21 to the old 2.4.21 then it will 
not be possible to migrate them.

Only /home should be a problem here, the rest can usually be regenerated from 
file_contexts anyway.


Russell Coker


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

general security lib (was: 2.6.0-test3)

[Magosányi Árpád]

2003-08-21, cs keltezéssel Colin Walters ezt írta:
> at all.  Russell, what do you think about starting to send these patches
> to the Debian package maintainers and get them integrated?  At least the

It might be the least unconvenient solution for the short run.

But for the long run it would be better if the upstream maintainers
would integrate support for the userspace security API. And they
won't necessarily like that they should use separate code for
selinux, rsbac, etc. It means that there should be a general
security lib. I now think that the current API of libselinux is
good, only the inside workings should be made more general, to
make it possible to plug other modules in.
The approach is described in
http://reality.sgiweb.org/offer/papers/PACM/
in the rationale paper.


-- 
GNU GPL: csak tiszta forrásbó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: 2.6.0-test3

[Russell Coker]

On Fri, 22 Aug 2003 08:32, Brian May wrote:
> Does the libselinux in unstable support the 2.6 interface yet?

Colin is about to upload a new libselinux for 2.6 and the 2.4 back-port...

-- 
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: general security lib (was: 2.6.0-test3)

[Stephen Smalley]

On Fri, 2003-08-22 at 08:38, Magosányi Árpád wrote:
> But for the long run it would be better if the upstream maintainers
> would integrate support for the userspace security API. And they
> won't necessarily like that they should use separate code for
> selinux, rsbac, etc. It means that there should be a general
> security lib. I now think that the current API of libselinux is
> good, only the inside workings should be made more general, to
> make it possible to plug other modules in.
> The approach is described in
> http://reality.sgiweb.org/offer/papers/PACM/
> in the rationale paper.

RSBAC isn't a good motivating example, as it doesn't include patches for
userspace, and its author seemed specifically inclined against patching
userspace for RSBAC.

I don't quite follow your argument; if you agree that the SELinux API is
good and that we just need to modularize the libselinux implementation,
then what is your objection to the coreutils patch, which simply invokes
the API?  

-- 
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: 2.6.0-test3

[Stephen Smalley]

On Fri, 2003-08-22 at 00:53, Brian May wrote:
> On Fri, Aug 22, 2003 at 12:04:56PM +1000, Russell Coker wrote:
> > However those of us who use different versions of the relevant applications, 
> > or who use alternate programs will have some coding to do.  Also the process 
> > of upgrading from old SE Linux to new SE Linux will be slightly more 
> > difficult than doing a fresh install of SE Linux...  :(
> 
> What is required to upgrade?
> 
> I assume the biggest problem will be the file labels?

The migration to xattr and the overhaul of the SELinux API make an
upgrade more complicated than a typical SELinux upgrade.  See the
selinux-doc README for detailed installation instructions for the new
SELinux, and the selinux-doc PORTING for notes on porting SELinux-aware
applications and SELinux policy configurations from the old SELinux. 
Also, the slides from the 2003 OLS SELinux BOF available from the NSA
site have some notes about the changes to SELinux.

Upgrading a production system running the old SELinux is complicated by
the fact that you would like to be able to upgrade the system while
still in enforcing mode, and immediately transition to the new SELinux
(also in enforcing mode) so that the system remains in a secure state
throughout.  To do this, you would need to set the xattr values before
you first boot the new SELinux kernel if you want it to successfully
boot in enforcing mode, but you cannot set the xattr values until you
have a kernel that includes the xattr handler. So you would need to back
port the xattr handler to the old SELinux kernel (and merge the EA patch
from acl.bestbits.at into it) so that you can set the values while still
running the old SELinux code.  This is possible, but would take a little
work by someone.  There are also the usual policy issues with upgrading
a live system and the issues created by the API incompatibility between
the old and new SELinux.

Some caveats about upgrading to the new SELinux, also noted in the
selinux-doc files:
1) It relies on xattr support in the filesystem and an xattr handler for
the security namespace in the filesystem.  We have only implemented such
handlers for ext[23] as well as a "pseudo" handler for devpts to support
relabeling of ptys.  If you are using another filesystem type, e.g.
reiserfs, you'll need to apply the reiser xattr patches developed by
others and add a specific handler for the security namespace.  Also,
note that the support for genfs_contexts has been greatly reduced; the
problem is that mapping an inode to a pathname is not generally
supportable in the kernel except in specialized cases like proc.  We can
work on restoring support for other filesystem types on a case-by-case
basis if a reliable means can be found for performing such mappings for
that filesystem type.  devfs appears to be obsolete, so it isn't likely
worth spending time on reviving support for it.

2) We have found that vanilla 2.4 kernels will no longer boot after you
have assigned the SELinux EAs to the root filesystem.  2.4 kernels
patched with the EA patch from acl.bestbits.at will boot fine and
vanilla 2.6 kernels will boot fine.  The underlying cause is still being
investigated.  You may want to have a 2.4+EA kernel or a vanilla 2.6
kernel (with EA support enabled) available as a fallback to perform
emergency recovery and manual correction of xattr values.

3) The initial policy load has been moved into userspace and is
performed from an initrd.  You must build an initrd that includes the
new load_policy utility and a copy of your binary policy and that
performs the initial policy load before the real root filesystem is
mounted.  See the selinux-doc README for a sample patch to mkinitrd to
do this.

4) The SELinux network access controls (but not the socket access
controls) have been temporarily dropped, as the implementation depended
on the LSM networking security fields and hooks that were rejected for
mainline 2.5.  We plan on restoring a subset of the original
functionality in the future using only the set of hooks that were
accepted plus NetFilter, as well as revisiting the set of permission
checks to provide more effective controls.

-- 
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: 2.6.0-test3

[Dale Amon]

On Fri, Aug 22, 2003 at 03:44:31PM +1000, Russell Coker wrote:
> On Fri, 22 Aug 2003 14:53, Brian May wrote:
> > On Fri, Aug 22, 2003 at 12:04:56PM +1000, Russell Coker wrote:
> > > However those of us who use different versions of the relevant
> > > applications, or who use alternate programs will have some coding to do. 
> > > Also the process of upgrading from old SE Linux to new SE Linux will be
> > > slightly more difficult than doing a fresh install of SE Linux...  :(
> >
> > What is required to upgrade?
> >
> > I assume the biggest problem will be the file labels?
> 
> Steve tells me that it is not possible to create appropriate XATTR's without 
> having an in-kernel handler for them.  So unless some code is ported from 
> 2.6.0 or the new SE Linux version for 2.4.21 to the old 2.4.21 then it will 
> not be possible to migrate them.
> 
> Only /home should be a problem here, the rest can usually be regenerated from 
> file_contexts anyway.

Hmmm... I'm having problems with your default file. Note that I've got a
2.4.22rc2 kernel. The dependency kills it. I presume this means I have to
drop back to your orig file and do it all manually?

dpkg --install selinux-policy-default_1.1-1_all.deb 
Selecting previously deselected package selinux-policy-default.
dpkg: regarding selinux-policy-default_1.1-1_all.deb containing selinux-policy-default, pre-dependency problem:
 selinux-policy-default pre-depends on selinux (>= 2003081307-2)
dpkg: error processing selinux-policy-default_1.1-1_all.deb (--install):
 pre-dependency problem - not installing selinux-policy-default


--
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: 2.6.0-test3

[Russell Coker]

On Fri, 22 Aug 2003 23:02, Stephen Smalley wrote:
> Upgrading a production system running the old SELinux is complicated by
> the fact that you would like to be able to upgrade the system while
> still in enforcing mode, and immediately transition to the new SELinux
> (also in enforcing mode) so that the system remains in a secure state
> throughout.  To do this, you would need to set the xattr values before
> you first boot the new SELinux kernel if you want it to successfully
> boot in enforcing mode, but you cannot set the xattr values until you
> have a kernel that includes the xattr handler. So you would need to back
> port the xattr handler to the old SELinux kernel (and merge the EA patch
> from acl.bestbits.at into it) so that you can set the values while still
> running the old SELinux code.  This is possible, but would take a little
> work by someone.

I get the impression that no-one at the NSA has the time to spare for 
back-porting the xattr handler, and it seems that everyone else who could do 
it is also focussed on 2.6.0.  So it looks like this isn't going to happen.

Also just writing the xattr handler would not be enough, you would need a 
program that can read SIDs and then write equivalent xattrs, it shouldn't be 
difficult but it's another thing that has to be done.

Finally you would need wrapper programs for login, sshd, etc that check which 
version of SE Linux is running and execute the correct version of the program 
to match (but this is easy to do).

> There are also the usual policy issues with upgrading
> a live system and the issues created by the API incompatibility between
> the old and new SELinux.

I think I've solved the policy issues.  I've got a policy tree which should 
work on both old-style and new-style SE Linux.  It's only tested on old-style 
however, but if there are any bugs then I expect them to be small.

> relabeling of ptys.  If you are using another filesystem type, e.g.
> reiserfs, you'll need to apply the reiser xattr patches developed by
> others and add a specific handler for the security namespace.  Also,

SUSE developed the ReiserFS xattr patches.  However they will not be merged 
into the main ReiserFS tree, Hans recommends waiting for ReiserFS v4 for 
xattr support.  :-#

> 2) We have found that vanilla 2.4 kernels will no longer boot after you
> have assigned the SELinux EAs to the root filesystem.  2.4 kernels
> patched with the EA patch from acl.bestbits.at will boot fine and
> vanilla 2.6 kernels will boot fine.  The underlying cause is still being
> investigated.  You may want to have a 2.4+EA kernel or a vanilla 2.6
> kernel (with EA support enabled) available as a fallback to perform
> emergency recovery and manual correction of xattr values.

NB  In my kernel patch package for Debian I have ported the LSM patch to 
operate with the ACL patch, and installing the LSM patch will also get the 
ACL patch.  So Debian users who build a kernel with a version of my patch 
package of 2003.07.11-2 (Aug 5) or later will be able to boot from their 2.4 
kernel if the upgrade fails.

-- 
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: general security lib (was: 2.6.0-test3)

[Stephen Smalley]

On Fri, 2003-08-22 at 08:38, Magosányi Árpád wrote:
> The approach is described in
> http://reality.sgiweb.org/offer/papers/PACM/
> in the rationale paper.

By the way, I get a bit weary of people referring to this proposal as if
it predates SELinux or is more general than the SELinux API.  Neither is
true.  The PACM reports were written after SELinux had already been
released, along with the original SELinux API, documentation describing
that API, and extensive reports analyzing the generality of the
interface and framework for SELinux's predecessors (see the DTOS
reports, linked from the SELinux Background page).  Yet the PACM reports
do not appear to draw from the SELinux API or evaluate how the PACM API
compares with it, and the end result is that the PACM API cannot even
support the requirements of the SELinux API.

-- 
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: general security lib (was: 2.6.0-test3)

[Russell Coker]

On Fri, 22 Aug 2003 22:38, Magosányi Árpád wrote:
> 2003-08-21, cs keltezéssel Colin Walters ezt írta:
> > at all.  Russell, what do you think about starting to send these patches
> > to the Debian package maintainers and get them integrated?  At least the
>
> It might be the least unconvenient solution for the short run.
>
> But for the long run it would be better if the upstream maintainers
> would integrate support for the userspace security API. And they

A modification to PAM could allow the sshd, login, and cron patches to go 
away.

Theodore Ts'o suggested to me that a new PAM call be added to run the shell 
which takes appropriate parameters about user-name etc.  Then a SE Linux 
version of this module could change the security context appropriately, thus 
requiring only one copy of the code to determine the context to use, and not 
requiring any on-going modification to applications.

This design concept sounds really good, and as it's Ted's suggestion I don't 
expect any great resistance to accepting the patch upstream once it's been 
tested and proven to work.

I've been meaning to work on this for almost a year, I might start work next 
week.

-- 
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: 2.6.0-test3

[Stephen Smalley]

On Fri, 2003-08-22 at 09:21, Russell Coker wrote:
> I get the impression that no-one at the NSA has the time to spare for 
> back-porting the xattr handler, and it seems that everyone else who could do 
> it is also focussed on 2.6.0.  So it looks like this isn't going to happen.

It really wouldn't be difficult to do, and certainly doesn't require any
deep SELinux or xattr knowledge.  Just copy fs/ext3/xattr_security.c and
the related changes to fs/ext3/{Makefile,super.c} and fs/Config.in from
the new 2.4-based SELinux to the old 2.4-based SELinux.  Of course, you
do need to merge the EA patch from acl.bestbits.at as well, but that
also shouldn't be too difficult.

> Also just writing the xattr handler would not be enough, you would need a 
> program that can read SIDs and then write equivalent xattrs, it shouldn't be 
> difficult but it's another thing that has to be done.

If you simply want to set the xattrs from the file contexts
configuration, you can just run the new setfiles program.  If you want
to set the xattrs from the persistent label mapping, then you would need
to restore the psid code to the new setfiles program and adjust it to
get the value from the mapping and set the xattr from it.  Not
difficult, but a little bit of work.

> Finally you would need wrapper programs for login, sshd, etc that check which 
> version of SE Linux is running and execute the correct version of the program 
> to match (but this is easy to do).

Not clear if this is necessary, unless you want to be able to switch
back and forth.  If you just want to upgrade, you should be able to just
install the new versions while running the old kernel (since this won't
affect already running instances) and then immediately boot the new
kernel.

> SUSE developed the ReiserFS xattr patches.  However they will not be merged 
> into the main ReiserFS tree, Hans recommends waiting for ReiserFS v4 for 
> xattr support.  :-#

I'm not sure about this guidance, as reiser4 isn't in mainline yet, and
last I looked at the reiser4 code, it did NOT include any xattr support
or handlers.  Using the SuSE xattr patches for reiser seems to be the
only real option for current reiser users.

> NB  In my kernel patch package for Debian I have ported the LSM patch to 
> operate with the ACL patch, and installing the LSM patch will also get the 
> ACL patch.  So Debian users who build a kernel with a version of my patch 
> package of 2003.07.11-2 (Aug 5) or later will be able to boot from their 2.4 
> kernel if the upgrade fails.

It should then be a very easy task to transfer over the xattr_security.c
handlers and the corresponding changes from the new 2.4-based SELinux to
your patch so that the older SELinux can access the xattrs.

-- 
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: 2.6.0-test3

[Russell Coker]

On Sat, 23 Aug 2003 00:17, Stephen Smalley wrote:
> On Fri, 2003-08-22 at 09:21, Russell Coker wrote:
> > I get the impression that no-one at the NSA has the time to spare for
> > back-porting the xattr handler, and it seems that everyone else who could
> > do it is also focussed on 2.6.0.  So it looks like this isn't going to
> > happen.
>
> It really wouldn't be difficult to do, and certainly doesn't require any
> deep SELinux or xattr knowledge.  Just copy fs/ext3/xattr_security.c and
> the related changes to fs/ext3/{Makefile,super.c} and fs/Config.in from
> the new 2.4-based SELinux to the old 2.4-based SELinux.  Of course, you
> do need to merge the EA patch from acl.bestbits.at as well, but that
> also shouldn't be too difficult.

That sounds positive.  I've already merged the EA patch, so I'll probably give 
it a go next week.

> > Also just writing the xattr handler would not be enough, you would need a
> > program that can read SIDs and then write equivalent xattrs, it shouldn't
> > be difficult but it's another thing that has to be done.
>
> If you simply want to set the xattrs from the file contexts
> configuration, you can just run the new setfiles program.  If you want
> to set the xattrs from the persistent label mapping, then you would need
> to restore the psid code to the new setfiles program and adjust it to
> get the value from the mapping and set the xattr from it.  Not
> difficult, but a little bit of work.

True.  Actually I was thinking of writing a custom utility that gets the 
context using the old API and writes it as xattrs.

> > Finally you would need wrapper programs for login, sshd, etc that check
> > which version of SE Linux is running and execute the correct version of
> > the program to match (but this is easy to do).
>
> Not clear if this is necessary, unless you want to be able to switch
> back and forth.  If you just want to upgrade, you should be able to just
> install the new versions while running the old kernel (since this won't
> affect already running instances) and then immediately boot the new
> kernel.

The problem here is that upgrades don't always work correctly.  I really don't 
want to go into an upgrade without without an escape route!

> > SUSE developed the ReiserFS xattr patches.  However they will not be
> > merged into the main ReiserFS tree, Hans recommends waiting for ReiserFS
> > v4 for xattr support.  :-#
>
> I'm not sure about this guidance, as reiser4 isn't in mainline yet, and
> last I looked at the reiser4 code, it did NOT include any xattr support
> or handlers.  Using the SuSE xattr patches for reiser seems to be the
> only real option for current reiser users.

Your comments make sense to me.  However Hans' opinions on this matter are 
authoritative, and leave us with a choice of maintaining yet another kernel 
patch (ACL, LSM, and a ReiserFS patch) in our trees which is more work and 
more risk of bugs, or of not using ReiserFS in this way.

I feel that for my machines my best option is to cease using ReiserFS.

-- 
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: general security lib (was: 2.6.0-test3)

[Stephen Smalley]

On Fri, 2003-08-22 at 10:09, Russell Coker wrote:
> A modification to PAM could allow the sshd, login, and cron patches to go 
> away.
> 
> Theodore Ts'o suggested to me that a new PAM call be added to run the shell 
> which takes appropriate parameters about user-name etc.  Then a SE Linux 
> version of this module could change the security context appropriately, thus 
> requiring only one copy of the code to determine the context to use, and not 
> requiring any on-going modification to applications.
> 
> This design concept sounds really good, and as it's Ted's suggestion I don't 
> expect any great resistance to accepting the patch upstream once it's been 
> tested and proven to work.
> 
> I've been meaning to work on this for almost a year, I might start work next 
> week.

If you investigate this idea, be sure to work from the new SELinux
patches that use the new SELinux API, not the old one.  Note that the
new SELinux API is better suited to encapsulation within PAM, since the
exec context is now an attribute of the process that can be set prior to
the execve call.  PAM could call setexeccon() when it ordinarily sets
the user's credentials.  This avoids the need to create a new PAM call,
or to alter the execve call itself.

While you may be able to move the setup of the user execution context
into PAM, there are other elements of the SELinux patches as well, such
as the labeling of the tty/pty and the entrypoint check for cron jobs. 
Hence, I suspect that we will still need some kind of patch for
login/sshd/crond, albeit a smaller one. 

-- 
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: general security lib (was: 2.6.0-test3)

[Daniel J Walsh]

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

Also how would you allow the user to select the context they will login 
as if there are more then one?  Unless we remove this capability and 
always force users to use newrole.

Dan

Stephen Smalley wrote:

>On Fri, 2003-08-22 at 10:09, Russell Coker wrote:
>  
>
>>A modification to PAM could allow the sshd, login, and cron patches to go 
>>away.
>>
>>Theodore Ts'o suggested to me that a new PAM call be added to run the shell 
>>which takes appropriate parameters about user-name etc.  Then a SE Linux 
>>version of this module could change the security context appropriately, thus 
>>requiring only one copy of the code to determine the context to use, and not 
>>requiring any on-going modification to applications.
>>
>>This design concept sounds really good, and as it's Ted's suggestion I don't 
>>expect any great resistance to accepting the patch upstream once it's been 
>>tested and proven to work.
>>
>>I've been meaning to work on this for almost a year, I might start work next 
>>week.
>>    
>>
>
>If you investigate this idea, be sure to work from the new SELinux
>patches that use the new SELinux API, not the old one.  Note that the
>new SELinux API is better suited to encapsulation within PAM, since the
>exec context is now an attribute of the process that can be set prior to
>the execve call.  PAM could call setexeccon() when it ordinarily sets
>the user's credentials.  This avoids the need to create a new PAM call,
>or to alter the execve call itself.
>
>While you may be able to move the setup of the user execution context
>into PAM, there are other elements of the SELinux patches as well, such
>as the labeling of the tty/pty and the entrypoint check for cron jobs. 
>Hence, I suspect that we will still need some kind of patch for
>login/sshd/crond, albeit a smaller one. 
>
>  
>

[-- Attachment #2: Type: text/html, Size: 2130 bytes --]

Re: 2.6.0-test3

[Colin Walters]

On Fri, 2003-08-22 at 08:44, Russell Coker wrote:
> On Fri, 22 Aug 2003 08:32, Brian May wrote:
> > Does the libselinux in unstable support the 2.6 interface yet?
> 
> Colin is about to upload a new libselinux for 2.6 and the 2.4 back-port...

I just uploaded 1.1 last night, it's waiting in queue/NEW.

--
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: general security lib (was: 2.6.0-test3)

[Colin Walters]

Stephen,

What do you think about Magosányi's point of sending more of these
patches upstream?

At least some projects like openssh have active upstreams with an
interest in security, so I think they would be receptive.

Other stuff like cron is unfortunately basically unmaintained, so
there's not much we can do there.



--
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: general security lib (was: 2.6.0-test3)

[Stephen Smalley]

On Fri, 2003-08-22 at 13:51, Colin Walters wrote:
> Stephen,
> 
> What do you think about Magosányi's point of sending more of these
> patches upstream?
> 
> At least some projects like openssh have active upstreams with an
> interest in security, so I think they would be receptive.
> 
> Other stuff like cron is unfortunately basically unmaintained, so
> there's not much we can do there.

Yes, this would likely be worthwhile, given that the mainline kernel now
provides the necessary support for the new SELinux API and the SELinux
patches have been ported to the new API.  There are some likely
conflicts that would have to be resolved:

1) OpenSSH may want a patch written to a common API that can be mapped
to either the SELinux API or the TrustedBSD API.

2) Patches that deal with managing file security contexts may overlap
with the generic xattr patches from acl.bestbits.at.  Unfortunately, the
generic xattr patches don't support an aspect of the SELinux API - the
ability to create a file with a specified security context (using
setfscreatecon prior to the file creation) rather than just using a
default inheritance model based on the parent directory.  This
distinction is security-relevant, as the generic xattr patches will
leave files temporarily in a security label that may be less restrictive
than the final target security label.  Note that our patches make
extensive use of setfscreatecon(), whereas the xattr patches simply set
the label after the file has already been created (when it may be too
late).

-- 
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: general security lib (was: 2.6.0-test3)

[Russell Coker]

On Sat, 23 Aug 2003 03:21, Daniel J Walsh wrote:
> Also how would you allow the user to select the context they will login
> as if there are more then one?  Unless we remove this capability and
> always force users to use newrole.

Firstly, this decision is not currently available in a regular ssh 
configuration or for cron.  So such a PAM module would easily allow the use 
of unmodified sshd and cron programs once support for the new PAM had been 
added.

As for login, I am under the impression that there is a possibility for a 
dialog between application and PAM module, so the PAM module could specify 
text to display and the application could return an answer to it.  But I 
haven't done any PAM coding yet so I'm not sure of this.

-- 
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: general security lib (was: 2.6.0-test3)

[Russell Coker]

On Sat, 23 Aug 2003 00:32, Stephen Smalley wrote:
> If you investigate this idea, be sure to work from the new SELinux
> patches that use the new SELinux API, not the old one.  Note that the
> new SELinux API is better suited to encapsulation within PAM, since the
> exec context is now an attribute of the process that can be set prior to

I want to devise a suitable generic solution that it can be accepted into the 
PAM distribution.  Anything that can't support both old and new SE Linux APIs 
probably isn't nearly generic 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: general security lib (was: 2.6.0-test3)

[Brian May]

On Sat, Aug 23, 2003 at 03:06:01PM +1000, Russell Coker wrote:
> As for login, I am under the impression that there is a possibility for a 
> dialog between application and PAM module, so the PAM module could specify 
> text to display and the application could return an answer to it.  But I 
> haven't done any PAM coding yet so I'm not sure of this.

I believe you are correct, the PAM module can ask any number of
questions which the application then has to ask. It is very flexible.
Perhaps too flexible, as it doesn't work well with fixed protocols
like the fixed password authentication protocol in sshd.

Last I heard, sshd had to be hacked to work with PAM, because the sshd
protocol doesn't support asking a undetermined number of questions as
required by PAM, in fact, the basic password authentication protocol
supports only one field: password.

IIRC, once the authentication has been done, then the PAM module can ask
any number of questions in wants. As sshd generates interactive prompts
at the server side to display on the client. eg. changing a expired
password after logging in via sshd works correctly via the PAM module.

So, I think it will work for this application, too.

I haven't looked at the sshd code though, so I am not sure of the
details. The situation may have improved over time, too.
-- 
Brian May <bam@snoopy.apana.org.au>

--
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: general security lib (was: 2.6.0-test3)

[Brian May]

On Sat, Aug 23, 2003 at 12:09:19AM +1000, Russell Coker wrote:
> Theodore Ts'o suggested to me that a new PAM call be added to run the shell 
> which takes appropriate parameters about user-name etc.  Then a SE Linux 
> version of this module could change the security context appropriately, thus 
> requiring only one copy of the code to determine the context to use, and not 
> requiring any on-going modification to applications.

Would this work properly with the chroot authentication stuff in sshd?
-- 
Brian May <bam@snoopy.apana.org.au>

--
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: general security lib (was: 2.6.0-test3)

[Russell Coker]

On Sat, 23 Aug 2003 19:21, Brian May wrote:
> On Sat, Aug 23, 2003 at 12:09:19AM +1000, Russell Coker wrote:
> > Theodore Ts'o suggested to me that a new PAM call be added to run the
> > shell which takes appropriate parameters about user-name etc.  Then a SE
> > Linux version of this module could change the security context
> > appropriately, thus requiring only one copy of the code to determine the
> > context to use, and not requiring any on-going modification to
> > applications.
>
> Would this work properly with the chroot authentication stuff in sshd?

As the shared object itself is not in the chroot environment it must be loaded 
before the chroot(), therefore at that time it should be able to load and 
cache any files it needs.

This may need some modifications to the SE Linux library code, but it 
shouldn't be too difficult.

-- 
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: 2.6.0-test3

[Dale Amon]

On Fri, Aug 22, 2003 at 10:44:46PM +1000, Russell Coker wrote:
> On Fri, 22 Aug 2003 08:32, Brian May wrote:
> > Does the libselinux in unstable support the 2.6 interface yet?
> 
> Colin is about to upload a new libselinux for 2.6 and the 2.4 back-port...

Any ETA for when the updates be available? I'm still seeing 
the conflict with the selinux package and policycoreutils.




--
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: 2.6.0-test3

[Colin Walters]

On Sun, 2003-08-24 at 13:30, Dale Amon wrote:
> On Fri, Aug 22, 2003 at 10:44:46PM +1000, Russell Coker wrote:
> > On Fri, 22 Aug 2003 08:32, Brian May wrote:
> > > Does the libselinux in unstable support the 2.6 interface yet?
> > 
> > Colin is about to upload a new libselinux for 2.6 and the 2.4 back-port...
> 
> Any ETA for when the updates be available? I'm still seeing 
> the conflict with the selinux package and policycoreutils.

I think this is due to the incompatibilities with Russell's
selinux-policy-default.  I split out policycoreutils from that package.


--
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: 2.6.0-test3

[Dale Amon]

On Sun, Aug 24, 2003 at 01:50:54PM -0400, Colin Walters wrote:
> On Sun, 2003-08-24 at 13:30, Dale Amon wrote:
> > On Fri, Aug 22, 2003 at 10:44:46PM +1000, Russell Coker wrote:
> > > On Fri, 22 Aug 2003 08:32, Brian May wrote:
> > > > Does the libselinux in unstable support the 2.6 interface yet?
> > > 
> > > Colin is about to upload a new libselinux for 2.6 and the 2.4 back-port...
> > 
> > Any ETA for when the updates be available? I'm still seeing 
> > the conflict with the selinux package and policycoreutils.
> 
> I think this is due to the incompatibilities with Russell's
> selinux-policy-default.  I split out policycoreutils from that package.

Could some one give me a heads up when I should try a sid update
to sort my test machine out? It's very confused at the moment! :-)

No terrible rush, just tell me when things are sorted.

--
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: general security lib (was: 2.6.0-test3)

[Stephen Smalley]

On Fri, 2003-08-22 at 10:09, Russell Coker wrote:
> A modification to PAM could allow the sshd, login, and cron patches to go 
> away.
> 
> Theodore Ts'o suggested to me that a new PAM call be added to run the shell 
> which takes appropriate parameters about user-name etc.  Then a SE Linux 
> version of this module could change the security context appropriately, thus 
> requiring only one copy of the code to determine the context to use, and not 
> requiring any on-going modification to applications.
> 
> This design concept sounds really good, and as it's Ted's suggestion I don't 
> expect any great resistance to accepting the patch upstream once it's been 
> tested and proven to work.
> 
> I've been meaning to work on this for almost a year, I might start work next 
> week.

On second thought, I'm not sure that the above is correct.  The existing
SELinux patch parallels the existing code in login and sshd; it invokes
setexeccon() to set the exec security context just as the existing code
invokes setuid() to set the user identity, and it invokes setfilecon()
to set the tty/pty security context just as the existing code invokes
chown() and chmod() to set the tty/pty ownership and mode.  Why would
the SELinux patch be migrated into PAM when the setuid(), chown(), and
chmod() is not?

-- 
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: general security lib (was: 2.6.0-test3)

[Russell Coker]

On Wed, 27 Aug 2003 00:40, Stephen Smalley wrote:
> On second thought, I'm not sure that the above is correct.  The existing
> SELinux patch parallels the existing code in login and sshd; it invokes
> setexeccon() to set the exec security context just as the existing code
> invokes setuid() to set the user identity, and it invokes setfilecon()
> to set the tty/pty security context just as the existing code invokes
> chown() and chmod() to set the tty/pty ownership and mode.  Why would
> the SELinux patch be migrated into PAM when the setuid(), chown(), and
> chmod() is not?

The idea is that the setuid/chown/etc code would be put in the module too.

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