swapon unsuppoted?

swapon unsuppoted?

[Yuichi Nakamura]

Hi.

When I used swapon command, 
access vector "swapon" was not checked, 
only capability sys_admin was checked.
It seems that FILE__SWAPON does not exist in hooks.c

Is swapon unsupported in current version?

---
Yuichi Nakamura
Japan SELinux Users Group(JSELUG)
SELinux Policy Editor:  http://seedit.sourceforge.net/



--
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: swapon unsuppoted?

[Stephen Smalley]

On Mon, 2005-10-10 at 15:50 -0400, Yuichi Nakamura wrote:
> Hi.
> 
> When I used swapon command, 
> access vector "swapon" was not checked, 
> only capability sys_admin was checked.
> It seems that FILE__SWAPON does not exist in hooks.c
> 
> Is swapon unsupported in current version?

Yes, the corresponding LSM hook was never merged upstream.  There was
never a strong justification for it in the first place. 

-- 
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: swapon unsuppoted?

[Yuichi Nakamura]

Stephen Smalley wrote:
> > When I used swapon command, 
> > access vector "swapon" was not checked, 
> > only capability sys_admin was checked.
> > It seems that FILE__SWAPON does not exist in hooks.c
> > 
> > Is swapon unsupported in current version?
> Yes, the corresponding LSM hook was never merged upstream.  There was
> never a strong justification for it in the first place. 
I see, I found when swapon is used, getattr ,read and write are also checked.
swapon access vector may not be useful.

So, why it still exists in access_vectors file?
I think it is confusing, 
it should be removed or comment should be described.

---
Yuichi Nakamura
Japan SELinux Users Group(JSELUG)
SELinux Policy Editor:  http://seedit.sourceforge.net/


--
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: swapon unsuppoted?

[Stephen Smalley]

On Wed, 2005-10-12 at 11:11 -0400, Yuichi Nakamura wrote:
> I see, I found when swapon is used, getattr ,read and write are also checked.
> swapon access vector may not be useful.
> 
> So, why it still exists in access_vectors file?
> I think it is confusing, 
> it should be removed or comment should be described.

Removing it would cause the subsequent permissions to change bit values,
thereby breaking compatibility with the kernel.  A comment would be
fine.  It isn't the only dead permission.

-- 
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: swapon unsuppoted?

[Yuichi Nakamura]

Stephen Smalley wrote:
> On Mon, 2005-10-10 at 15:50 -0400, Yuichi Nakamura wrote:
> > Is swapon unsupported in current version?
> Yes, the corresponding LSM hook was never merged upstream.  There was
> never a strong justification for it in the first place. 

I am reviewing meaning of access vectors to develop SELinux Policy Editor.
I also found  
capability:net_broadcast, 
filesystem:transition and object class ipc are unused.
Is it correct?
And are they going to be used in the future?

---
Yuichi Nakamura
Japan SELinux Users Group(JSELUG)
SELinux Policy Editor:  http://seedit.sourceforge.net/


--
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: swapon unsuppoted?

[Stephen Smalley]

On Wed, 2005-10-12 at 11:17 -0400, Yuichi Nakamura wrote:
> I am reviewing meaning of access vectors to develop SELinux Policy Editor.
> I also found  
> capability:net_broadcast, 
> filesystem:transition and object class ipc are unused.
> Is it correct?
> And are they going to be used in the future?

SELinux simply defines a parallel capability for every capability
defined by the core kernel, so even if CAP_NET_BROADCAST is presently
unused by the mainline kernel, we would want to retain the definition as
long as it remains defined in include/linux/capability.h.  An out of
tree driver could still be using it.

Filesystem transition is unused; the filesystem
relabelfrom/relabelto/transition triple was originally for the old
chsidfs interface and persistent label on superblocks, which was lost
when we migrated to using xattrs and overhauled the API, and
relabelfrom/relabelto were later reclaimed for use to control context
mounts.

Object class ipc is obsolete; it is a relic of the old modular SELinux
and precondition function handling.

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

Other unused permissions(Re: swapon unsuppoted?

[Yuichi Nakamura]

Yuichi Nakamura  wrote:
> I am reviewing meaning of access vectors to develop SELinux Policy Editor.
> I also found  
> capability:net_broadcast, 
> filesystem:transition and object class ipc are unused.

I also found following seem to be unused( in linux 2.6.12-1.1398_FC4).

* netif : enforce_dest 
* socket common :ioctl, append, lock, relabelfrom, relabelto, recvfrom,setattr
* unix_stream_socket: newconn, acceptfrom
* tcp_socket: connectto, newconn, acceptfrom

Some permissions seem to be defined for compatibility, 
will these be active again in the future?

---
Yuichi Nakamura
Japan SELinux Users Group(JSELUG)
SELinux Policy Editor:  http://seedit.sourceforge.net/


--
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: Other unused permissions(Re: swapon unsuppoted?

[Stephen Smalley]

On Thu, 2005-10-20 at 10:43 -0400, Yuichi Nakamura wrote:
> I also found following seem to be unused( in linux 2.6.12-1.1398_FC4).
> 
> * netif : enforce_dest 

Correct - that was specific to one of the extended socket calls in the
original SELinux API.  Not sure it will ever be revived.

> * socket common :ioctl, append, lock, relabelfrom, relabelto, recvfrom,setattr

You need to be careful here; some of these permissions are inherited
from file, so the file checks in the code may be applicable to a socket
object as well.  A variety of calls act on file descriptors that might
refer to a socket, such as ioctl, fcntl, flock, fchmod, etc, even though
it may not make sense to use them on a socket in all cases.  Thus,
ioctl, append, lock, and setattr are possible.  relabelfrom and
relabelto should eventually be restored; it should be possible to
implement relabeling support for sockets via fsetxattr (requires a
kernel change, but not an interface change).  recvfrom is presently
unused and its original meaning essentially subsumed by other network
permission checks (*_recv on netif and node).

> * unix_stream_socket: newconn, acceptfrom

Since these are local sockets, the acceptfrom check was always
extraneous here - the connectto check is sufficient.  newconn was
related to the extended socket call API, not sure if it will ever be
revived.

> * tcp_socket: connectto, newconn, acceptfrom

connectto/acceptfrom might be revived once the labeled networking
support (via IPSEC) is mainstreamed.  newconn again was related to the
extended socket API.

> Some permissions seem to be defined for compatibility, 
> will these be active again in the future?

-- 
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: Other unused permissions(Re: swapon unsuppoted?

[Stephen Smalley]

On Sun, 2005-11-27 at 10:26 +1100, Russell Coker wrote:
> On Friday 21 October 2005 22:52, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > > * netif : enforce_dest
> >
> > Correct - that was specific to one of the extended socket calls in the
> > original SELinux API.  Not sure it will ever be revived.
> 
> I think it would be a good idea to rename the unused entries with names such 
> as "unused1", "unused2", etc.  That makes it clear to everyone what their 
> status is and will result in anyone who proposes a new entry in taking the 
> spot of one of the old ones rather than just adding a new one to the end.
> 
> It will also avoid future discussions about this.

Yes, that would likely be a good idea.  Patches accepted.  cc'd selinux
list.

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