OSR 507: umask, configuration and default settings
Pepe
The system was installed with the Traditional security profile.
After reading the documentation, what I have understood is that the
umask default configuration goes something like this:
1. kernel parameter CMASK: sets the umask which the kernel is going to
use. The default value in /etc/conf/cf.d/mtune is "0", which I guess
means "umask 000".
2. init's umask, configured in the script /etc/initscript with which
init runs all the scripts it launches. The default value configured in
that script in security profile Traditional is "umask 022". Because at
boot time the kernel runs init, I guess from that point onwards this is
the operative system default umask setting for everything that init
launches, am I right?
3. umask for login sessions, defined:
3a. system-wide, preferably in /etc/profile, and if absent there then
login falls back to the value set in the parameter UMASK in
/etc/default/login.
3b. system-wide, if no umask is set in step 3a, then the man page for
login says "Initially, umask is set to octal 022 by login".
3c. per user, in $HOME/.profile
4. the cron man page makes no mention of any special hardcoded default
umask.
--------------------------------------------------------
So I guess that if I don't change the default CMASK kernel parameter
(umask 000), and if I comment out the umask setting in /etc/initscript,
then init should function with "umask 000" inherited from the kernel,
i.e., then init should create standard files like "-rw-rw-rw-" and
directories like "drwxrwxrwx".
Well, not quite so... I did this test:
# ls -l /etc/init.d/inittouch
-rwxr-xr-x 1 root sys 85 Dic 4 23:10 /etc/init.d/inittouch
# cat /etc/init.d/inittouch
#!/bin/sh
UM=`umask`
echo Running script inittouch... Init environment umask is $UM.
# ls -l /etc/rc2.d/S00inittouch
lrwxrwxrwx 1 root sys 21 Dic 4 22:53
/etc/rc2.d/S00inittouch -> /etc/init.d/inittouch
And the output from that script at boot time is:
# cat /etc/rc2.d/messages/S00inittouch.log
Running script inittouch... Init environment umask is 0077.
So I have some questions, here:
1. does the kernel come with a hardcoded default umask, different than
the default value of "CMASK 0" set in /etc/conf/cf.d/mtune ?
2. does init come with a hardcoded default umask? what does define the
umask init runs with if no umask is declared in /etc/initscript ?
Also, if I comment out the umask command in /etc/initscript as in the
test above, cron creates files with an umask of 077, which seems to be
inherited from init. However, if I set "umask 000" in /etc/initscript
and reboot the system, cron still creates files with an umask of 077.
How come so? Does cron have a hardcoded default umask of 077 ? Where is
documented this behavior of cron relating to its default umask value?
Even more weird things... If I comment out the umask command in
/etc/profile, and if I don't set a value for UMASK in
/etc/default/login, and also I don't set any umask in $HOME/.profile,
the shell I get after logging in has an umask of 077. But, doesn't the
login man page say that the default umask in that case should be 022 ?
If anyone can shed light into the rationale behind this weird and
undocumented behaviors, I'm all ears.
Steve M. Fabac, Jr.
What's your point? How is this a problem and what are you trying to do?
We're all ears.
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
Pepe
My questions are:
1. where does init get its default umask setting from, in case it is not
specified in /etc/initscript ?
2. where does login get its default umask from, and why it isn't 022 as
its man page says?
3. where does cron get its default umask setting from?
4. where is it documented the answer to questions 1, 2 and 3 ?
Thanks you.
Pepe
Further investigations suggest that the CMASK kernel parameter does not
work as advertised in DocView section "Kernel parameters that you can
change using configure" (
http://localhost:8457/en/PERFORM/kernel_configure.html ).
My test on the CMASK kernel parameter:
# /etc/conf/bin/idtune CMASK 022
# grep CMASK /etc/conf/cf.d/stune
CMASK 022
# /etc/conf/bin/idbuild
boot this kernel by default? y
rebuild kernel environment? y
# init 6
Now I create the script:
# ls -l /bin/borrar.sh
-rwxr-xr-x 1 root sys 35 Dic 6 21:51 /bin/borrar.sh
# cat /bin/borrar.sh
#!/bin/sh
touch /tmp/inittouch.txt
# rm /etc/init
# ln -s /bin/borrar.sh /etc/init
# sync; sync; sync; reboot
Ok, system reboots and gives the message:
WARNING: exit - /etc/init (PID 1) died, status 0x00000000
I boot now with the rescue boot+root floppies, and remake the correct
symbolic link for init:
# mount /dev/hd0root /mnt
# cd /mnt/etc
# rm init
# ln -s /opt/K/SCO/Unix/5.0.7Hw/etc/init init
# cd /
# umount /mnt
# reboot
Now the system boots normally, and I do:
# ls -l /tmp/inittouch.txt
-rw------- 1 root root 0 Dic 6 21:52 /tmp/inittouch.txt
And I find out the kernel applied an umask of 077 to file
"inittouch.txt", whereas I instructed the kernel with the CMASK
parameter to use an umask of 022.
What I expected? To get a file named "/tmp/inittouch.txt" with
permissions 644.
What I got? A file named "/tmp/inittouch.txt" with permissions 600.
My question?: Why didn't the "CMASK 022" kernel parameter give me what I
expected?
Bela Lubkin
> In OpenServer 5.0.7 with MP5, I am testing different umask configurations.
You do like to torture yourself, don't you...
> 1. kernel parameter CMASK: sets the umask which the kernel is going to
> use. The default value in /etc/conf/cf.d/mtune is "0", which I guess
> means "umask 000".
The doc you pointed to ("as advertised in DocView") is sort of right,
sort of wrong, and mostly completely irrelevant:
" CMASK
" The default mask used by umask(S) for file creation. By default
" this is zero, meaning that the umask is not set in the kernel.
umask(S) doesn't create files, the doc writer meant "the default
umask(S) file creation mask".
The configure(ADM) setting of CMASK is consumed in
/etc/conf/pack.d/kernel/space.c:
int Cmask = CMASK;
That's the only reference in any kernel *.[ch] file. Turning to *.[oa]
files,
# cd /etc/conf/pack.d
# nm -r */*.[oa] | grep Cmask
[56] | 0| 0|NOTY |GLOB |0 |UNDEF |startup.o:Cmask
Then I use a favorite trick:
# ar xv /etc/conf/pack.d/kernel/os.a startup.o
x - startup.o
# cc startup.o -o startup
/// 80+ errors omitted
# cc startup.o -o startup 2>&1 | awk '/\.o$/ { print "void "$1"(){}" }' > startup-missing.c
# cc startup.o startup-missing.c -o startup
Extract the object file and compile it with a bunch of stubs. Now you
can disassemble this fully linked binary and see what calls what.
Skipping more steps, in the end I find that p0init() is the only kernel
function that uses Cmask. That's the function that creates "process" 0,
which eventually forks process 1 and so on.
"By default this is zero" -- true, as seen in
# grep CMASK /etc/conf/cf.d/mtune
CMASK 0 0 0777
"meaning that the umask is not set in the kernel" -- false. p0init()
stores Cmask into process 0's umask no matter what it is or whether you
have explicitly set it.
Irrelevant: the only processes ever started by process 0 are a few
kernel daemons that probably don't create any files anyway, and `init`.
If init sets its own umask then effectively CMASK / Cmask has no use or
purpose whatever.
> 2. init's umask, configured in the script /etc/initscript with which
> init runs all the scripts it launches. The default value configured in
> that script in security profile Traditional is "umask 022". Because at
> boot time the kernel runs init, I guess from that point onwards this is
> the operative system default umask setting for everything that init
> launches, am I right?
I wouldn't construe this as "init's umask". It is (as you describe) the
umask applied to processes *started by* init. It doesn't start itself
with initscript so init's own umask comes from elsewhere.
> 3. umask for login sessions, defined:
>
> 3a. system-wide, preferably in /etc/profile, and if absent there then
> login falls back to the value set in the parameter UMASK in
> /etc/default/login.
/bin/login doesn't read /etc/profile. /etc/profile doesn't come into
play until you've actually logged in, when it is read by your login
shell -- if your login shell is a member of the Bourne shell lineage.
> 3b. system-wide, if no umask is set in step 3a, then the man page for
> login says "Initially, umask is set to octal 022 by login".
In full on this subject, login(M) says:
" UMASK This is the default file creation mask (see umask(C)).
...
" Initially, umask is set to octal 022 by login.
I take this to mean that the default here is 022 unless overridden by
UMASK in /etc/default/login. But! `strings` tells me there are no
references to UMASK in /bin/login or in any of the shared objects it's
linked with. In fact, by doing this I determined that *nothing* in the
system(*) reads "UMASK" from /etc/default/login:
# cd /opt/K/SCO/Unix
# find . -type f -follow -print | xargs gnugrep -al UMASK
This finds a dozen or so false matches (various things that are
manipulating umasks and using the name "UMASK", but *not* interacting
with /etc/default/login). (*) Of course I only checked the "Unix" SSO,
but I doubt there's anything outside that uses it.(**)
The most interesting bit was in the files /tcb/lib/relax/*/script.
These are used by relax(ADM). Each of them has this code:
# fix up default umasks
for file in /etc/initscript /etc/cshrc /etc/profile
do
/bin/sed "s/.*umask.*/umask $UMASK/" < $file > $file-t
/bin/cat $file-t > $file
/bin/rm -f $file-t
done
-- differing only in the assigned values of UMASK: 077 for "high", 027
for "improved", and 022 for "traditional" and "low". So this intends to
set the umask for all init scripts & logins (to the extent that logins
all use sh & csh-family shells). Running `relax some-level` will revert
any private changes in those files. If you made slightly fancier
structural changes to /etc/profile, `relax` could actually break the
script with its naive substitution...
(**)... but imagine my surprise. I went back and ran it for the entire
/opt/K hierarchy and found that /opt/K/SCO/ssh/5.0.7Hf/etc/sshd --
that's /etc/sshd to you and me -- has the strings "/etc/default/login"
and "UMASK" in close and obvious proximity:
/etc/default/login
SUPATH
PATH
UMASK
What does that mean?
1. The person doing the OpenSSH port for OSR507 had read and believed
login(M) more than the software itself did
2. If you are still running the ancient sshd that came with OSR507, you
have this feature for ssh logins only; the feature being "your umask
comes from /etc/default/login for a few microseconds until overridden
by /etc/profile, /etc/cshrc, ~/.profile, etc."
3. The OSR507 files I'm looking at are actually old engineering
prototypes on this system (it's running 506 but has a set of
/opt/K/SCO/*/*5.0.7* files laid down in the SSO hierarchy).
"5.0.7Hf" would have been Build Level 8-f (BL8f) while the product
shipped at BL8w.
4. The OpenSSH in this build is "OpenSSH_3.8.1p1, OpenSSL 0.9.7e 25 Oct
2004" while I have an idea that 507 shipped with, or was eventually
supplied with a supplement bringing it up to "OpenSSH_4.2p1, OpenSSL
0.9.7e 25 Oct 2004", which of course is still ridiculously ancient.
> 3c. per user, in $HOME/.profile
Of course; or .cshrc or .login or whatever.
> 4. the cron man page makes no mention of any special hardcoded default
> umask.
> --------------------------------------------------------
>
> So I guess that if I don't change the default CMASK kernel parameter
> (umask 000),
then PID 0's umask will be 0;
> and if I comment out the umask setting in /etc/initscript,
then processes started by init will have init's own umask, which we
haven't discussed yet; until/unless you run `relax level` and it gets
blasterized by the script. There's some sort of GUI to this stuff in
`scoadmin` and there may also be a thing or two that runs it for you
without your asking (possibly major installs of some top-level
components).
> then init should function with "umask 000" inherited from the kernel,
> i.e., then init should create standard files like "-rw-rw-rw-" and
> directories like "drwxrwxrwx".
>
> Well, not quite so... I did this test:
Right, we'll get there...
> # ls -l /etc/init.d/inittouch
> -rwxr-xr-x 1 root sys 85 Dic 4 23:10 /etc/init.d/inittouch
> # cat /etc/init.d/inittouch
> #!/bin/sh
> UM=`umask`
> echo Running script inittouch... Init environment umask is $UM.
> # ls -l /etc/rc2.d/S00inittouch
> lrwxrwxrwx 1 root sys 21 Dic 4 22:53
> /etc/rc2.d/S00inittouch -> /etc/init.d/inittouch
>
> And the output from that script at boot time is:
>
> # cat /etc/rc2.d/messages/S00inittouch.log
> Running script inittouch... Init environment umask is 0077.
If you want `init` to run some arbitrary program, there are two routes
available at runtime. One is sd(ADM) which you can read yourself (you
make a suitably formatted entry in /tcb/files/no_luid/cmdtable). The
other is in inittab(F):
" Entries with values a, b, and c in this field are not true run-levels
" but are [run when you say `init a` etc.]
So for your purpose you could have done, e.g.:
# cd /etc
# cp -p inittab inittab.sav
# echo "XYZ:c:once:/etc/init.d/inittouch > /tmp/inittouch.out 2>&1" >> inittab
# init q # reread inittab
# init c # do the 'c' entry
# cp -p inittab.sav inittab # remove the tmp 'c' entry
# init q # reread inittab
I'm not sure if the `init q`s are necessary; they won't hurt.
> So I have some questions, here:
>
> 1. does the kernel come with a hardcoded default umask, different than
> the default value of "CMASK 0" set in /etc/conf/cf.d/mtune ?
Nope
> 2. does init come with a hardcoded default umask? what does define the
> umask init runs with if no umask is declared in /etc/initscript ?
Sort of; and as I said, initscript has no effect on init *itself*.
> Also, if I comment out the umask command in /etc/initscript as in the
> test above, cron creates files with an umask of 077, which seems to be
> inherited from init. However, if I set "umask 000" in /etc/initscript
> and reboot the system, cron still creates files with an umask of 077.
> How come so? Does cron have a hardcoded default umask of 077 ? Where is
> documented this behavior of cron relating to its default umask value?
Also "sort of".
> Even more weird things... If I comment out the umask command in
> /etc/profile, and if I don't set a value for UMASK in
> /etc/default/login, and also I don't set any umask in $HOME/.profile,
> the shell I get after logging in has an umask of 077. But, doesn't the
> login man page say that the default umask in that case should be 022 ?
>
> If anyone can shed light into the rationale behind this weird and
> undocumented behaviors, I'm all ears.
It's ever so slightly documented...
See identity(S). This is an omnibus man page covering a dozen
SecureWare functions, among them set_auth_parameters(). This is an evil
function, one of whose features is mentioned in the man page:
" set_auth_parameters resets the umask in the calling process to 077.
...
You've mentioned a couple of times the /tcb files "that SCO invented".
Not so. That hierarchy is the "Trusted Computing Base", intended to
implement a C2 level of security. (That was hot stuff back then.) To
achieve C2, SCO modified every utility they could think of which had a
security role. Actually, SCO hired a third party to do so: SecureWare.
SecureWare twiddled every utility in sight, returning them in what were
referred to as "Trusted" editions. Obviously `login` and `cron` are
going to be two such utilities.
Every utility they touched starts life by calling set_auth_parameters(),
thus acquiring an 077 umask unless they specifically change it
afterwards.
SCO wasn't the only company to use SecureWare. HPUX used it around the
same time; I believe it's still there, possibly considerably mutated in
the last ~20 years. I think some subflavor of Digital UNIX (OSF/1) also
had a SecureWare implementation. SecureWare had a set of libraries
which they would custom-bolt onto your flavor of Unix, so each actual
field implementation is moderately different, but generally similar.
SCO's implementation has a *lot* of documentation, including:
System Administration Guide, Chapter 5 "Maintaining system security":
<http://localhost:457/cgi-bin/printchapter/OSAdminG/BOOKCHAPTER-5.html>
Operating System User's Guide, Chapter 9 "Using a secure system":
<http://localhost:457/cgi-bin/printchapter/OSUserG/BOOKCHAPTER-9.html>
Man pages of SecureWare library functions, file formats and similar
information:
acceptable_password(S), audit(HW), audit(S), authaudit(S),
authcap(F), authcap(S), authorize(F), auths(C), default(F),
devassign(F), files(F), get_seed(S), getdvagent(S), getluid(S),
getpasswd(S), getprdfent(S), getprfient(S), getpriv(S),
getprpwent(S), getprtcent(S), identity(S), passlen(S), prpw(F),
randomword(S), setluid(S), setpriv(S), smp_audit_fail(S),
smp_check_pw(S), smp_check_user(S), smp_generate_pw(S),
smp_get_messages(S), smp_pw_change(S), smp_pw_choice(S),
smp_set_identity(S), smp_set_pw(S), smp_try_pw(S), subsystem(M),
subsystems(S), ttys(F)
Man pages of purely SecureWare-provided commands or commands SCO wrote
expressly to deal with SecureWare stuff:
addxusers(ADM), ale(ADM), ap(ADM), asroot(ADM), auditcmd(ADM),
auditd(ADM), auditsh(ADM), authck(ADM), authsh(ADM), chg_audit(ADM),
dlvr_audit(ADM), fixmog(ADM), goodpw(ADM), initcond(ADM),
integrity(ADM), reduce(ADM), relax(ADM), report(ADM), sd(ADM),
secdefs(ADM), tcbck(ADM), unretire(ADM)
Man pages of commands documented as affected by SecureWare (most of
these mention at least "Authorizations"):
accept(ADM), at(C), cancel(C), crontab(C), df(C), disable(C),
enable(C), getty(M), groupadd(ADM), groupls(ADM), hierarchy(M),
init(M), ipcs(ADM), login(M), lpstat(C), mount(ADM), newgrp(C),
passwd(C), prwarn(C), ps(C), pstat(C), pwconv(ADM), rmuser(ADM),
shutdown(ADM), su(C), sysadmsh(ADM), useradd(ADM), userls(ADM), w(C),
whodo(C), write(C)
Other binaries that are linked against libprot (implying some
dependency) but not documented as such:
acct(ADM) and related process accounting commands
additional System V lp(C) printer subsystem programs
assorted NIS/yp commands
assorted ftp-related commands
assorted ssh commands
custom(ADM) and its internals
various bits of scoadmin(ADM)
plus:
cpio(C), cron(C), finger(C), hello(C), id(C), imapd(ADMN),
inetd(ADMN), ipcrm(ADM), ls(C), mesg(C), on(NC), pcnfsd(NADM),
popper(ADM), rexd(NADM), rexecd(ADMN), rlogind(ADMN), rshd(ADMN),
scolock(XC), scologin(XC), script(TC), sessreg(1), sg(C), smtpd(ADM),
sulogin(ADM), telnetd(ADMN), uucpd(ADMN), xdm(1)
Many of the SecureWare man pages are uninteresting API junk; others give
you a large amount of insight into what it's all about.
When it was first introduced in SCO UNIX 3.2.0, it was pretty awful.
Over time it got refinements, fallbacks, relaxations etc. which made it
OK. (For contrast: I am by no means reconciled like that with the
symlink mess. That was done for "SSOs" -- Software Storage Objects -- a
grand concept that never delivered more than 2% of its claims, and made
a horrible mess out of everything. Pthbhthbthtt!)
> My questions are:
>
> 1. where does init get its default umask setting from, in case it is not
> specified in /etc/initscript ?
set_auth_parameters() [identity(S)]
> 2. where does login get its default umask from, and why it isn't 022 as
> its man page says?
Same
> 3. where does cron get its default umask setting from?
Same
> 4. where is it documented the answer to questions 1, 2 and 3 ?
identity(S) + a lot of sleuthing or knowing from past experience...
> Now I create the script:
> # ls -l /bin/borrar.sh
> -rwxr-xr-x 1 root sys 35 Dic 6 21:51 /bin/borrar.sh
> # cat /bin/borrar.sh
> #!/bin/sh
> touch /tmp/inittouch.txt
>
> # rm /etc/init
> # ln -s /bin/borrar.sh /etc/init
> # sync; sync; sync; reboot
>
> Ok, system reboots and gives the message:
> WARNING: exit - /etc/init (PID 1) died, status 0x00000000
>
> I boot now with the rescue boot+root floppies, and remake the correct
> symbolic link for init:
Better:
# mkdir /etc/init.bin
# mv /etc/init /etc/init.bin/init
# echo 'exec /etc/init.bin/init "$@"' >> /bin/borrar.sh
# ln -s /bin/borrar.sh /etc/init
# reboot
... system boots, creates /tmp/inittouch.txt [0600], boots normally
# mv -f /etc/init.bin/init /etc/init
# rm -rf /etc/init.bin
The extra directory is because `init` is one of those binaries that
looks at argv[0] to see what to do. Normally I would just rename it to
"/etc/init.real", but that may fail in the argv[0]-sniffing case. Using
the same basename in a different directory won't fail.
> And I find out the kernel applied an umask of 077 to file
> "inittouch.txt", whereas I instructed the kernel with the CMASK
> parameter to use an umask of 022.
...
> My question?: Why didn't the "CMASK 022" kernel parameter give me what I
> expected?
That's a puzzle, actually. What I expect is that proc 0 has umask CMASK
(022 in your test), it execs whatever you've stuck in /etc/init, and
that should have 022. Your interpreter statement "#!/bin/sh" shouldn't
hurt it, /bin/sh definitely does *not* call set_auth_parameters() and
acquire an 077 umask.
To check some assumptions, try a test script like:
#!/bin/sh
umask > /tmp/umask.init
ps -ef > /tmp/ps.early
exec /etc/init.bin/init "$@"
Now /tmp/umask.init records both the acted-on and the shell's idea of
umask. ps.early should (I believe) show PID 0 "sched", 1 "init", 2
"vhand", 3 "bdflush", 4 "kmdaemon", 5 "htepi_daemon /", and 6 "ps"
(umask is a shell builtin and shouldn't consume a PID). Insert 4 "CPU1
idle process", 5 "CPU2 idle process", etc. up to the # CPUs you're
using, if you have SCO SMP installed.
Hmmm.
Ok, some disassembly gets me:
sec_init+10C movw u.u_cmask,3F
That's storing 077 into the current user-area's umask. sec_init() is
called by crllry_sec_init(), which is called by main() at a time when
I'm pretty sure process 0 is the only one. So this is more fun from
SecureWare: even process 0's umask Must Be Secure.
PID 0's umask matters little except in being passed on to init. So if
this really concerns you, permanently replace /etc/init:
#!/bin/sh
umask 0 # whatever
### this would also be a great place to establish
### a bunch of system-wide ulimits...
exec /etc/init.bin/init "$@"
Also, sec_init() comes from a driver, "sec". The kernel won't link with
it removed, but I'm pretty sure it could be stubbed out with a moderate
amount of effort...
>Bela<
Pepe
Thank you very much for you reply, Bela. That was not a Usenet post, it
was a full fledged technical whitepaper!
I got all the answers I was searching for, and then some more.
Although you already solved the last mystery: the kernel's CMASK
parameter and why it is being overrided -- I could not stop from trying
your suggested test anyway, for completeness:
------------------------------------------------------
root@gollum02:/root # grep umask /etc/initscript
# umask 022
## umask 077
root@gollum02:/root # grep umask /etc/profile
# umask 022
# Cambio umask a 077, fecha: 2010-11-21
## umask 077
root@gollum02:/root # grep CMASK /etc/conf/cf.d/?tune
/etc/conf/cf.d/mtune:CMASK 0 0 0777
/etc/conf/cf.d/stune:CMASK 022
root@gollum02:/root #
root@gollum02:/root # ls -ld /etc/init.bin/
drwxr-xr-x 2 root sys 512 Dic 7 17:05 /etc/init.bin/
root@gollum02:/root # ls -l /etc/init.bin/
total 0
lrwxrwxrwx 1 root root 32 Nov 21 11:49 init ->
/opt/K/SCO/Unix/5.0.7Hw/etc/init
root@gollum02:/root #
root@gollum02:/root # ls -l /bin/borrar.sh
-rwxr-xr-x 1 root sys 86 Dic 7 17:09 /bin/borrar.sh
root@gollum02:/root # cat /bin/borrar.sh
#!/bin/sh
umask > /tmp/umask.init
ps -ef > /tmp/ps.early
exec /etc/init.bin/init "$@"
root@gollum02:/root #
root@gollum02:/root # ls -l /etc/init
lrwxrwxrwx 1 root sys 14 Dic 7 17:07 /etc/init ->
/bin/borrar.sh
root@gollum02:/root #
------------------------------------------------------
I then rebooted, and then:
------------------------------------------------------
root@gollum02:/root # ls -l /tmp/umask.init /tmp/ps.early
-rw------- 1 root root 745 Dic 7 17:12 /tmp/ps.early
-rw------- 1 root root 5 Dic 7 17:12 /tmp/umask.init
root@gollum02:/root # cat /tmp/umask.init
0077
root@gollum02:/root # cat /tmp/ps.early
UID PID PPID C STIME TTY TIME CMD
root 0 0 8 16:12:23 ? 00:00:00 sched
root 1 0 1 16:12:23 ? 00:00:00 /etc/init
root 2 0 0 16:12:23 ? 00:00:00 vhand
root 3 0 0 16:12:23 ? 00:00:00 bdflush
root 4 0 0 16:12:23 ? 00:00:00 CPU1 idle process
root 5 0 0 16:12:23 ? 00:00:00 kmdaemon
root 6 1 0 16:12:23 ? 00:00:00 htepi_daemon /
root 7 0 0 16:12:23 ? 00:00:00 strd
root 8 1 0 16:12:23 ? 00:00:00 udi_alloc
root 9 1 0 16:12:23 ? 00:00:00 udi_region
root 10 1 2 16:12:23 ? 00:00:00 ps -ef
root@gollum02:/root #
-------------------------------------------------------
Therefore, the user-configurable value of the CMASK kernel parameter for
umask is rendered useless by the hardcoded umask of 077 in the kernel,
which comes from the sec_init() function that SecureWare planted into
the kernel.
Also, as you said, the SecureWare function set_auth_parameters() which
has a hardcoded umask of 077 is injected into many OSR 5 system
utilities, and it is from that function that init (and therefore the
init-initiated scripts and daemons) and login (and therefore the
login-initiated shell) get their default umask, if no umask is declared
in /etc/initscript nor /etc/profile to override said hardcoded umask of 077.
Cron, itself, always runs with the hardcoded umask 077 from the
set_auth_parameters() function, no matter what umask happens to be
configured in /etc/initscript.
All is clear and transparent now.
Thank you again, Bela.
Bela Lubkin
[500+line quote of what I wrote]
Please don't -- Google and other repositories provide perfectly good
storage these days, and USENET's traditional propagation delays and
stochastic routing are things of the past. Quote a few bits you want to
comment on. In the unusual case that someone receives only your reply,
googling on the quotes will find the original.
> Thank you very much for you reply, Bela. That was not a Usenet post, it
> was a full fledged technical whitepaper!
Oh aye, that's why I Cc'd it to my archivist ;-}
> Therefore, the user-configurable value of the CMASK kernel parameter for
> umask is rendered useless by the hardcoded umask of 077 in the kernel,
> which comes from the sec_init() function that SecureWare planted into
> the kernel.
If you really want extra credit, go figure out how to stub out the "sec"
driver. I'll help along the way...
> Also, as you said, the SecureWare function set_auth_parameters() which
> has a hardcoded umask of 077 is injected into many OSR 5 system
> utilities, and it is from that function that init (and therefore the
> init-initiated scripts and daemons) and login (and therefore the
> login-initiated shell) get their default umask, if no umask is declared
> in /etc/initscript nor /etc/profile to override said hardcoded umask of 077.
I should mention that in addition to the four named `relax` modes
"high", "improved", "traditional" and "low", there is a fifth unofficial
mode, "ripped out".
Hmmm. Searching for that term in the SCO tech articles comes up with a
match, <http://www.sco.com/ta/103607>. I also found that it was fully
documented up through 506, but disappeared from 507. Hmmm.
If you're into this sort of experimentation, you should try the "ripped
out" mode and then follow it up with trying to stub out "sec".
On a 506 system, look at <http://localhost:457/FEATS/tcb_remove.html>;
or google for "Security database file removal". The instructions have a
sanity-check bug: "rm -rf /tcb /etc/auth" should be "mv /tcb /tcb.save;
mv /etc/auth /etc/auth.save". Plus, as I remember it, there are one or
two files under those hierarchies which it is beneficial to retain.
Unfortunately I don't remember which they are.
As I remember it, *most* code which looks for TCB files that you're
ripping out looks like this:
if (found TCB blah blah)
do secureware stuff
else if "TCBFILES=OFF" in /etc/default/security
pretend all is well
else
error ...
rather than:
if "TCBFILES=OFF" in /etc/default/security
pretend all is well
else if (found TCB blah blah)
do secureware stuff
else
error ...
So as a general rule, bits of TCB that you leave behind do get used;
"TCBFILES=OFF" is not an order to disregard the TCB, but rather a
permission for utilities to accept the situation when parts of the TCB
are missing.
> Cron, itself, always runs with the hardcoded umask 077 from the
> set_auth_parameters() function, no matter what umask happens to be
> configured in /etc/initscript.
... so, for instance, in "ripped out" mode I believe the call to
set_auth_parameters() will not do this. I may be wrong: I don't believe
you actually remove /lib/libprot.so.1 (you would have to provide stubs
for it); and the part of set_auth_parameters() that slams the umask
doesn't seem like it would have any dependency on TCB files that you
would have removed. But it's an interesting experiment to try... And
of course you *could* go on to the next level by stubbing out libprot
(after stubbing out "sec" driver)...
>Bela<
Pepe
>> parameter for umask is rendered useless by the hardcoded umask of
>> 077 in the kernel, which comes from the sec_init() function that
>> SecureWare planted into the kernel.
>
> If you really want extra credit, go figure out how to stub out the
> "sec" driver. I'll help along the way...
> ... so, for instance, in "ripped out" mode I believe the call to
> set_auth_parameters() will not do this. I may be wrong: I don't
> believe you actually remove /lib/libprot.so.1 (you would have to
> provide stubs for it); and the part of set_auth_parameters() that
> slams the umask doesn't seem like it would have any dependency on TCB
> files that you would have removed. But it's an interesting
> experiment to try... And of course you *could* go on to the next
> level by stubbing out libprot (after stubbing out "sec" driver)...
The idea of building a kernel stubbing out the "sec" driver is tempting;
and also ripping out the TCB subsystem sounds nice...
However, I'm afraid the Unix skills and the OpenServer link-kit Kung Fu
needed for such a hacking project are beyond me. Also, currently I want
to understand OpenServer "classic", not to hack it into pieces and
produce an ultra-customized Frankenstein out of it. :-)
And, more importantly, I've yet to make a proper full backup of my test
system (this is the moment when Nico Kadel-Garcia would advise me to run
OSR 507 inside of a VM and make snapshots before trying serious/suicide
hacking, and certainly he would be spot on).
So for the time being, I won't dive into such deep hacking waters. But
it's nice to know it's doable...