On Fri, 25 Jan 2002 09:30, jmjonesat_private wrote: > Um, the only problem I have is getting the executable I write to be "full > permission" on a variety of systems. Write in the documentation "if installing on an LSM, GRSecurity, or other security enhanced kernel then make sure that the installation program has full system administration rights and that the SUID root program named /usr/bin/fsckmeharder gets such rights when it's run". > I guess it would be appropriate for it to be set the same priority via DTE > or module-manual methods as the executable being installed, but I am > somewhat uncertain as to how this can be done in a "cross-module" manner. It can't as different modules do different things. Also note that LSM is not the only method of adding extra security to Linux, it's just the most publicised through the NSA SE Linux work that goes into it. Anyone can make a system that operates differently with some small kernel patches. They could even mount the file system in question as "nosuid". Running a Unix system with all file systems mounted nosuid should be possible. > Any advice would be useful, or any modifications to the LSM interface that > would support it would be useful. I know that "having knowledge" of > permissions are specifically out-spec, but The NSA SE Linux work includes patches to common programs such as stat. I have attached the result of stat'ing some binaries on one of my SE Linux systems. However you have to note that my stat is a port of the NSA changes to the Debian stat (which may have different formatting to the Red Hat stat that the NSA ships). Also the results tell you what context the files are in, but not what that context allows. > Wouldn't it be more useful to be able, in a standard-interface sort of > way, to be able to temporarily give an INSTALL type script/application the > same permissions as another application (the installed software) would > get? Call a hook with the name of the application as installed, for > example, and require the module to assign "cloned" permissions? Sure, there's a program in the SE Linux called "newrole" that runs in a similar fashion to /bin/su but for changing security contexts. The following should do it: newrole sysadm_r # now we have a shell with the sysadm_r: /mnt/cd/install > In essence, a standard way to communicate to the module to "interpret my > permissions as if I was XYZ"... leaving it to the module to determine if > the test program has a right to ask that? > > I think this sort of thing might be necessary for LSM to be generally > accepted. I don't think that good security will ever be generally accepted. Security always involves inconveniances. Whenever you lock a door there's a chance that you'll forget the key when you want to open it. Being able to do "su -" and have complete access to the entire system is incredably conveniant. This is why until recently many Linux users used to have root as the only account they ever used. This is why most commercial system programs will only run as root, and why many commercial applications install directories mode 777 (one application I know of has root cron jobs running programs from a mode 777 directory). If you don't want security then that's your decision. But you won't convince anyone on this list in a hurry. -- 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/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
This archive was generated by hypermail 2b30 : Thu Jan 24 2002 - 22:03:42 PST