News Group Posts

Bela Lubkin responded to a newsgroup post and gave a huge brain dump of OSR5 SecureWare stuff, specifically relating to how umask is set and how this affects programs run from init and from login.

While there are very few people still using SCO, and the security aspects are certainly very outdated on many that are, this still may be of historical interest. Some of it may even be useful in current context.

From: Bela Lubkin <fi...@armory.com>
Subject: Re: OSR 507: umask, configuration and default settings
Date: Tue, 7 Dec 2010 02:04:14 -0800
Message-ID: <201012070204.aa00502@deepthought.armory.com> 
References: <4cfcd500$2@news.x-privat.org> 

p...@naleco.com wrote:

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

Comments?

More Articles by Bela Lubkin

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.